I think Boot Mode is properties of ECU's CPU. CPU have internal ROM and RAM. Microprogram for normal boot and Boot Mode in internal ROM. When we connect pin24 to GND and Power ON we change starting address from normal boot to Boot Mode sequence. Boot Mode for load main program to external ROM (EEPROM) have most of PIC's. But internal ROM is EEPROM too and boot program can be damaged. This case only programmer allow load something to external EEPROM but this not warranty for normal CPU boot and work. Possible need renew CPU internal EEPROM.

Hmmm,

So boot mode is a processor function where by it loads from internal ROM (on processor) EEPROM, which is triggered by grounding the flash pin 24.

So even with the flash chip removed, do you ground the pin 24 pad to do the same?


I've been looking at failed writes here and right now it looks like when the flash is written to, the whole flash is reset to binary value 1 throughout.

The the writing begins, and I'm pretty sure it starts with the last 16kb block of the ECU. I'm not sure if it writes from 7c000 > 80000 hex address, or from 80000 > 7c000 (backwards basically)

This address range seems to be almost unique to all hardware and software on EDC15C2 (checked 1999/2002/2005 cars from Citroen/Peugeot quickly)... with only detail differences in a handful of values (like +/- 5% etc)

Then the main ECU data write begins from address 0 through to 7C000.


I'm wondering, is that last 16kb block the address the CPU uses for 'normal' boot mode? In the case of the ECU I have here it does communicate ok, as I can read the data off and 'see' it via "Galletto", but I can't write as it has a checksum error (protection built into the normal boot software?)


So I'm guessing that the CPU ROM eeprom for boot mode is a 16kb program too, which simply looks to the programmer for the data rather than the flash eeprom chip?

I suppose if the CPU ROM eeprom has damaged data you can still re-program the main flash chip and have a good working ECU, just boot mode if you try load it won't work!?


Hmmm

Dave

In edc15c2 (3 plug) on the table, you need to disconnect the eeprom, because programming is blocked.
Maybe EDC 15C2 (1 plug) is similar.

glapsson wrote:In edc15c2 (3 plug) on the table, you need to disconnect the eeprom, because programming is blocked.
Maybe EDC 15C2 (1 plug) is similar.

on my spare 3 plug ecu to flash on table i had to remove 95p08 immo chip write flash then solder immo chip back on

OK.

I had a friend help me with two ECU's tonight. All bench work.

One was a 306 HDi, 3 plug, 592 hardware number.

Had a bad write, ZIP file, not binary. Oops.


MPPS, no communication in normal mode.

No comm in slow mode.

Opened it up, boot pin, wrote, finished.

Restarted in normal mode on bench, read out binary fine, checked all ok.



Next car

C5, 3 plug 808 hardware.

MPPS, no communcation in normal mode.

No comm in slow mode.

Opened it up, boot pin, wrote, finished.

Restarted in normal mode on bench, wouldn't detect ECU to even read.

Restarted in boot mode, read off data, checked, confirmed ok, good chk, good write.

Restarted in boot mode, wrote random junk file, finished.

Restarted in boot mode, read random junk file, finished, checked ok.

So ECU boot mode was working, processor working fine, flash storing data fine (apparently), but ECU won't see memory out of boot mode.

Restarted in boot mode, re-wrote good original file, finished, restarted in boot, read file, checked again.

Tried comm with Galletto 1250, KWP2000 and MPPS all in normal mode, no joy.

Tried ELM327, no access.

Tried Peugeot Planet/Lexia, no response except from injection module.




At this point I'm really confused.


The history of the ECU is as follows.

Owner wrote file with Galletto. Good file, chk correct etc.

Write stopped at 44%, windows crashed.

He then restarted, communicated with ECU, and got a write with his tool, and the file was indeed only 44% complete (16kb block at end of ECU data, and then 41% ish of the start of the flash area written)


I then said you need someone to fix it, so a local tuner to him used a KESS Titanium whizz bang bollocks tool (not sure if it was a slave or master). The tuner didn't open the ECU, so I assume they just tried to write direct via OBD in 'slow' mode.

After he did that he said it completed fine, but wouldn't start. I asked to confirm with a read of the data and his tool said checksum error and wouldn't read the ECU. Was the file bad? I checked and no it wasn't.

The tuner then said he'd take the car to Peugeot to fix for £80 (haha), but the owner declined that offer thinking more like £800!


Since that point nothing has been able to communicate with this ECU except ONLY in boot mode, where the processor and flash chip happily talk to each other and via k-line.


Next step is solder but I can't understand why the ECU would have a problem unless the flash is just damaged in some way that means it works ok in slow boot mode, but not in fast normal mode?!
Maybe the 'slow' KESS write damaged the memory module in some way!? Maybe this is some weird KESS slave tool protection that works on some other flash memory on the ECU (immo chip, processor flash!?)



So, boot mode does work, very well actually!

But until I understand why this C5 ECU isn't working it might not be a guaranteed fix which is a big shame, as boot mode fix is a 10 min job if you are quick :D



If anyone has any clues to why the C5 isn't working I'd love to hear your thoughts :)


Cheers

Dave

Possible this help you:

Hmmm, that is quite interesting.

Still not sure what might be wrong though since one 3 plug ECU worked ok, the other didn't.


Something has changed or is different on this ECU, and now I'm worried it's internal readable ROM memory on the CPU that is either damaged or configured incorrectly somehow.
Someone mentioned internal ROM may be damaged but that would cause boot mode to not work, only read from flash. But in this case it's like it's stuck backwards. Boot will work, but read from flash won't.

Maybe a software toggle for boot/flash mode inside the CPU is stuck in the boot setting?!


All this is quite over my head now... more tinkering required to see if it'll come back to life!



Does anyone have any dip8 data dumps from this ECU that I can compare against. Starting to think if I can get a read off that and check it's in good order then I might be getting somewhere (ie, check it's not scrambled or something)

PS, which is the correct dip8 flash chip on the back of the ECU, there are two on this one and now I'm confusing myself if that is the case on all of them or not.


Cheers

Dave

Thank you very much.

Another learning curve about to start here dipping into the 8 pin flash :D

Dave

Can pick it up if you like to have a go, i've not had a chance to look at it apart from boot flashing a couple of times. All logical causes are pointing at wrong software to me. The processor is working, the bus is working, the eeprom integrity is good, the ecu won't otherwise wake. So logically speaking I'd have to suspect a firmware mismatch but with not much info on the ecu cover there's not a lot to go on.data

I doubt soldering will acheive much because the memory has been read off via bootpin and is intact. Funny one.