Page 1 of 1

Rev 7 corruption?

Posted: Sun Sep 10, 2006 1:30 am
by Stinky
Matt,
I've been playing around with the rev7 bin and doing some dyno tuning. I noticed today that there are two areas in the bin that have changed from the basecode that I programmed on the nvram chip. The first is 3F26+3F27. They are normally 01 96 but in the current read I get 13 E0. The second set is 3F3B+3F3C which is normally 01 00 but has been replace by 13 E0 as well. The car still runs fine.

Also, when I do a burn changes sometimes it stalls the car and other times it doesnt.

I'm also definitely experiencing some sort of misfire when changing the timing at higher rpms. I can see the power drop off on the dyno and it quickly picks back up. It's just a hickup but somethigns definitely going on.

Otherwise things are going very well.

Posted: Mon Sep 11, 2006 1:30 pm
by Russ84NA
I was having some problems with the consult conecting. I thought it was taken care of with the connection inside the ECU. Today at the autoX event I was trying to log some A/F and RPM logs. I got everything set to go and running and took off on a run. When I got back the Log had disconnected. When we tried to reconnect I got an error message about an incorrect bin file. The consult was connected and the car ran fine, but I could not get it to log.
Before I left for the event I had experienced a similar problem. By reloading the 88na bins I got it to log. Then it would except the bins I had tuned. Any thoughts?

Posted: Mon Sep 11, 2006 1:57 pm
by Stinky
My problem doesnt seem to be affecting the consult or logging functions. Other than the actual data changing in the bin I dont notice any problems.

Posted: Mon Sep 11, 2006 2:32 pm
by Matt
bryant - i'll have a look into that error you are getting. the 13E0 address looks like the pointer for the start of the buffer code. something not right there. will check it out tonight.

The burn changes has potential to stall the car because whilst the burning occurs, the ECU sits in a tight loop, and has no program code to run. this can take upto half a second. sometimes its a blip and othertimes it can stall. RPM speed during store can affect this also


Russ - I'm going to add a audiable/visual indication to indicate consult has disconnected during runs.

Can you send me your bins that you have tuned? darkhalf@aanet.com.au They may have been corrupted somehow or do not have a nistune patch loaded in it?

You can use the copy map feature to copy your tuned images back to the 88na or similar working rom image to get your tune back in a Nistune ROM image

Posted: Tue Sep 12, 2006 2:24 pm
by Russ84NA
Matt,
I burned my tuned bin files into the 88nacastock_nt base bin file as my old one wouldn't work with the latest version of NisTune. It works and then for some reason it gives me an error message about not being a good bin.
I'll get a copy of it off to you.
Any word on the 84 ECU I sent you?

Posted: Tue Sep 12, 2006 6:48 pm
by Matt
hey russ

yep i have it here, have read out the RAM chips and socketed it. i haven't sent an email since i dont have a modem at home currently (its getting fixed). these forums are my only contact point for now :(

i've been making some more fixes to firmware in regards to NVRAM last weekend for all three board types, and now have to quickly resolve this problem Bryant has raised.

Once that is done I'll program a board up for you with the latest firmware and send it off


Send me the downloaded bin from the romulator (perhaps do a romulator download and also a consult download) and i'll have a look at it. The romulator has the potential to corrupt an image if power is lost or something stange like that. Unless map uploads are corrupting the image. I'll need the log files also if you have any


Bryant - Please put a 10K resistor between pins 13 (D2) and 14 (GND).

This may help the STORE timeout problem. i poll the D2 line for HIGH once STORE is issued, it will be left floating during the STORE (and this resistor will tie it low)

Posted: Wed Sep 13, 2006 4:43 am
by Stinky
I assume this is pin 13 and 14 of the nvram socket correct?

Posted: Mon Sep 18, 2006 12:28 pm
by Matt
yep. solder to the legs of the socket from underneath perhaps.

i've found the problem with the STORE not working and tested to death last night with writes/reads and STORES. all seems to work well now. patch revision 8 will be out soon

do not use patch rev 6-7 for now because it DOES corrupt the vector tables and other areas of the ecu

Posted: Thu Sep 21, 2006 1:29 pm
by Matt
patch rev8 is finished and works sweet. no corruption and no drops in rpm/stalling during STORE. this and a new nistune version should be up tomorrow (friday my time) since i should be getting my modem back then!!!

i'm now doing similar for the Z32 boards since they have a similar issue.

i've been looking into the blatz issue also bryant. the error i get from your blatz is the same when my NIStune tries to incorrectly use my internal modem during consult read. its possible it doesn't support overlapped I/O

when you plug your blatz in. can you tell me what serial port (COM) it is using (Windows device manager will tell you), and connect using the newest version of nistune when I upload it in the next few days. If that doesn't work I'll try some other software which uses Overlapped I/O and see if that has the same problem

Also look to see if there is a newer driver for the Blatz boards.

CP2101 is the chip
http://www.silabs.com/tgwWebApp/public/ ... erface.htm