nvram corruption?

Stinky · Post by **Stinky** » Sat Jun 17, 2006 3:37 pm

Matt,
My car was running a bit odd this evening. A few times I tried to connect consult and I got a message saying something like " could not connect because of checksum error". After restarting nistune and the ecu I was able to connect. To check things I downloaded the bin through consult and did a compare of the download with the rom that should be in place. I found two areas with diffrences. One at 3700h-3701h which I believe is normal because of consult. The second was at 2000h. Normally the value there is 79. However, in the downloaded file it reads 00. I removed teh nvram chip and confirmed this with my reader. 3700-3701h matches with the reader(makes sense) but 2000h is still different.

I havent reburned the nvram chip to confirm that this is why the car was running odd but I'm still thinking the bin shouldnt have changed. Thoughts?

Matt · Post by **Matt** » Sat Jun 17, 2006 7:53 pm

it is strange that 2000 had a change in location since it should be protected from writes to the on chip RAM

that exact location being corrupted will need to be investigated

(a) did the car run fine before connecting USB to laptop and starting nistune?
(b) were there any ecu reconciles or modifications made before the problem (ie modifications to programming of NVRAM?)
(c) you said that consult was unable to connect during initial power on. did you attempt any STORE operations after this?
(d) 3700/3701 is the USB memory mapped location to transfer data and status to/from the ecu this is normal
(e) is there any memory reference to 2000h in your address file?
(f) can you email me a copy of the downloaded file and the normal file?
(g) when you repowered the ecu was it after 10 seconds off?

the nvram will store contents permanently from RAM to EEPROM when STORE(burn) is pressed. it will recover from EEPROM to RAM each time the ECU is powered on (or RECOVER button is pressed)

i need to determine if there was corruption from EEPROM to RAM during the AUTORECOVER during power on which could cause consult connect problems

(h) were you doing STORE operations or similar the day before hand where this corrupt may be been introduced to SRAM and then STORED permanently to EEPROM afterwards?

so you are still currently running the car then with 2000h=00h? since you haven't reburnt the nvram chip?

see if you can change this back to 79h in the hex editor and store that... it shouldnt be allowed due to the firmware write loation limitations

Bernardd · Post by **Bernardd** » Sat Jun 17, 2006 11:39 pm

I looked at my binfile and it's also got 00 at 2000h. If that helps any..... I haven't noticed any problem with how the car is running. I've only tried to connect to consult a few times so far and haven't had any problems.

Stinky · Post by **Stinky** » Sun Jun 18, 2006 12:39 am

I think the only Store operation I had done since burning the chip was a few addresses in the idle timing table. It seemed to work fine. After that all I've done is some logging where I got a few disconnects. I havent installed the new usb connector yet. When I started getting the checksum error I turned off the ecu until I could hear the eccs relay shutoff (probably 10s) and then turned the ecu back on.

I reburned the chip last night and I'll try the ecu again today. It's entirely possible something else is wrong with the ecu/car that is causing the running problem but like you say that address shouldnt change anyway. I'm going to keep an eye on things and see if I can get it to happen again.

Matt · Post by **Matt** » Sun Jun 18, 2006 10:01 am

the reason for putting the checksum in was that i was getting strange consult display data every once often. the car always ran fine however. it was a consult connectivity issue. the rest of the ECU program was still running okay (car worked)

I'm thinking perhaps the AUTORECOVER is not finishing copying EEPROM to SRAM before the ECU starts up sometimes (race condition) and runs from SRAM

For now in the next patch revision/NIStune release version I'll change the checksum error into a warning (consult still stay connected) so we can readback the ROM images after these problems

im going to run my laptop permanently in the car again and try and read back the rom images when this happens to see what is causing it

it is a serious problem which could affect the whole project. hopefully it is nothing too problematic causing it

only changes that should be permanent on the NVRAM are those when the STORE button is hit.

*however the STK15C88 does do an AUTOSTORE if there is enough capacitance on VCC/GND which could be a possiblity. if you can check this by making changes to maps and then turn off the engine (10 seconds) and then restart and see if the changes are still there/gone without doing a STORE/RECOVER from NIStune after a reconcile to PC then you know that AUTOSTORE is happening

The next board uses a STK11C88 which performs no AUTOSTORE at all. I have ordered 75 surface pieces of these chips which will be compatible with the newer rev3 boards (rev2 has a SMD footprint but some of the connections are wrong). The boards will be ordered early next week for these also (three different board types)

bernard - could you please email me your programmed NVRAM file and the ROM output file from NIStune to see if this memory address is meant to be zero for your ECU program in that location or not.

usb connector will not make any difference in this circumstance

2000h is a strange address and since it doesn't appear to be some random location is probably a software error somewhere setting it to 0 (like size of an array is too small or something like that).

because of this, best test to try out is make a map change, STORE it and then repower the ecu. then reconcile and look at that memory location to see if it has changed. we will need to keep monitoring this memory location for abnormalality

as for what happens with bryants particular ecu software on this...

DFFF : 96 79 " y" ldaa X0079
E001 : 84 01 " " anda #$01
E003 : 27 1D "' " beq LE022

turns into

DFFF : 96 00 " " ldaa X0000
E001 : 84 01 " " anda #$01
E003 : 27 1D "' " beq LE022

