This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Softdevice Assertion with active timeslot API: Infinite retransmission of received package

I'm currently working on an application using the timeslot API to be able to use the radio while it is idle. It is based on the nrf_esb shockburst implementation from SDK13, but somewhat modified. It is mostly running as a primary receiver (PRX).

Now when hitting a breakpoint while debugging the application, the softdevice calls the assertion handler, as expected. If the chip is kept running at this point (e.g. by having while (1) {} in the assertion handler), the RADIO will immediately start broadcasting the last received package on the channel/address configured or an empty package if none has previously been received. When I stop the application once again after that, using the debugger, I see the radio configuration as it should be (pipe, channel, address, etc.), but it is in STATE_Tx or TxRu.

Do you have any idea what could happen on a softdevice assert, that would change the radio from (probably) being either in any of the RX states to going into Tx state infinitely?

Unfortunately, I currently can't easily share the code or create a minimal example that reproduces this behaviour. I know there are some issues with which I have to deal at some point, but for now I'm just really keen on getting any pointers to what could cause this behaviour. I tried reproducing it with this esb timeslot example, but this did not seem to have any issues.

For the record, I'm currently on SDK 14.1 and S132 4.0.5, but the issue was there with SDK 13 and S132 3.x, too.

Parents
  • It could be difficult to tell what happens exactly when assertion occurs. Especially, there is a requirement that the application have to stop all peripherals before the timeslot finishes.

    Which state the softdevice was when you halt the CPU ? it's advertising or in a connection ? Do you use any ACK in your ESB application ?

    Could you check the SHORT and PPI that connect to the RADIO ? I suspect these automation channel actually cause the infinite transmitting.

Reply
  • It could be difficult to tell what happens exactly when assertion occurs. Especially, there is a requirement that the application have to stop all peripherals before the timeslot finishes.

    Which state the softdevice was when you halt the CPU ? it's advertising or in a connection ? Do you use any ACK in your ESB application ?

    Could you check the SHORT and PPI that connect to the RADIO ? I suspect these automation channel actually cause the infinite transmitting.

Children
No Data
Related