bin file is gigantic, hex and elf files are normal, when defining a section of RAM in STM32F765VITx

[BobbyBeta]

I'm trying to define a region of RAM for storing debug information that can persist following a reset (DEBUG_RAM). I'd like to put variables in a section (.debug_ram) that are stored in the DEBUG_RAM memory such its usage properly displays in the Build Analyzer.

When I do this my elf and hex files are a normal size, 1.3MB and 15kB respectively. My bin files, however, are 393MB. Unfortunately the company I work for has standardized on bin files, particularly for their bootloader software.

I have attached my modified linker file (renamed STM32F765VITX_FLASH.ld.c so that it can be attached to the forum) and main.c where I locate the debug_ram_test variable in the in the .debug_ram section. When I build the build analyzer window correctly shows that 6.25% of the DEBUG_RAM region is used.

If I use a bin-to-hex utility to convert the bin file I see it's almost all data records with all of the data equal to zero, interspersed with Extended Linear Address records outside the range for the FLASH for the MCU. Here is an example:

:10FFC000000000000000000000000000000000000000000000000000000000000000000031
:10FFD000000000000000000000000000000000000000000000000000000000000000000021
:10FFE000000000000000000000000000000000000000000000000000000000000000000011
:10FFF000000000000000000000000000000000000000000000000000000000000000000001
:01000004FF0FED
:100000000000000000000000000000000000000000000000000000000000000000000000F0
:100010000000000000000000000000000000000000000000000000000000000000000000E0
:100020000000000000000000000000000000000000000000000000000000000000000000D0
:100030000000000000000000000000000000000000000000000000000000000000000000C0 

I'm really hoping that I'm doing something dumb that I can fix, but I've done this on lots of projects before and probably never noticed because I only used hex files.

[KnarfB]

hex and elf formats can hold the bytes in several chunks or segments, bin cannot. Bin contains all the values between the lowest address and the highest. There is no way to change. Keep in mind, that even if your debug info persists after a (warm) reset, the content will be lost when the power goes down. Writing zeros to inbetween addresses might even cause side effects.

If the format really cannot be changed, you may add some startup code, actively copying the debug info from a global const (read-only) variable to the target adddess (or let a secondary bin file do so).

hth

KnarfB

[BobbyBeta]

The MCU only has 2MB of Flash so a 393MB bin file doesn't make sense. If I try to load the file in STM32CubeProgrammer it says that it's too big.

If I simply remove __attribute__((section(".debug_ram"))) from debug_ram_test in main.c, the bin file reduces to 6kB. It really shouldn't have an effect on the bin size where the variable is located in RAM but it does.

Long term I do plan on looking at the RCC->CSR register to determine the cause of reset before trusting the data in the .debug_ram section. I may use a CRC as well.

For now, however, I seem to get non-sensical bin files when I build with gcc and that's the first step.

[Tesla DeLorean]

Large because the file tries to put data from RAM into the BIN file, ie spanning 0x08000000 thru 0x20000080 (384MB). Binaries can't be sparse. Other tools would split to multiple binaries.

Stop putting data in RAM that needs to be staged in FLASH and moved there via code in startup.s

Check .MAP file, or dump .ELF object with objcopy

[Tesla DeLorean]

Could make DEBUG_RAM as a NOLOAD region if you don't want data initialization there.

[BobbyBeta]

NOLOAD seems to have worked!

With my debug variable in the DEBUG_RAM region I'm now getting a 6kB bin file!

Thank you so much for this!