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

[xuchungang]

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.

[Tesla DeLorean]

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

[Walid FTITI_O]

Posted on September 06, 2016 at 15:59

Hi vovk.dmitriy,

As a start, I recommend to check the

http://www.st.com/content/ccc/resource/technical/document/user_manual/3f/61/72/ff/c5/5a/4a/7b/CD00155676.pdf/files/CD00155676.pdf/jcr:content/translations/en.CD00155676.pdf

'' Getting started with DfuSe USB device firmware upgrade STMicroelectronics extension'' and download

http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-stm32080.html

-Hannibal-

[xuchungang]

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]

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]

Posted on September 15, 2016 at 10:39

Hi xu.ross,

Thans for sharing your finding.

-Hannibal-