AnsweredAssumed Answered

ST-Link Utility HEX bug ?

Question asked by mjbcswitzerland on Jun 19, 2015
Latest reply on Jul 31, 2015 by Clive One
Hi All
Using ST-Link 3.6.0 to download a HEX file to an STM32F407 board I found that the loaded code sometimes didn't run. But, if I loaded the BIN version instead it was OK.

After some investigation I found that the HEX file sometimes had lines like this:

:10AAC0004100546F3A20000D0A5375626A65637441
:10AAD0003A20000D0A46726F6D3A20000D0A2E00D2
:0FAAE00005060C181C3C082008001100015180CD   <----
:10AAF000746573745F6E616D6540746573742E6305
:10AB00006F6D000000000000000000000000000069
:10AB1000000000000000000000FFC29EE50B0000E6

Notice that most lines are 0x10 bytes in length but one is 0x0f. There is in fact a single byte "hole" in the object.
After loading with ST-Link and successful verification the code would not run. Debugging the case it was found that the line
:10AAF000746573745F6E616D6540746573742E6305
is not programmed in Flash to 0xaaf0 as expected but is programmed to 0xaaef - where the 'hole' should be.
The result is that the program content after this line is shifted by one byte. In the investigated case the content was const values but when the program accessed them they were one-off and in the case of critical values it would lead to the code failing.

As I wrote - if I load the BIN instead of the HEX the code is correct in Flash.
Aslo, I don't always get the 'hole' in the code (it is due to consts being aligned to a long word boundary) and then all works too.

Is this a known issue with the tool??

Regards

Mark


Outcomes