.bss section taking up flash space?

[ron239955_stm1]

Hi all, I have an STM32H743 project that I've been working on. I've worked on a fair amount of projects in STM32CubeIDE in the past, but now I have a problem I haven't encountered before: the linker is putting my .bss section in flash as well as RAM. I'm not sure why an uninitialized section would be placed in flash... I've attached the output from the build analyzer as well as my linker script. The script is almost the default, except that I've added D2/D3 RAM and have moved stack & heap to DTCM. I've used very similar scripts in other projects and BSS ends up only in RAM in those projects.

Can anyone find what I'm doing wrong? Thanks!

 

[Pavel A.]

Can you show any of your other "good" .ld files?

These lines outside of sections blocks  are suspicious:

 . = ALIGN(4);

 

[Tesla DeLorean]

Not sure I'd rely on the memory view to understand what's actually happening

Use an ELF dumping tool like OBJDUMP, OBJCOPY or FROMELF, see what's getting into BITS / NOBITS sections. How large the .BSS foot-print in FLASH actual is vs the amount of RAM being cleared.

The .MAP might also help understand what's going on.

I don't have the fortitude or motivation to fight the .LD syntax and ordering for you, that'll need to be your battle. But it's likely to be something to do with the ordering and attributes that the linker thinks it's working with. It's not using a "best fit" or "multi-pass" approach, but for the most part a linear traversal of rules.

[Pavel A.]

Right! Humans should not edit manually makefiles and .ld scripts. In the AI era, this will be beyond capability of a typical human very soon ))

[Tesla DeLorean]

Well, at the very least it's extremely frustrating, and I'm not looking for unpaid tasks. The GNU/LD could have a book written on them. I've written linkers in the past, so I'm not unfamiliar with the goals, it just makes dealing with intractable ones more frustrating.

The Arduino implementation at least constructs it's own scatter tables.

The Keil Scatter files and load regions are far less frustrating. And my tools of choice. Still, working set optimization is something I'd opt to automate rather than attack manually.

[ron239955_stm1]

Here's an .ld from another project that does the right thing with the bss section. This other project didn't need as much memory, so I didn't need to add D2RAM/D3RAM sections. 

If there's no obvious error to point out, I'll have to dig into this further. I know next to nothing about the .ld format, so I guess it's time to learn!

 

 

[Pavel A.]

Again - try to remove lines " . = ALIGN(4);" that are not within any { section }

(lines 139, 155).

 

[ron239955_stm1]

Thanks for catching that, not sure why that isn't flagged as an error. Unfortunately, it doesn't seem to help.

I started going through documentation, and tried some things. In the end, it appears that Tesla D. is right - it's all in the order. Putting the .bss section before .data in the file fixed it. It appears that, because .data is placed in both RAM_D1 and Flash, any section that follows it that is placed in RAM_D1 is automatically also placed in Flash.

Weird, though, that my other project's linker script works fine and it has .bss after .data. 

I'm going to forge ahead, cautiously optimistic, with what I've got and see what happens. Fortunately, this project has a long way to go before production.

Thanks everyone!

 

[Pavel A.]

> ALL of them fail to find the issue. 

Maybe because they are hard-locked to be polite and abstain from comments about bss on flash? They probably think, well, those humans have unicorns, dragons and Santa, why not bss in flash?

Machines are still "garbage in, garbage out" things.

 

[KaiY]

I ran into the same issue, and it turns out the .bss section does not actually take up space in flash as reflected in the binary/executable output files

It is a bug with the build analyzer, and possibly others. Since the linker assigns this section an LMA in FLASH due to a previous section having a VMA in the same memory region whose LMA is also in FLASH i.e. data section (this may be a linker bug or a quirk of the linker), the build analyzer erroneously determines that this region takes up space in flash.

Or select the .elf instead of the .map when using the build analyzer.

[Pavel A.]

> Or select the .elf instead of the .map when using the build analyzer.

How?

 

This usually happens if the .bss section has a LOAD attribute pointing to flash. Double-check your MEMORY regions and section mapping — .bss should only have a NOLOAD in RAM without a flash load address.