Error with: Softdevice assert: 86132

[lgs]

Hi Team,

I am developing an application that nordic chips receive data from msp430 chips by the SPI, and send them out.

Nordic can receive the data from the msp430, but when it tries to send it out. It occurs an error: "Softdevice assert: 86132";

How can I handle it?

With best regards,

Gaosheng

[Vidar Berg]

Hello,

Can you please provide the Softdevice variant and version number (e.g. s140 v7.1.0)? I need this to look up the PC address in our assert tables.

Also, what interrupt priority have you set for the SPI interrupt? Note that the Softdevice reserves access to the priorities listed here: Interrupt priority levels

Best regards,

Vidar

[lgs]

Dear Vidar,

yes, the softdevice version is s140. v7.2.0. The Mesh version is v5.0. nRF5 SDK version is 17.0.2.

I will check the Interrupt priority levels later.

Thanks for your help!

With best regards,

Gaosheng

[Hung Bui]

Hi Gaosheng, 

I'm taking over the case from Vidar as it's mesh related. 

The error suggest that it could be an issue with the radio scheduler. 
Please check: 

- You have followed the interrupt priority level requirement as described here.

- You have configured the LFCLK correctly according to your board. Which 32kHz clock source do you use on your board ? 

How long did it take to reproduce the issue ? 

[lgs]

Hi ***,

Actually, it appears quickly. After the first schedule, the issue appears.

According to Vidar's advice, I check my code.  My application combined with SPI, when received the data then send it out by Mesh. I stop the SPI process after receiving the data, then deliver it to Mesh to it out. 

No problem appears. But try to debug the Mesh process, it will appear new errors with code: "Softdevice assert: 154632:0." 

So my question is how to balance/schedule the SPI and Mesh process?

Merry Christmas and happy new year!

With best regards,

Gaosheng

[Hung Bui]

Hi Gaosheng, 

Error at 154632 is described as: 

 //ASSERT if the application used too much time in the callback handler. Softdevice timing may be thrown off.

It still seems to me that the application is using too much time in SPI or other tasks. Please double check. Make sure SPI handling is finished as soon as possible (no dead loop) and the interrupt priority should match with the priority that you declare to initialize mesh (usually APP_IRQ_PRIORITY_LOWEST if you don't use app scheduler)

If the issue remains please try to temporarily disable some of the feature of your application just to check if the assertion disappear.