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]

Here are examples of ATT MTU exchange and DLE.

I modified ble_app_uart and ble_app_uart_c. You should be able to send up to 155 bytes of data in one packet.

Use two terminals to send and receive data.

Here is a ZIP.

[eyeye]

Hi @Petter, I have try your examples on two nRF52-DK. It works as expected, the ATT_MTU and LL Data length extended. When I replace the central nRF52-DK with my iPhone6(iOS10), only ATT_MTU exchanged, LL Data length doesn't extended. nRF52 response the LL_LENGTH_REQ cmd with LL_UNKNOWN_RSP. It should be LL_LENGTH_RSP.

from this question you can get more detail information.

[Elias]

I haven't managed to go through the example completely, but making the modification to ble_stack_handler_types.h allowed me to double packet size and increase application throughput by about 100kb/s immediately, so I'll consider my issue resolved for now.

[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.