Throughout the codebase the PLACE_IN_SECTION macro is used to place bluetooth related static variables into their own sections. I guess this is done increase the isolation from possible errors in other parts of the code.
The sections (for example "BLE_DRIVER_CONTEXT", "BLE_APP_CONTEXT") are not mentioned in the linker script, so the linker places them on it's own.
Because of this the sections created are not assigned to the .data or .bss segments. This has two implications:
- Zero initialized static/global variables (that normally reside in .bss) take up equal amounts of ram and flash. (In .bss they actually only take up ram, since it's not neccessary to store explicit 0 initializer values)
- static/global variables are not initialized at all. Since the sections are neither in .bss or .data, neither zero initialized nor explicitly initialized data sections are copied from flash to ram by the startup code.
Especially point 2 is a subtile source of bugs, because initialized global/static variables won't have their values set at run time.
For example:
static PLACE_IN_SECTION("BLE_DRIVER_CONTEXT") uint8_t importantValues[4] = {
0, 1, 2, 3};
In this case the importantValues array won't contain the values 0 to 3 but random memory content. There is no warning or error.
As fara as I've seen this is NOT a bug in the firmware package, because the variables/buffers placed in the sections are always explicitly initialized in code. But it's easy for a developer to follow the scheme of isolating additional variables here and expect initializers to work.
That being said, I'm not sure what the best/correct solution should look like. Naming the sections like ".data.BLE_DRIVER_CONTEXT" places them in the .data segment, but it looks like the linker only groups the variables per file (i.e. not all elements annotated with the same section will end up in the same chunk of memory when used in multiple files).
Probably the best would be to explicitly specify the section in the linker file and making sure the "_edata" symbol includes the newly defined regions. But this would stil be vulnerable to forgetting to keep sections in the linker file and in code in sync.
Can you clearify the intent behind the sections (like BLE_APP_CONTEXT, BLE_DRIVER_CONTEXT, TIMERSERVER_CONTEXT)? I think the solution depends on the original motivation for these sections.
