devo7e: .bss variables in .mod getting corrupted

Hey Forum

I'm getting some erratic behavior in a protocol I'm developing when I do various things that ought to not have any effect on anything (adding some parameters to the end of the protocol_opts structure which aren't yet used, for example). The only common denominator I can come up with is that the changes that cause my problems adjust the code layout and I wonder whether I'm crossing sections in the linker map or something.

Also, this is for a devo7e so protocols are compiled out into .mod files.

Are there size or layout restrictions on the .mod binaries?

the .mod's have a size limit of 4kb iirc

Ah yes, I recall the 4kb restriction. That's a hard compile-time requirement though; if I blow past 4k it won't link.

So, the plot thickens a little: In my state machine, I have a local static variable (u8) that I set to zero. In one of the later states, the value is assigned based on the payload of an ACK packet. In a state after that, the value is re-used. I noticed through some tracing that when I went to use the value I read, it was appearing totally bogus. SO I decided to assign the value to a known constant at init. The code changed from "static u8 toc_size = 0" to "static u8 toc_size = 1". This change alone caused the following compilation error:
What's going on with that?! What does that error mean? My only guess is maybe I'm riding on the edge of the .bss section, size wise, but I don't seem to find any restrictions on how big that can be.

My code is here:
github.com/theseankelly/deviation/blob/w...flie_nrf24l01.c#L391

Here's my linker map for the binary that's produced, but doesn't work (where several of my local statics appear to be getting clobbered).

The map shows them in the bss section as expected, toward the end. My 'toc_size' variable is sitting at an offset of 3294bytes from the start of the RAM section (0x20004000) Do we definitely have a full 4k of RAM to play with for these modules on the devo7e?

False alarm. It's due to this:
. = _data_start; /* Ensure there is no data section, since initialization won't happen */

Looks like you can't use initialized globals in a protocol.

Back to the drawing board on debugging my *actual* problem..

I've updated the title of the post since I have a better idea of what I'm dealing with now.

Basically, it appears some globals (local statics, technically) which link into the BSS section are getting corrupted. Some questions:
1) Any hints on how to debug?
2) Where is bss loaded when a .mod is loaded? Is it still under the stack and subject to stack overflow?

One more data point: I've changed my function local globals to ordinary globals declared outside the function. The problematic behavior in my code goes away. The linker map still has them in .bss though in roughly the same order as before.

Edit: I guess I should say, it either fixes the problem, or moves my code around in such a way that it masks the problem again..

Is there some nuance to how the linker handles function local statics that gets messed up when loading a module?