• State Verified Answer
  • Replies 3 replies
  • Subscribers 62 subscribers
  • Views 1233 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 127532
Options
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

m.wagner

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.

  • 0

    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.

  • +1

    @HungBui Thanks. I'm pretty sure the SHORTS-Register-setting is the actual reason it happens, as I use ESB with ACK and the DISABLED_TXEN bit is set in the SHORTS register. The SHORTS-register would actually get reconfigured in the interrupt-routine but the routine probably won't get called when the softdevice asserts, so the RADIO transmits infinitely...

    I just tested this again and realised that the issue actually exists in the unpatched version of nrf_esb, too. So it is reproducible using the example you uplodaed in the post I linked to.

    It looks like it would make sense to have TXEN only be called from the interrupt routine instead of having it in the SHORTS register?

    EDIT: I just did that and it seems to work fine so far.

  • 0

    @m.wagner: You can of course do that, but we utilize the SHORT so that the timing would be better and less work for the CPU.

    Usually in an assertion, we will try to reset the chip. If you want to stay in the assert handler, I would suggest you can think of disabling the radio in the assert handler ?

Related