Peripheral fault from DLE with s132 v3.0?

[Elias]

I'm trying to maximize BLE throughput between a central and peripheral (I'm programming both) running the new s132 SoftDevice v3.0. I can't achieve the maximum data payload that I expect.

Following the migration document, I added the ATT_MTU exchange procedure and the Data Packet Length Extension, setting the MTU and the PDU to 251 on both sides, and I enabled Connection Event Length Extension. I also increased the size of the characteristic being written to 251 and set the Central's transmit bandwidth to high.

My current issue is that when I call sd_ble_gattc_write() on the Central with more than 62 bytes, the Peripheral hits some fault before the application receives the event. Even though my sniffer doesn't like extended packets, it seems to suggest that the Central is sending them properly, so the problem does seem to be with the Peripheral's SoftDevice. Are there any more obscurely documented modifications I should have made during my migration? Using a fault handler gives me no good info and I'm not using an IDE so I can't look at a call stack or anything.

By the way, are there updated serial port examples (a central and a peripheral) on the way? The ones in SDK12 have been updated to the new API, but they don't look like they exploit the new SD features.

[Petter Myhre]

@Eugene It is returned from sd_ble_enable(), and 0x0004 is NRF_ERROR_NO_MEM. If you increase the MTU the SoftDevice will require more RAM. Examine softdevice_enable(). ram_start is the current starting point for the application, while app_ram_base is the required starting point for the application (after the call to sd_ble_enable()).

[Martin Roa Villescas]

@Petter Could you please rephrase the second part of your comment? I don't think I understand:

ram_start is the current starting point for the application, while app_ram_base is the required starting point for the application (after the call to sd_ble_enable())

On the other hand, the first part is clear: If you increase the MTU size then you have to increase the amount of RAM reserved for the SoftDevice. However, I still don't know where exactly you can increase the amount of RAM for the SoftDevice. Is it in the linker configuration file? Somewhere else? If we want to have an MTU size of 247 instead of 158, does that mean that we have to increase the SoftDevice RAM size by 89 bytes? Thanks in advance.

[Petter Myhre]

I'm not sure what you don't understand, have you examined softdevice_enable()? I'll try to rephrase. In softdevice_enable() ram_start equals the linker value of the RAM starting point of the application. app_ram_base is set to ram_start and is given to the SoftDevice through sd_ble_enable(), together with its configuration, where you set the maximum size of ATT MTU, number of links, and so on.

The SoftDevice will compare the value of app_ram_base with the RAM it actually needs, if not enough RAM is provided sd_ble_enable() will return NRF_ERROR_NO_MEM and app_ram_base will will be the required RAM starting point of the application.

[Martin Roa Villescas]

@Petter Thanks for the re-explanation. I was able to finally overcome the NRF_ERROR_NO_MEM error. Indeed it is the ICFEDIT_region_RAM_start value in the linker configuration file (ble_app_uart_c_iar_nRF5x.icf) that you have to modify according to what the NRF_LOG_WARNING says. My main problem is that the NRF_LOG_WARNING does not work together with the NUS service since I guess that they both try to claim the UART (in uart_init() and in NRF_LOG_INIT(NULL)). My solution was to temporarily comment out the NUS UART related code in order to see the NRF_LOG warnings. I'm sure there must be a better way to do this.

[Petter Myhre]

Great! You could also use a debugger and check the value.