Just came across some nasty hex images in ST's CubeMX packages:
STM32Cube_FW_F4_V1.17.0/Projects/STM32469I-Discovery/Demonstrations/STemWin/Binary/STM32469I-Disco_Demo_V1.2.0_FULL.hex
STM32Cube_FW_F4_V1.17.0/Projects/STM32469I_EVAL/Demonstrations/STemWin/Binary/STM32469I_EVAL_Demo_V1.2.0_FULL.hex
STM32Cube_FW_F7_V1.8.0/Projects/STM32F769I-Discovery/Demonstration/STemwin/Binary/STM32769I-DISCO_DEMO_V1.0.0_FULL.hex
STM32Cube_FW_F7_V1.8.0/Projects/STM32F769I_EVAL/Demonstration/STemWin/Binary/STM32769I-EVAL_DEMO_V1.0.0_FULL.hex
STM32Cube_FW_H7_V1.1.0/Projects/STM32H743I_EVAL/Demonstration/Binary/STM32CubeDemo_STM32H743-Eval_V
1.1.0_FULL.hex
Apparently they were produced by simply concatenating two hex files
built separately. Each part has its own end record ... And openocd (and
e. g. GNU objcopy as well) happily stops reading at the very first one
--- without complaining.
Quite trivial to fix, of course, however, point is whether to handle
this gracefully (like ST-Link utility does) or to reject the file as
invalid?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
