ST-Link Utility HEX bug ?

[hpipon957]

Posted on June 19, 2015 at 19:15

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 #st-link-hex-bug

[Tesla DeLorean]

Posted on June 19, 2015 at 20:38

Is this a known issue with the tool??

I've seen it reported here before, might dig for a cite. Seem to be several broken tools on the site for quite some time. This is one of those insidious problems one would have hoped was addressed promptly.

[Tesla DeLorean]

Posted on June 19, 2015 at 20:56

Here's the one I remembered

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/St-link%20Error%20in%20HEX%20parser&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=60

I'm going to push this up to moderation.

[hpipon957]

Posted on June 20, 2015 at 14:36

Hello Clive

Thank you very much - I did a search to see whether it was a known issue but didn't hit the post that you linked to. However it is indeed

exactly the problem

. In fact it is a very serious issue in such a tool since it is obviously not using the HEX addressing correctly and just seems to be linearly writing to Flash. Hope it will be corrected to avoid others losing time debugging the same issue which turns out to be a tool error rather than a SW error! Regards Mark

[pmoore]

Posted on June 25, 2015 at 19:32

This is very interesting as I have used the command line version to program tens of thousands of STM32Fxxx parts without seeing this issue. 

I wonder if it is specific to the environment the GUI utility is running in?  (I do use the GUI utility, but only a few hundred cycles per year.)  In the last five years, I've never had a HEX file fail to load for this issue.

[Tesla DeLorean]

Posted on June 25, 2015 at 19:52

Probably depends more on the tools generating the .HEX, and if it creates voids.

ST hasn't responded to anyone, and I'm not going to do regression testing on it, to understand when it was broken, or if it ever worked.This is generally why I write my own programming software, as blaming someone else doesn't put out fires on the production floor.

[yaredbw]

Posted on July 30, 2015 at 23:06

I don’t know where to report this but I tried ST-Link V3.6 to load hex file, it didn’t work and I downgrade it to V3.5, it is working. It seems like the problem with v3.6 is when it reads hex files, some of the bytes shifted by one to the left.

Regards

[Tesla DeLorean]

Posted on July 31, 2015 at 01:52

Have you tried v3.7?