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