it effectively makes the statement always jump to E022 and not run any of the code from E005 onwards. this would affect vehicle operation. it could be worse where an insturction code is corrupted and the whole ecu just never runs. that is how serious the problem is. especially if the change was permanent in NVRAM and you didn't have a programmer and you needed the car

btw can you change the 2000h address from the NIStune hex editor with this image? does it say 'written' or does it disconnect?

Stinky · Post by **Stinky** » Wed Jun 21, 2006 2:28 pm

Did some more testing this evening. I was able to change 2000h using the hex editor. It seems to work because when I change it to a value of 12h the car stumbles until I change it back to 00h or 79h. The problem I've run into is that I cant get 79h(the correct value) to stick. I've tried changing the value and shutting off the ecu, burning the changes, loading the original bin, uploading teh current bin to the ecu.

On a side note I think the running problem was from a bad diode possibly. I did some work on the idle circuit and things seem to be running ok.

Matt · Post by **Matt** » Wed Jun 21, 2006 2:44 pm

thats good news is that it is repeatable. i need to sit down and nut this one out. thanks for doing some more testing and posting the log.

i'm reworking the patch code so will update this to fix this problem also once it find it

now time to see if i can do the same thing on my r31 ecu running nvram

Matt · Post by **Matt** » Tue Jul 04, 2006 7:24 pm

I've started looking at this issue last night. I swear cos of winter over hear its like zero degrees in my shed whilst trying to debug this issue!

both of you have said that it keeps changing address 0x2000 to 00 but i can't seem to get this repeated here yet

I cant get 79h(the correct value) to stick. I've tried changing the value and shutting off the ecu, burning the changes, loading the original bin, uploading teh current bin to the ecu

what i need to know, is when does this start sticking? if you performed the following sequence, might help me. I am using 88ss_nt.bin which is the same binary file which bryant sent me, except the maps have changed

0. Turn on logging in NIStune
1. Burn the 88ss_nt.bin file from the Willem to the NVRAM with the capacitor connected
2. Confirm that 0x2000 on readback (without the capacitor connected) is 0x79
3. Put NVRAM in the ECU and connect to consult
4. Perform 'consult read' and then check 0x2000
5. Perform reconciles and other operations which you think may cause the problem
6. Perform another 'consult read' and recheck 0x2000 in the hex editor

to get the changes to stick, normally the 'burn' operation should do this. try changing another 'free' memory address to a known value prior to the 'burn' to ensure the burn worked

power off the ecu 10 seconds, and then switch back on and recheck with ECU download the 'burn' operation worked with the address you set, plus the 0x2000 address

i will try and replicate the issue here also with the 88ss_nt.bin file

i will also be uploading a 88ss_nt.bin pre-rev3 file which will have some memory protection added (only allow changes to maps) soon

if you can send me the log when this happens that would help lots

Matt · Post by **Matt** » Wed Jul 05, 2006 2:09 am

this is the pre-release rev3 witihout address bounds checking file i am using. i will start adding the bounds checking soon

will only work with the innovate test releases of nistune (0.96)

Matt · Post by **Matt** » Wed Jul 05, 2006 11:21 am

on another note i can cause some pretty nasty corruption by writing to the vector table in the hex editor (7ff0-7fff). this seems to make the ecu run nuts as expected, but the problem is that the STK15C88 is also autostoring the corrupted details

i dont know if this problem is related but the existing address bounds checking code isn't functioning as expected and needs updating

Stinky · Post by **Stinky** » Thu Jul 06, 2006 2:32 pm

I'm trying to reburn the chip and I want to make sure it's working right?

After I've burned the chip I'm doing a read without the capacitor connected. When I do this I get my burned image at 0000-3FFFh and nothing but FF from 4000h-7FFFh. Is this correct or should I be getting another copy of the image at 4000-7FFFh?

Matt · Post by **Matt** » Thu Jul 06, 2006 5:08 pm

the NVRAM Programming guide on the website details that you need to program 4000-7FFF

this means using

copy /b image.bin + image.bin image_32k.bin

to make a double size image which then you load into the NVRAM. the bottom half is not used by the NIStune board for rev2 hardware versions

Matt · Post by **Matt** » Thu Jul 06, 2006 5:25 pm

i will be doing some updates tonight to prevent writing to wrong areas of NVRAM to avoid corruption

i will also need to update the Romulator upload sequence to prevent the ECU from running when powered during an upload by clearing the interrupt vector tables first

Stinky · Post by **Stinky** » Fri Jul 07, 2006 12:24 am

Matt wrote:the NVRAM Programming guide on the website details that you need to program 4000-7FFF

this means using

copy /b image.bin + image.bin image_32k.bin

to make a double size image which then you load into the NVRAM. the bottom half is not used by the NIStune board for rev2 hardware versions

I've been programming it the way you instructed but it seems the second half of the chip isnt being programmed. I get OF at 4000h and nothing after that. I guess I'll keep trying. It seems like its hit or miss with the programming so maybe I need a different capacitor.

Matt · Post by **Matt** » Fri Jul 07, 2006 3:18 am

try programming the chip blank and then readback. it should be blank. then you can try the 32K rom image afterwards. i currently use 1000uf but i think it was something like 470uf or greater

the STK11C88s do not keep any corruption at all. will not be using STK15C88s in the future because of these corruption+autostore problems. but programming method will change