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

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

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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related