STM32 Hex file not as expected

Sysprogs forums Forums VisualGDB STM32 Hex file not as expected

Tagged: 

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #32468
    lpancoast
    Participant

    When I compile code for a STM32F411CE device, the hex file does not always capture the 0’s that are present in the bin file. This is presenting an issue because when I use the hex file to flash my device, that part of memory isn’t set properly (defaults to 0xFF when erased), which affects a checksum that I’m doing across the memory space. I’ve attached a picture of a spot where my generated hex file does not match the bin file.  Why would VisualGDB not capture those 8 bytes when generating the hex file? Is there a setting I need to enable?

    • This topic was modified 2 years, 7 months ago by lpancoast. Reason: adjusting picture to be within size
    Attachments:
    You must be logged in to view attached files.
    #32472
    support
    Keymaster

    Hi,

    Both hex and bin files are generated from the ELF file using the arm-none-objcopy.exe tool. The .bin file will fill the empty areas with 00’s, while the hex file will actually skip them (that translates of 0xFFs when erasing and programming FLASH). If you are using MSBuild, you can configure VisualGDB to fill the .bin files with 0xFF’s via MSBuild Project Properties -> Embedded Project -> Fill gaps in .bin file with.

    For other project types (e.g. CMake) there is no easy setting to do that, but you can still run arm-none-objcopy.exe manually as a post-build step, passing it the –gap-fill argument with the desired value. You can find more information in the documentation for the objcopy tool.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.