Assert at nrfx_grtc.c 278

[666]

HI all,

    The main program suddenly encountered assert （nrfx_grtc.c line 278）while running, which happened by chance. The following are the relevant logs

note:nrf54l15 v3.1.0

Do you have any suggestions? I have read other related posts and didn't quite understand them.

Looking forward to your reply！

[Turbo J]

Looks to me like it got another fault or error, tried to log it and got an assert while trying to read the current time from the grtc. This makes the stack trace a bit hard to read.

Smells to me like a buffer overflow that wrote over some other important stuff, but thats just a wild guess.

[Simon D-M]

Hi,

The main program suddenly encountered assert （nrfx_grtc.c line 278）while running, which happened by chance.

You are saying that the assertion doesn't appear all the time. Am I understanding it correctly ?

Turbo J said:

Looks to me like it got another fault or error, tried to log it and got an assert while trying to read the current time from the grtc.

I agree to what has been said here. What you are seeing in this screenshot is probably not the root cause of your issue. It is most likely some kind of consequences of your actual bug.

Also, can you try setting CONFIG_TIMESLICE_SIZE to something else than '0' (for example '20' which is the default value), I can be dangerous to set it to 0 as it can lead to some concurrency issues. I would say that it is better to play with the thread priorities or maybe semaphores if you need a thread not to be interrupted.

To help you further I guess I would need more information about your project and the context of the crash.

Best regards,

Simon D-M

[666]

Hi ,

Thank you for your patient answer.

Simon D-M said:

You are saying that the assertion doesn't appear all the time. Am I understanding it correctly ?

Yes

Simon D-M said:

I agree to what has been said here. What you are seeing in this screenshot is probably not the root cause of your issue. It is most likely some kind of consequences of your actual bug.

It is possible because the testing equipment currently has a probability of dying, but the cause cannot be found yet. This is the best log captured so far, so I would like to see if you have any ideas.

Simon D-M said:

can you try setting CONFIG_TIMESLICE_SIZE to something else than '0' (for example '20' which is the default value), I can be dangerous to set it to 0 as it can lead to some concurrency issues

I did not actively create any other threads in the application layer, will it not have any impact if CONFIG_TIMESLICE_SIZE=0?
I configured it as CONFIG_TIMESLICE_SIZE=0 here because I used v2.8.0 before, and when I updated to v3.1.0, I found that the power consumption increased. After checking the reason, I found that the configuration of CONFIG_TIMESLICE_SIZE was different. That's why I made the change here

In the above situation, does it mean that CONFIG_TIMESLICE_SIZE=0 has no effect?

Simon D-M said:

To help you further I guess I would need more information about your project and the context of the crash.

When the above situation occurs, the main will read data once every 50ms through I2C, and it is uncertain whether this will have an impact

For crash, due to my previous belief that the logs above were sufficient and did not preserve the site, I am currently reproducing them. I hope you can be patient and wait for a while (as this is not easy to reproduce).

[Simon D-M]

Hi,

666 said:

In the above situation, does it mean that CONFIG_TIMESLICE_SIZE=0 has no effect?

I can't see much, but basically if all your thread have different priorities, then no, this config doesn't have any effect. It will just apply to the drivers-created thread, which you probably don't want to mess with.

So as a first step, I would try to move this config back to the default value (20) for now, and see if the bug is still present.

And on top of that if there was something consuming more power when that value was different, it can also mean that instead of actually addressing the thread that was consuming power, you just blocked it from running (which is not optimal to say so).

But keep in mind that I still have very little information about what is actually going wrong in your code so at the end this might not be connected to the bug at all.

If you are able to get some logs printed or something similar to actually see from which thread/function the crash comes from it would be very handy.

Best regards,

Simon D-M