Reply to thread

I haven't updated this thread in ages, I wanted to post here to let you guys know that the project isn't dead! I finished my NVSRAM coding a few months ago. This is what allows the ECU to be flashed in situ with no additional hardware modules, and individual byte changes to be made to the ROM while the car is running. I polished it up, added some redundancy and safeties to it so that it would be reliable and commented it as posted here. Quaraxkad has been helping me on the PC interface programming end (the program that is used to send a new ROM file to the ECU) and pending a few minor modifications, his program will be ready shortly.

Here's a quick explanation of whats happening in the code:

To send one byte to the ECU there are 3 command codesm DATA, MSB and LSB:

D0 xx (Data)

D1 xx (Address MSB)

D2 xx (Address LSB and WRITE)

To write data #BB to address #1234, the commands would be as follows:

D0 BB

D1 12

D2 34

Since all addresses within the ECU are 16 bit and the serial port deals in 8 bits at a time, the address has to be split into two parts - MSB and LSB (most/least significant). In case your wondering about why 3 separate commands have to be issued - and the resulting rather long-ish program - I had to work around some limitations of the stock ECU. This ideally would have been inserted into a modified serial routine, but I wasn't able to access or change that routine at all. In order to make this program function correctly I had to insert it in to the kernel loop so that it runs once every microsecond. To make it play nicely with the serial routine (that runs on interrupt and MAY even interrupt this routine) that conveniently places it's received data in RAM, I added some waits and checks to facilitate that safely. The write to the NVRAM doesn't occur until the last command is issued (D2xx) and that part of the program checks to make sure that the other two commands (D0xx and D1xx) were received successfully to prevent invalid data from being written to the ECU.

-Matt