Do not know what value of RAM to configure after adding new characteristic to custom BLE service

[Xander To]

Hi Nordic team,

I'm using S132 with nRF52832 on my custom board. The SDK is nRF5_SDK_17.1.0_ddde560

I have made a custom BLE service that worked for several months. Now I want to add a new characteristic to my custom service. I know what to do in firmware as the new characteristic is 99% similar to the existing custom characteristic inside the custom service.

Firstly, my custom board crashed as expected because I didn't reconfigure the RAM space and 

NRF_SDH_BLE_GATT_MAX_MTU_SIZE in sdk_config. Therefore, I tested this firmware on DK to get the debug message (I currently don't have the hardware to debug the custom board so all debug tasks are on the DK). Initially, here are the RAM configurations on DK.

The original NRF_SDH_BLE_GATT_MAX_MTU_SIZE value is 1408. Based on the Segger IDE suggestion, I changed the RAM_START to 0x20002D30. I keep the NRF_SDH_BLE_GATT_MAX_MTU_SIZE  unchanged. The firmware works on the DK. I can see the new characteristic on my custom service. So that's good!

However, weird things started when I uploaded the same firmware on the custom board. The original RAM configurations of custom board are 

I know the original RAM configuration between DK and custom board are not the same but since they worked fine in the past, I didn't bother to match them together. But today, after I changed the RAM configuration on custom board to be the same as DK's configuration , the board crashes. Below is the custom board RAM configuration after the change

I thought it's probably the RAM change causing the crash. So instead of matching the RAM configuration of 2 boards, I increase the original RAM location up by 8 (0x20002D30 - 0x20002D28), similar to what I did on the DK. However, the board still crashes.

I tried changing the 

NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE to 1460. It still crashes.

I removed the BLE code in my firmware, it doesn't crash.

I added the BLE code back, but this time removed my new characteristic. It doesn't crash.

So that means my custom board is lacked of RAM to add the new characteristic and the amount of extra RAM required is not the same with the DK. Therefore, can you please give me a suggestion of what kind of RAM value I should change it to on the custom board? I program the DK with Segger IDE but program the custom board with GCC

Thank you for your help and suggestion.

Best regards,

Xander

[Einar Thorsrud]

Hi,

When you add more services or characteristics, the SoftDevice needs more RAM, which means that the application start address must be higher (and the size correspondingly smaller). The simplest way to do this is to increase the app start address significantly, and then adjust the RAM start address to what is calculated by the SoftDevice. See this post for details.

However, there are also other things that may need to be adjusted. What exactly happens when you write that the device "crash"? Have you debugged to see if there is a specific function call that returns an error? Sometimes it could be that you need to increase NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE in sdk_config.h and/or NRF_SDH_BLE_VS_UUID_COUNT (if adding vendor specific UUIDs). Note that if you do this, you also need to adjust the application RAM start address (and size).

[Xander To]

Hi Einar,

I currently don’t have the debugging hardware until next month so I’m trying to debug without a debug messege. I just add a new characteristic to my existing custom service (no new service is added compared to the previous firmware version) so do I still have to change the NRF_SDH_BLE_VS_UUID_COUNT.

I will try your suggest approach. However, I’m still very confused why DK and custom board using same firmware but require different RAM/ Flash configuration? I don’t know the debug message but I’m sure the error happens during the new characteristic being added to the service as commenting this section will result in no more crash.

Best regards,

Xander

[Xander To]

Hi Einar,

I have tried removing any changes on RAM start address. However, the firmware after removing all change will work on both side. From this starting firmware (the working firmware before I made any change), adding the new characteristic will definitely crash the custom board and DK (should be due to not enough RAM). Increasing the RAM start address will make DK work and custom board still crashes. Staying at this point, I have a firmware that works on DK and crashes on custom board.

Below is the schematic of our custom board, including the 2 LEDs I mentioned before: LED.Blue and LED.Red. These LEDs are controlled by PPI module. Noted that for firmware using on DK, I have to disable LEDs as DK doesn't have LEDs on these pins. Firmware with disabled LEDs (to match firmware on DK) will still crash on custom board.

[Einar Thorsrud]

Hi,

Xander To said:

Firmware with disabled LEDs (to match firmware on DK) will still crash on custom board.

OK, then we can probably ignore the LEDs. But what did you not write earlier that you saw a difference in behaviour depending on a LED? 

Xander To said:

From this starting firmware (the working firmware before I made any change), adding the new characteristic will definitely crash the custom board and DK (should be due to not enough RAM). Increasing the RAM start address will make DK work and custom board still crashes.

That is most peculiar. This should not be related to the HW differences at all.

With the above two points in mind, could it be that this issue is triggered by something else altogether, and that it is easy to jump to conclusions when testing as behavior changes when you change something, but perhaps with different test runs you will get different behaviors even without any SW modifications?

This is a bit fuzzy and it is difficult to grasp what the issue really is. I would focus on getting debugging up and running as soon as possible. Note that as you have a DK, you can use that as a debugger for your custom board using the debug out port.

[Xander To]

Hi Einar,

Can you please help me confirm I configure both boards to have same RAM settings? 

Here is my RAM setting in Segger Studio for the DK.

And below is the RAM setting in GCC for the custom board.

Einar Thorsrud said:

OK, then we can probably ignore the LEDs. But what did you not write earlier that you saw a difference in behaviour depending on a LED? 

It's not a consistent behavior. But if it crashes, disable LEDs will help. And after that, I can enable LEDs and reupload firmware and it will not crash anymore ?!?

Also, I just redid the change again from the working firmware. I still cannot find the exact reason why my firmware crashes, but I figured out the reason of this peculiar issue. In GCC, if I change RAM configuration in the .ld file (as shown above), it won't update this configuration until I make any change in the firmware code. For example, if I change main.c and do "make", then I change RAM configuration, then do "make" again (this seems to be ignored by the compiler as no change in firmware is found), then upload the code to custom board via openOCD, the new RAM configuration won't be used. However, if I change main.c, then change RAM configuration, then do "make" again, this time the new RAM configuration will be used. This is 1 step toward solving this weird behaviour.

Best regards,

Xander

[Einar Thorsrud]

Hi Xander,

The RAM configuration seems equivalent for the SES and GCC project (same starta address and size).

As this issue seems inconsistent and you see an effect on changing RAM configuration even if it should not matter, and perhaps changes somewhere causes changes somewhere else, I have a few thoughts:

• First of all, have you reproduced this on more than one custom board? Could it be that the nRF is damaged, or that there is some issues on the board causing issues?
• Could it be that you have some memory issues in your application, like writing to a buffer out of bounds, some dangling pointer, using uninitialized memory, or something similar that can give unpredictable behavior?

[Xander To]

Hi Einar,

Einar Thorsrud said:

Could it be that you have some memory issues in your application, like writing to a buffer out of bounds, some dangling pointer, using uninitialized memory, or something similar that can give unpredictable behavior?

Can it be possible to get 1 of these issues on the custom board but not on the DK even though they share the same firmware?

Einar Thorsrud said:

First of all, have you reproduced this on more than one custom board? Could it be that the nRF is damaged, or that there is some issues on the board causing issues?

Sure I will try this on a different board. Just to confirm, there is only 1 RAM and Flash size option for nRF52832 chip, isn't it? I mean there is no way I can get a nRF52832 that has more RAM than another nRF52832 (I'm talking about internal RAM). Here is the info of my custom board from the ST-Link

Info : nRF52832-CIAA(build code: E0) 512kB Flash, 64kB RAM

I just also figured out that if I just changed the RAM of custom board to be the same as DK, app will crash on custom board. This makes me suspect 2 boards have different RAM size.

Update: Solution found. After many trials on custom board, I realize for any RAM settings that has starting address + size > 0x20010000, it will crash. The DK RAM are 0x20002D28 + 0xDDE0 = 0x20010B08 so it will crash the custom board. From using DK, I know starting address of 0x20002b40 will work with the added characteristic. So I calculate RAM size for custom board to be 0x20010000 - 0x20002b40= 0xD4C0 and this RAM setting work on my custom board. Now I can use the newly added characteristic. By the way,  NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE also has to be changed from 1408 to 1508 to fit the new characteristic

Best regards,

Xander