cancel
Showing results for 
Search instead for 
Did you mean: 

Embedded bootloader failed to program the whole image to user flash memory.

xuchungang
Associate II
Posted on September 06, 2016 at 10:53

Hello,

I'm trying to program my application to user flash memory (0x08000000) via the DFU mode with the embedded bootloader. However, the application is always programmed incompletely. See the attached picture.

There is still some data after 0x0800A807 like below ( captured from the .hex file ).

:10A804001838F1071CF7068000F8C61850F1001C30

:10A81400F2020888611CF201021C62011CFD02D1D3

:10A824000431548204A8613C92071CF20A801C2162

:10A8340015921250A2041CF20A021CF20A201CF205

:10A8440006401C4E0848038312008C79B04E084819

:10A8540003F1071C83000854294C920654F30600A4

:10A86400101CFA0100A0A20A1CF20A101CFA0640ED

:10A874004C460018E102711CF20A0454F206201C32

:10A88400FA0508BC611CFD082C03FE0A08EC04460A

:10A8940008DCE1027550F107C4861034D30100A826

......

I am using STM32L486. Has anybody already got this problem? or has some idea about this?

Thanks in advance.

5 REPLIES 5
Posted on September 06, 2016 at 13:29

I would probably review the DFU creation process, and validate that the DFU to HEX mode provided back what I had supplied as input

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Walid FTITI_O
Senior II
xuchungang
Associate II
Posted on September 07, 2016 at 04:43

Thanks, clive. 

I did re-generate the HEX from the DFU. The new HEX looks same as the original one.

I found this problem when I am trying to upgrade my own boot program via the embedded bootloader. I also found another strange thing is sometimes the embedded bootloader can't upgrade my application program starting from 0x08010000. The reason looks same that verification failed. But my own bootloader can do this!

The following words are from section 5 of  UM1879: STM32L4 Discovery kit manual. Not sure whether this could be the root cause.

 

The following limitations exist in the bootloader V 9.0:

 

1. RAM data get corrupted when written via USART/SPI/I2C/USB interface

 

Description:

 

Data write operation into RAM space via USART, SPI, I²C bus or USB results in wrong 

 

or no data written.

 

Workaround:

 

To correct the issue of wrong write into RAM, download STSW-STM32158 bootloader 

 

V 9.0 patch package from www.st.com and load ''Bootloader V9.0 SRAM patch'' to the 

 

MCU, following the information in readme.txt file available in the package.

xuchungang
Associate II
Posted on September 07, 2016 at 08:46

Found the root cause in section 46 of AN2606:

For memory write operations using DFU interface: 

 

If the buffer size is larger than 256 bytes and not 

 

multiple of 8 bytes, the write memory operation 

 

result is corrupted. 

 

Workaround: if the file size is larger than 256 

 

bytes, add byte padding to align it on 8-bytes 

 

multiple size.

 

Write in SRAM is corrupted.

After manually aligning the HEX on 8-bytes before generating the DFU, then DFU upgrade succeeds. 

Walid FTITI_O
Senior II
Posted on September 15, 2016 at 10:39

Hi xu.ross,

Thans for sharing your finding.

-Hannibal-