Device hanging after raising .bss to/over 0x10000 (64kb)

[Kosmine]

I'm having a peculiar problem with my device in a memory heavy application, two of my libraries use statically allocated memory and one uses what i allocate with mem_manager. Overall memory usage doesn't seem to go past about 80kb per linker, but if i try to add mem manager blocks or FreeRTOS heap the result is same. My application won't run. Well to be honest i'm not sure my application doesn't run, but when take SEGGER debugger to it and halt it, it shows no exception. All it seems to me is that the device hangs.

[Susheel Nuguru]

Hi,

Even though the device appears to hang, on the technical perspective, the CPU is always running and hence executing instructions (unless halted by debugger or a halt instruction or when in sleep). In your case, i think the CPU is executing a loop of instructions. All you need to do is compile your code in debug mode, let it run in debugger for a while and pause it to see what the CPU, program counter (PC) is executing. You most likely will get a context from this where you can go forward with your debug session. 

My guess is that your application most likely is seeing a stack overflow.  But this should have sooner or later result in a hardfault unless the stack overflow took the PC into a legitimate code sectiton. In which case the behavior is unpredictable.

[Kosmine]

I made some tests to find out the cause over this, and I did note that moving a large struct from .bss over to heap seemed to solve the problem. I then started to test around with superfluous static arrays, and putting .bss with length 0xE164 past starting point of 0x200032F0 causes this to happen. That is putting heap past  0x20011458. Stack and Heap are both at length 0x8000, and halving the heap or stack size does nothing of note. Perhaps this is a linker issue on the arm-none-eabi-ld? 

I tested this with pared down version of my application with most of static variables gone, and used one superfluous static array for testing. for instance this works

section                    size         addr
.text                   0x64808      0x26000
.sdh_ble_observers         0x20      0x8a808
.sdh_soc_observers          0x8      0x8a828
.log_const_data            0x80      0x8a830
.sdh_stack_observers        0x8      0x8a8b0
.sdh_state_observers       0x10      0x8a8b8
.log_backends              0x10      0x8a8c8
.nrf_queue                 0x18      0x8a8d8
.nrf_balloc                0x18      0x8a8f0
.ARM.exidx                  0x8      0x8a908
.data                     0xf90   0x20002168
.got                       0x24   0x200030f8
.got.plt                    0xc   0x2000311c
.log_dynamic_data          0x40   0x20003128
.log_filter_data           0x40   0x20003168
.bss                     0xe284   0x200031a8
.heap                    0x8000   0x20011430
.stack_dummy             0x8000   0x20011430
.ARM.attributes            0x30          0x0
.comment                   0x7f          0x0
.debug_frame            0x14b40          0x0
.debug_info             0x83dde          0x0
.debug_abbrev            0xb7f0          0x0
.debug_loc               0x325a          0x0
.debug_aranges           0x7600          0x0
.debug_ranges            0x7298          0x0
.debug_line             0x2669f          0x0
.debug_str              0x12a5a          0x0
.stab                      0xe4          0x0
.stabstr                  0x1fd          0x0
Total                  0x172c5d

but this does not

section                    size         addr
.text                   0x64808      0x26000
.sdh_ble_observers         0x20      0x8a808
.sdh_soc_observers          0x8      0x8a828
.log_const_data            0x80      0x8a830
.sdh_stack_observers        0x8      0x8a8b0
.sdh_state_observers       0x10      0x8a8b8
.log_backends              0x10      0x8a8c8
.nrf_queue                 0x18      0x8a8d8
.nrf_balloc                0x18      0x8a8f0
.ARM.exidx                  0x8      0x8a908
.data                     0xf90   0x20002168
.got                       0x24   0x200030f8
.got.plt                    0xc   0x2000311c
.log_dynamic_data          0x40   0x20003128
.log_filter_data           0x40   0x20003168
.bss                     0xe288   0x200031a8
.heap                    0x4000   0x20011430
.stack_dummy             0x8000   0x20011430
.ARM.attributes            0x30          0x0
.comment                   0x7f          0x0
.debug_frame            0x14b40          0x0
.debug_info             0x83dde          0x0
.debug_abbrev            0xb7f0          0x0
.debug_loc               0x325a          0x0
.debug_aranges           0x7600          0x0
.debug_ranges            0x7298          0x0
.debug_line             0x2669f          0x0
.debug_str              0x12a5a          0x0
.stab                      0xe4          0x0
.stabstr                  0x1fd          0x0
Total                  0x16ec61

There seems to be some variation on how the .bss if filled but i can only begin to guess at the reasons what happens here.

[Susheel Nuguru]

I am guessing that one or few of your individual array member in .bss needs to be volatile, .bss memory is handled by what linker thinks is best and we can only assume what it is thinking in a particular scenario but heap is controlled in the kernel and we know how the space is handled (more or less).. 

Nothing else strikes me at this point that should have this kind of side affect..