Flash Loader Demonstrator Crash / AN3155

[cschumann]

Posted on April 20, 2010 at 09:58

Flash Loader Demonstrator Crash / AN3155

[cschumann]

Posted on May 17, 2011 at 13:47

After compiling the FlashLoaderDemonstrator myself and debugging it, I found the cause of the crash. The parameter -i seems to be required but it is not checked in the app.

Nevertheless, I am still unable to upload images from my device or download them:

>STMFlashLoader.exe -p --pn 2 -i STM32_High-density_512K -u --fn tmp.hex

 UPLOADING ...

Uploading        page 0          @0x  8000000    size 2.00(KB)   [KO]

 Press any key to continue ...

[cschumann]

Posted on May 17, 2011 at 13:47

After some further investigation I canceled the FlashLoaderDemonstrator project and started to implement my own bootloader based on AN3155 because there are more cons than pros with the ST FlashLoaderDemonstrator sample app.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:47

This syntax (ie -c not -p) worked with V2.0.0

STMFlashLoader -c --pn 2 -i STM32_High-density_512K -d --fn DOWNLOAD.HEX

You are correct about -i, if you don't specify it the app faults on a NULL vector.

-Clive

[cschumann]

Posted on May 17, 2011 at 13:48

Actually I am struggling with the checksum. AN3155 mentions a XOR checksum, but it seems like a NXOR checksum to me (i.e. command and complement). For some cases, the checksum is correct, but the download of data to the device fails with a NACK after sending the datalength+data+checksum.

Do you know how the ''checksum'' is exactly calculated and if the datalength (when downloading) is involved in the checksum?

Carsten

[Tesla DeLorean]

Posted on May 17, 2011 at 13:48

After some further investigation I canceled the FlashLoaderDemonstrator project and started to implement my own bootloader based on AN3155 because there are more cons than pros with the ST FlashLoaderDemonstrator sample app.

 

Came to the same conclusion, the protocol is pretty simple. If you only have to support one device and need a custom user interface for factory test/program starting from scratch would be easier than modifying the example code.

-Clive

[cschumann]

Posted on May 17, 2011 at 13:48

Thanks, damh,

this solution works for me for all but the WRITE_MEMORY commad. There I get a NACK after sending the data.

After some sniffing on the serial port I can confirm that the computed checksum is correct (the same checksum is sent by the FlashLoaderDemonstratorGUI).

When the c# library is finished, I will publish it on my Homepage.

Carsten

[damh]

Posted on May 17, 2011 at 13:48

The internal bootloader does it like this:

data size=1 byte => checksum = data[0] ^ 0xFF;

data size>1 byte => checksum = data[0] ^ data[1]^...^data[size-1]

I suppose, that the other bootloader does it the same way.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:48

For the Write

31 CE

   79 [ACK]

20 00 00 00 20

   79 [ACK]

0F 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 0F

   79 [ACK]

Where 0F^00^11^22^33^44^55^66^77^88^99^AA^BB^CC^DD^EE^FF = 0F

and 20^00^00^00 = 20

[Tesla DeLorean]

Posted on May 17, 2011 at 13:48

For the read

Send

0000 : 11

Send

0000 : EE

Receive (ACK)

0000 : 79

-------------------------

Send

0000 : 1F

Send

0000 : FF

Send

0000 : F0

Send

0000 : 00

Send

0000 : 10

Receive (ACK)

0000 : 79

-------------------------

Send (N)

0000 : 0F

Send (N ^ 0xFF)

0000 : F0

Receive (ACK)

0000 : 79

Receive (N + 1)

0000 : 00 02 00 20 21 F0 FF 1F 45 F7 FF 1F 47 F7 FF 1F

-------------------------

The address is self contained with it's own XOR sum

For Address 0x20000000 the 5 bytes are 20 00 00 00 20

For Address 0x1FFFF000 the 5 bytes are 1F FF F0 00 10

ie 0x1F ^ 0xFF ^ 0xF0 ^ 0x00 = 0x10

This is used for all DWORD parameters

The length is sent as N, N ^ 0xFF

And it returns 0x79, then N+1 bytes from memory

[damh]

Posted on May 17, 2011 at 13:48

At which address do you try to write?

First 2 or 4 pages can be written only after mass erase until first reset. After that they are writeprotected.