Softdevice Assertion Failure while using Radio Timeslot, PC=0x00000timA60

[robwasab]

Hi,

[Softdevice 6.1.1]

I am developing an application which uses the radio timeslot api in conjunction with BLE. Even without starting BLE advertising, or any other BLE timeslot activity, I still get asserts.

I am getting soft device asserts approximately 1 out of 10 times I reset the the firmware. The asserts occur in the radio timeslot handler.

It seems that the assert is occurring right after I write NRF_RADIO->TXEN = 1. I know this because I'm toggling some GPIOs right after.

I don't think I'm running out of time since this is happening pretty early on during the timeslot.

As a first step, I need help decoding the assert at the mentioned program counter: 0xA60.

I'm using softdevice 6.1.1

>> It's late, but this might also be good information... I noticed that when this issue occurs, the transmitter goes haywire and interferes with my other transmitters so much so that enough packets get dropped they "disconnect", which agrees with the timing above (happens right after setting TXEN = 1).

Thanks for any assistance you can provide.

- RJT

[Susheel Nuguru]

It is really difficult to narrow down what caused the hardfault you mentioned. But 0xA60 is softdevice hardfault assert handler. I am guessing since you saw this PC value, you are running your code in debugger and you see that the execution halts here? If this is the case, you can continue the execution and most likely this will call your application assert handler and that will provide more information as to where the hardfault was created. If this is application generated hardfault, it would be easy to analyze it thereafter.

[robwasab]

I think the issue is that I was using NRF_RNG (random number generator) in the timeslot. According to the specification, its access is restricted and can only be used through the softdevice.