array size increase causes bluetooth to not connect.

[Robin]

Hello once again Nordic Pro's,

My latest issue, I believe to be related to stack/heap settings, but dont have enough information to track/correct.

I have a couple int array variables that, if their size is increased above 105 elements, bluetooth no longer connect to our central test board.

Not sure where to start chasing this  as I have no compile, build or load error messages, just a failure to connect.

Any help in chasing this down is greatly appreciated.

Device: 51822,

SDK: 12.3,

IDE: Keil 5.28,

App based on app_ble_uart peripheral.

Thanks again,

Robin @ TL

[Turbo J]

On the 16KB NRF51x variants, you can run out of RAM quite quickly.

Testing what is actually happening requires debugging, e.g. with a J-Link.

[tesc]

Hi,

Let me add that our SoftDevices has a maximum stack usage of around 1.5 kB. In other words, if at any time SoftDevice + application RAM usage + application stack usage exceeds 14.5 kB then you may get a stack overflow which will result in undefined behavior.

Debugging will either give you error codes, or, you can have a look at the stack pointer to see if it goes alarmingly high. Remember that each array of a hundred 32 bit integers is 400 bytes, not that far from half a kilobyte, so if you have 16 kB of RAM those arrays quickly takes up a significant portion of available RAM.

Also, how much RAM is available to the stack? (The way to tell in Keil is that ZI-data and RW-data is the total static ram used by the application, the rest of available RAM is for the stack.)

Are the arrays in static memory or are they also put on the stack?

How many arrays are there?

Regards,
Terje

[Robin]

Hello everyone,

According to the map file, I am well under RAM and ROM limitations.  There are only 2 arrays and they are both static as are most of the variables in our app.  W/r/t stack size it is define in the startup at 2048.  Any change to this in either direction causes the same result, not BLE connection.  So, where should I look when debugging, given no stack pointer overrun?

Thanks again

Robin @ TL