pcmhacking.net

I have couple questions

My car is Daewoo Lanos 1.5L Euro II. ECU installed is KDAC with ZXJN program id.

The question is how do reflash that ECU?. Is it wossible at all? I found no info about ALDL modes which allow flash writing. The ECU fully supports 0,1,2 4 which I tested.
How your program writes flash. I couldnt see that because my ECU not recognised by it.

My guess that ECU should support mode wich allow to write RAM and execute it, then loader will reflash ECU.

What year is that ECU? Most our testing here is currently with early 90s australian delco ecus, which have a 16bit architecture allowing 64kbyte of address space max (without bank switching, which is done in the VS commodore ecu to allow 128k of data).

If your car is a 2000 model, then the ecu is probably a newer style. It would be great if you could post some pics of it or any info about it. Not much info is public about most euro gm ecus, but feel free to hang around and ask questions and we'll help all we can if you want to figure it out.

This flash tool uses the processors write feature, but that will not work with a standard memcal on eprom. We replace the eprom with nvram, wire the write line if it is not connected, and patch the binary to support a non-official write command. Newer ECUS dont need this as they have flash memory allready, and the process is closer to what you said - unlock the ecu security, upload a flash writer to its ram and execute it, then send the new binary over.

L2-Max wrote:Thanks for you work but smalest problem exists.

The read timeout between arrival of two bytes is small. I'm using adapter on ftdi chip and coudnt read any dump of memory. I have run PORTMON NT which capture adapter port and I see that your program has been interrupted by timeout every request it do. It reads not fully data which my ECM transfer.

Thanks for the bug report I have had this issue in the past and made a program change to correct it, you can use the 'Comm Timeout' option in the preferences to adjust the timeout. Maybe the timeout needs to be made larger than the default in your case.

Let me know how you go.

Portmon log in attacment. There is GetCal request. I did it on my PC with ECU emulation. I purposely set 1 - 10 msecs (randomly) between bytes to forse problem.

By my expirience with my ECU the reading timeout is 1000. / baudRate * bitsPerFrame + constant. (read MSDN for COMMTIMEOUTS::ReadIntervalTimeout field).

Note: if wait for silence is > 0 then program have no time to read any packets on real ECU I think it is caused by ReadIntervalTimeout == -1 and ReadFile functions returns immediately if any bytes in the buffer.

Thanks, I had a look at the log but cannot see where its failing? Have you tried adjusting the preferences for comm timeout?

The wait for silence is only for before a request is made to stop or start chatter, this is done at the start and end of a read or write function and is used to stop the BCM or ABS from communicating. If you uncheck 'Disable Chatter' The wait for silence is not used.

antus wrote:What year is that ECU? Most our testing here is currently with early 90s australian delco ecus, which have a 16bit architecture allowing 64kbyte of address space max (without bank switching, which is done in the VS commodore ecu to allow 128k of data)

My car is 2007 year. Poland (FSO) manufacturer. VIN SUPTF69...........

I'm not familary fith microcontrollers but what I found:
There is 68HC11 8bit microcontroller (but I'm not sure).
There is flash memory installed.

I attach original prom image for my car.

I want to know is there ALDL mode to download image exists or FlashTool uses some loader to reflash ? What is the mode ?

The flash tool uses either mode 11 or mode 12 - mode 11 writes in 8 byte blocks and mode 12 in 128byte blocks. These are ALDL modes that have been added, they are not part of a factory GM ECM code.

The bin you have attached looks like HC11 code, can see in the init area that it sets the stack to 0x03FF (so thats the size of RAM). But what modes, would have to disassemble the bin for that really.

VL400 wrote:Thanks, I had a look at the log but cannot see where its failing?

Look start from 41 packet. You send request then you start to read echo. Read only 2 bytes then abort serial line. It means adapter has no time to reply. It is appears aon most packets ant not only while echo sent.

Then look at 36 packet. RI:-1 RM:-1 RC:60 WM:0 WC:60
What MSDN says:

If an application sets ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD, one of the following occurs when the ReadFile function is called:



If there are any bytes in the input buffer, ReadFile returns immediately with the bytes in the buffer.
If there are no bytes in the input buffer, ReadFile waits until a byte arrives and then returns immediately.
If no bytes arrive within the time specified by ReadTotalTimeoutConstant, ReadFile times out.

Looks like first case is your, but I cant excactly determine problem because I don't know how you process replies.

That's timeouts which I set in my tool RI:37 RM:20 RC:0 WM:20 WC:50

If you interest full source code and binaries
http://depositfiles.com/files/90q7ppp5e or http://filestore.com.ua/?d=F540E4713
and disscussion http://lanos.com.ua/forum/viewtopic.php?f=71&t=28615 in russian, sorry

VL400 wrote:The flash tool uses either mode 11 or mode 12 - mode 11 writes in 8 byte blocks and mode 12 in 128byte blocks. These are ALDL modes that have been added, they are not part of a factory GM ECM code.

The bin you have attached looks like HC11 code, can see in the init area that it sets the stack to 0x03FF (so thats the size of RAM). But what modes, would have to disassemble the bin for that really.

All is clear ... only loader will resque me

I read M68HC11RM document from frescale. I found Boot loader listing. There is a comment:
* THIS BOOTSTRAP PROGRAM ALLOWS THE USER TO
* DOWNLOAD A PROGRAM OF EXACTLY 256 BYTES.
* THE PROGRAM MUST START AT $0000.
* EACH BYTE OF THE PROGRAM IS RECEIVED BY THE
* SCI, STARTING WITH THE $0000 BYTE AND WORKING
* UP TO THE $00FF BYTE.

reading listing I see set BAUD tu 8192 and wait for FF byte to start download ...

Why boot loader sets stack to 0x0FF if memory up to 0x400?

Does somebody use that loader to download user program into RAM (I mean - does realy work?)?.