Softdevice assertion failed (PC=0x15124)

Hello,

Our setup consists of two nrf52840 devices on custom boards. The devices establish a BLE connection via the Coded PHY (S=8). DLE is used. Connection event time is 7.5 ms and connection interval is also 7.5 ms. Slave latency is 0. On the connection there is almost no traffic but after some time the peripheral device is resetting itself after a failed softdevice assertion (id = 1; pc = 0x15412). The time until the assertion fails is varying between 10 minutes and several hours.

Further details:

  • Device: nrf52840
  • Setup: Custom board
  • Softdevice: S140 7.0.0 (s140_nrf52_7.0.0_softdevice.hex)

Thanks for your help in advance!

Best regards

Parents
  • Hi

    SoftDevice asserts are usually because of one of the following (only relevant reasons based on your description added):

    1. The application tries to access modules in HW that are used by the SoftDevice

    2. The application configures or uses interrupt priorities that it's not supposed to use and breaking the SoftDevices requirements for having the priority on interrupts.

    3. The application stack overflows, and corrupts the SoftDevice stack memory (most likely based on your description I would say, see this case for more details  RE: Application stack overflow during SoftDevice execution  ).

    4. Using the Timeslot API and not ending the session in time.

    Best regards,

    Simon

Reply
  • Hi

    SoftDevice asserts are usually because of one of the following (only relevant reasons based on your description added):

    1. The application tries to access modules in HW that are used by the SoftDevice

    2. The application configures or uses interrupt priorities that it's not supposed to use and breaking the SoftDevices requirements for having the priority on interrupts.

    3. The application stack overflows, and corrupts the SoftDevice stack memory (most likely based on your description I would say, see this case for more details  RE: Application stack overflow during SoftDevice execution  ).

    4. Using the Timeslot API and not ending the session in time.

    Best regards,

    Simon

Children
  • Hi Simon,

    Thanks for your answer! The softdevice is using the same stack (MSP) like the application code based on the sections I read in the documentation, isn't it? So there is no dedicated stack for application and softdevice or am I wrong? In our application we don't use a RTOS. Based on my calculations the worst case application stack usage and worst case softdevice stack usage together should not exceed the stack limit of our application which is 8kB (0x2000).

    Thanks for your help!

    Best regards,

    Florian

  • Hi Florian

    The MBR and SoftDevice will have the "bottom" part of the flash memory reserved for its use 0x0 to ~0x26000 if I recall correctly, and then the rest of the flash will be available for the user application. Please check out the blog post here explaining this split and how to set the RAM and Flash memory for the nRF5 SDK. 

    Best regards,

    Simon

  • Hi Simon,

    Please excuse my delayed response. Thanks for the link with the overview of the memory region. It is very helpful! I check the memory regions based on the overview and within our application everything should be in range.

    In the mean time I was able to solve the problem. The connection stays now active over several days without a device reset. The step to solve the problem was to reduce the LL payload size back to fixed 27 bytes. Previously after a connection setup a payload size of 251 bytes was requested. Later I found in the release note of SoftDevice 7.0.0 a limitation which mentions that the LL payload size is limited to 27 bytes for connection via Coded PHY. Maybe the violation of this limitation within our application caused the assertion and the device reset?

    Thanks for your help and your ideas solving this issue!

    Best regards,

    Florian

Related