NRF_SDH_BLE_GAP_EVENT_LENGTH

[Lee Daniel Crocker]

Using SDK14.2.

I'm trying to optimize the throughput of my ble_nus-based app (I'm getting about 5k/sec right now). I've read elsewhere on this forum that increasing NRF_SDH_BLE_GAP_EVENT_LENGTH from the default of 3 to 16 might help, and I also read that doing so requires increasing ram_start. I updated sdk_config.h, and the changed the RAM address in the linker script from 20002076 to 20002800, but I continue to get error 4 from nrf_sdh_ble_enable(). Is there some other setting that needs to be tweaked at the same time? Did I not change the ram start enough? Any other suggestions?

[Håkon Alseth]

Hi,

 

If you are getting err_code = 4 (_NO_MEM) back when trying to initialize the stack, you'll need to provide more RAM to the SoftDevice. 

in nrf_sdh_ble.c::nrf_sdh_ble_enable(), there is logging to provide you the expected RAM start, so if you have the NRF_LOG module enabled, it should print the required minimum RAM start address.

When adjusting the define NRF_SDH_BLE_GAP_EVENT_LENGTH, you will extend the amount of data that the peripheral can send, but this might still be restricted by the central side. if your connection interval is 100 ms, and the peer device does not support DLE, your overall throughput will be limited, as you are only able to send a lower amount of packets per interval (typically from 1 to 6).

 

Are you seeing 5 kBit/s or 5 kByte/s?

What is your connection interval?

 

Cheers,

Håkon

[Lee Daniel Crocker]

When I run it, nrf_sdh_ble.c reports "RAM starts at..." and just lists whatever the linker file is set to, so it is no help in determining actual ram usage. It never prints the "...can be adjusted to..." part, but when I move that log line out of the enclosing if, it just reports the same value.

When I say "5k", I mean whole bytes, so the throughput is reasonable, but that's still only 5% of the theoretical maximum bitrate. It would be nice to get 10-20%.

I have min/max connection interval set to 25 and 75 msec. Slave latency 0,

[Håkon Alseth]

Hi Lee,

 

I suspect that DLE is not used (not all central's support this) due to the low throughput. 

If that is the case, then going down to 7.5 ms connection interval should give you a better throughput.

 

If you still are seeing issues with the RAM, just set a higher value, as hmolesworth suggested.

You can read out the required RAM start by going into debug mode and breaking in the end of function nrf_sdh_ble.c::nrf_sdh_ble_enable(). Note that you likely need to set the optimization level to '-O0' in order to peek at the variables within the function scope.

 

Best regards,

Håkon

[Lee Daniel Crocker]

I think you missed my note above that all the variables in nrf_sdh_ble_enable() simply reflect the linker setting--there is no information there about actual RAM usage. I seem to recall that being different in earlier SDKs; the "...can be adjusted to..." line was actually useful. Currently it is very much not useful. Perhaps some change was made recently that works OK in the IDEs but not for armgcc?

[Håkon Alseth]

Hi,

 

Sorry for misunderstanding.

I suspect that your sdk_config has the "info" level set, and not the "debug" level for nrf_log.

You can set this in sdk_config.h:

#define NRF_SDH_BLE_LOG_LEVEL 4

and to set it to this level by-default:

#define NRF_LOG_DEFAULT_LEVEL 4

 

When setting it to print at a debug level, it outputs:

<debug> nrf_sdh: State request: 0x00000000
<debug> nrf_sdh: Notify observer 0x0003BBE4 => ready
<debug> nrf_sdh: State change: 0x00000000
<debug> nrf_sdh: State change: 0x00000001
<debug> nrf_sdh_ble: RAM starts at 0x20002B90
<debug> nrf_sdh_ble: RAM start location can be adjusted to 0x20002B88.
<debug> nrf_sdh_ble: RAM size for application can be adjusted to 0xD478.
<info> app: Heart Rate Sensor example started.
<info> app: Fast advertising.

 

Did your overall transfer rate change when trying 7.5 ms connection interval?

 

Cheers,

Håkon

[Lee Daniel Crocker]

I wasn't using logging at all--I had it turned off and not even linked in. I was looking at the variables directly with GDB after setting a breakpoint, and they did not show memory usage. But I see my mistake now--the value is only set after the enable() call.