ASSERTION FAILED at ral_fsm.c:318 - Can not even find this file

[rico]

As the title descripes i get an error with a file name in it but i can not locate this file.

I am working with the 802.15.4 wireless uart example on a nRF52840 DK. I only get this error if i start inserting breakpoints, i can debug some lines and than suddenly this error.

The Call Stack looks like this:

app_error_fault_handler()
assert_nrf_callback()
RADIO_IRQHandler()

Maybe someone can help with this error. Are there more example or even a template for 802.15.4 or is this the only project i can build on?

Thank you soo much!

[Vidar Berg]

Hi,

The SDK provides the 802.15.4 driver as a pre-compiled library which is why you can't see the source code when debugging. The source code is however available on GitHub if you are interested (link). 

I assume the problem is that you get an assert in the driver because you are single stepping through the code. Only the CPU becomes halted when you hit a breakpoint; timers will keep running so the driver may detect that radio protocol timing requirements were not met as soon as you resume execution.  A workaround for this limitation is to use Monitor mode debugging (link).

[rico]

I will try the Monitor Mode while debugging and give some feedback if it solved the problem.

I could not locate the source code for the libary in the given repository. Is there to option to build the libary ourself?

For example i tried locating the source for the mlme_start_req() function from mac_mlme_start.h, but i could not find it.

[rico]

The example i am using is not including the app config and so the app_timer_pause(); is not defined.

Do i need to include the app timer? Do i need to stop and start another timer on entree/exit?

[Vidar Berg]

Normally you will not have to debug the radio drivers. It may be best to use the pre-compiled libraries which are tested for the particular SDK release they have been distributed with.

It's not required to include _pause/_start even if you use the app_timer. We have another blog post on monitor mode debugging that you may find helpful as well (think the last 3 paragraphs are most relevant): https://devzone.nordicsemi.com/b/blog/posts/monitor-mode-debugging-with-j-link-and-gdbeclipse 

[rico]

Thanks for the link, it llok really helpful if someone is using Eclipse and GDB, but i can not transfer all off the given information to the SES which i am using. All examples are provided with a working project for SES and your engineers recommended using the SES. Is the a similar guide for the SES?

My intention is not to debug the radio driver. But something is causing assertation faults and i need to get rid of those(weather i am causing those are something else).

I am running some non hardware related code on the APPLICATION TASK and i am getting assertations in sys_queue.c:152 and ral_fsm.c:318. I can not find those on the github repository you linked in the first  replay.

[Vidar Berg]

rico said:

Thanks for the link, it llok really helpful if someone is using Eclipse and GDB, but i can not transfer all off the given information to the SES which i am using. All examples are provided with a working project for SES and your engineers recommended using the SES. Is the a similar guide for the SES?

Sorry, I should have been more clear. you should ignore the Eclipse/GDB specific info at the beginning of the tutorial. So what I'm suggesting is that you read the blog post I linked to initially plus the last 3 paragraphs in the Eclipse/GDB tutorial because it gives some tips on how to select the interrupt priority. There's also the official documentation from Segger (link).

rico said:

My intention is not to debug the radio driver. But something is causing assertation faults and i need to get rid of those(weather i am causing those are something else).

 Do you get the assert even if you don't do single-step debugging? 

rico said:

I am running some non hardware related code on the APPLICATION TASK and i am getting assertations in sys_queue.c:152 and ral_fsm.c:318. I can not find those on the github repository you linked in the first  replay.

 And sorry about this. I was under the impression that we had the complete stack in the openthread repo, but it's just the driver (also hosted here). We do not provide source code for ral_fsm.