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

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

Vidar Berg — Fri, 03 May 2019 10:38:57 GMT

Glad to hear that it works now. Just let me know if you still want MMD and can't get it to work.

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

rico — Fri, 03 May 2019 09:00:15 GMT

At the moment i am using the driver from github, which works like a charm. If i find some time i will test the SDK driver and give you some feedback.

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

Vidar Berg — Wed, 17 Apr 2019 08:39:52 GMT

Hi,

I added MMD support to wireless_uart->raw->first in SDK 15.3.0, see attached. However, I wasn't able to replicate the assert by single stepping through the code without MMD enabled. Can you try with the same configuration on your side?

devzone.nordicsemi.com/.../wireless_5F00_uart.zip

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

rico — Tue, 16 Apr 2019 14:16:59 GMT

[quote userid="4240" url="~/f/nordic-q-a/45631/assertion-failed-at-ral_fsm-c-318---can-not-even-find-this-file/181818"] Do you get the assert even if you don't do single-step debugging? [/quote]

I have tried debugging the wireless_uart example. It is running fine without single stepping.

[quote userid="4240" url="~/f/nordic-q-a/45631/assertion-failed-at-ral_fsm-c-318---can-not-even-find-this-file/181818"]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).[/quote]

As simple as it sounds, it is not working. Maybe you can try yourself with the example provided in the SDK. I am trying to debug the beginning of the "a_radio_tx_start" function in the fsm. This is called from the user task and should be as far as i understand debuggable.

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

Vidar Berg — Fri, 12 Apr 2019 10:50:17 GMT

[quote user="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?[/quote]

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).

[quote user="rico"]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).[/quote]

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

[quote user="rico"]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.[/quote]

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.

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

rico — Wed, 10 Apr 2019 13:03:47 GMT

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.

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

Vidar Berg — Mon, 08 Apr 2019 11:11:14 GMT

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

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

rico — Thu, 04 Apr 2019 14:06:11 GMT

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?

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

rico — Thu, 04 Apr 2019 10:41:50 GMT

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.

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

Vidar Berg — Wed, 03 Apr 2019 07:06:43 GMT

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).