How does the flash kernel get executed? - Safety of flashing

Developer topics relating to software that reflashes or modifes ECU code and data

Moderator: Freon

How does the flash kernel get executed? - Safety of flashing

Postby JimbobUK » Sun Feb 12, 2006 4:35 am

Hi Colby etc...

Is there any thread that addresses how the reflash process actually works?

I would like to know:

1) What state is the 68HC16 in with the ignition OFF? Is it powered down, or in some sort of stdby mode, or actually executing code? (for my following questions I assume it is powered down)

2) What happens when the ignition is turned ON? Does the HC16 execute code from it's reset vector? Is this the stuff at the beginning of the image that ECUFlash reads? Or is the TPU involved somehow?

3) Presumably the flash kernel is written into RAM somehow... Is the HC16 still executing code while this is written in, or are you instructing the TPU to halt the HC16, and then vector to the kernel afterwards?

4) Which processor HC16 / TPU implements the SSM protocol?

5) Where it the TPU code stored (is this part of the image that we read / write)?

6) What is actually on the ECU board? Are there any memory mapped devices (FPGA / CPLD / ASIC ect), which could impose a H/W version compatibility issue with F/W upgrade?

One of the visualisations in my mind is that the TPU masters the HC16, and is executed from reset... Implements the SSM protocol... Verifies the HC16 code, and brings the HC16 out of reset when it determines the code is OK.

What I'm really after is to know whether I flash a newer F/W image to the ECU, and some sort of H/W compatibility issue occurs, and the ECU locks, will some other processor (TPU?) still implement the SSM protocol such that I can get back in and re-write the flash?

Heeellllppp, as this is the main issue worrying me from writing a new flash image to my ECU!
JimbobUK
 
Posts: 36
Joined: Thu Sep 29, 2005 12:28 pm

Postby JimbobUK » Sun Feb 12, 2006 5:42 am

By the way, here is a pic of my ECU (AF530)...

Does anyone know what IC602 is ("ESPC")?

Does anyone know what IC603 is (44 pin quad jobbie in the middle)?
Attachments
AF530_pcb.jpg
AF530_pcb.jpg (1023.94 KiB) Viewed 5162 times
JimbobUK
 
Posts: 36
Joined: Thu Sep 29, 2005 12:28 pm

Re: How does the flash kernel get executed? - Safety of flas

Postby cboles » Mon Feb 13, 2006 9:35 am

1) I haven't done any tests, but I assume it is in a RAM standby mode, not executing. I hits the reset vector again on power up.

2) Yes

3) The TPU is not really running on this ECU. The ECU is just using the TPU flash area as place to store the kernel boot loader code. The ECU is executing the code here when you are uploading the kernel to RAM, and then transfers control to the kernel if the checksums look right. The reason for doing this is that it is a seperate flash block, and won't get erased during the reflashing process, thereby protecting the bootloader. Depending on the model and situation, this doesn't necessarily protect you from rendering the ECU unresponsive with a bad reflash though.

4) There are definitely HW incompatibilities as some level because some ECUs support additional sensors.

5) The TPU flash area is at 0x60000. The newer flash tools don't bother reading it as I have found that it hasn't changed much. It also doesn't exist on the newer ECU CPUs.

6) Most likely this will not happen if you are using code from a similar model year. But yes, it can happen. I have not had it happen. As long as the CPU uses the same SCI pins and a few other things, it has a godd chance of being happy enough to stay communicative. I mostly work from a bench programming setup where my ECUs only have power, ground, the test mode pin, and the K line connected.

Colby

JimbobUK wrote:Hi Colby etc...

Is there any thread that addresses how the reflash process actually works?

I would like to know:

1) What state is the 68HC16 in with the ignition OFF? Is it powered down, or in some sort of stdby mode, or actually executing code? (for my following questions I assume it is powered down)

2) What happens when the ignition is turned ON? Does the HC16 execute code from it's reset vector? Is this the stuff at the beginning of the image that ECUFlash reads? Or is the TPU involved somehow?

3) Presumably the flash kernel is written into RAM somehow... Is the HC16 still executing code while this is written in, or are you instructing the TPU to halt the HC16, and then vector to the kernel afterwards?

4) Which processor HC16 / TPU implements the SSM protocol?

5) Where it the TPU code stored (is this part of the image that we read / write)?

6) What is actually on the ECU board? Are there any memory mapped devices (FPGA / CPLD / ASIC ect), which could impose a H/W version compatibility issue with F/W upgrade?

One of the visualisations in my mind is that the TPU masters the HC16, and is executed from reset... Implements the SSM protocol... Verifies the HC16 code, and brings the HC16 out of reset when it determines the code is OK.

What I'm really after is to know whether I flash a newer F/W image to the ECU, and some sort of H/W compatibility issue occurs, and the ECU locks, will some other processor (TPU?) still implement the SSM protocol such that I can get back in and re-write the flash?

Heeellllppp, as this is the main issue worrying me from writing a new flash image to my ECU!
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby JimbobUK » Mon Feb 13, 2006 11:39 am

Thanks very much for the detailed reply Colby :-)

So I take it that the SSM protocol is implemented straight off the SCI interrupt (or perhaps queued to a scheduler)? Is this brought up very soon after reset?

What command do you send to make the ECU branch to the kernel loader (in the TPU flash)?


Probably a really dumb question, but I had originally assumed that the program flash memory was internal to the HC16, but from the Freescale HC16 variant comparison page, none of them seem to have much flash. Are those two 24 pin dil packages (IC 802, 803 on my PCB) flash memory?

What is the the 44 pin IC603 next to these ICs?

Have you (or anyone else out there) ever 'bricked' an ECU? If so, have you ever used a hardware method of programming back a valid image to the flash? (Such as removing the flash and programming it)?

Just out of interest, have you ever thought of adding an option to ECUFlash to only write to flash blocks from 0x28000 -> 0x2FFFF perhaps? To avoid risk of corrupting the program code.

Once again, thanks very much for your patience with us novices. Hopefully I'll be able to contribute to the project when I have gained a bit more knowledge in the area! :-)

James
JimbobUK
 
Posts: 36
Joined: Thu Sep 29, 2005 12:28 pm

Postby cboles » Mon Feb 13, 2006 11:52 am

* protocol is implemented off of the SCI interrupt
* the commands for the kernel loader are somewhat complex. there are seed/key challenges in some cases. take a look at the source code i have published.
* the flash is internal
* i have never removed the chip to flash it in eeprom mode. there are other supported reflash modes on some chips that can be done via serial. i have done this.
* ecuflash only reflashes the blocks which have changed, so if you only want to flash that area, just only change that area.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA


Return to Reflashing Software

Who is online

Users browsing this forum: No registered users and 5 guests