Getting Error

[mjconnor57]

I am developing a custom application that was started from 1 of the bluetooth examples for a customer and though I have been using the same custom PCB for 7 months, I am now, for the past few weeks, getting this error any time I run in debug mode. My application will run for a varying amount of time sometimes a second sometimes a minute then it throws the error. 

<error> app: ERROR 3735928559 [Unknown error code] at C:/nRF5_SDK_17.1.0_ddde560/modules/nrfx/hal/nrf_gpio.h:492
PC at: 0x00038B67
<error> app: End of error report

I was told to check out my call stack for further information and perhaps a clue as to which pin is causing this issue but the hex for the pin is changing every instance, I am attaching 2 screen captures as examples.

Any help is greatly appreciated.

Thank you

Matt

[Vidar Berg]

Hello Matt,

The first impression I get after looking at the call stacks is that it looks like a stack or buffer overrun. The pin variable passed to nrf_gpio_pin_toggle() is clearly corrupted, at least.

I found the project you shared with me in an earlier ticket, and it shows the pin number being retrieved from a global array. Can you check what the array index is when the assert is raised, and/or if the array contains the expected pin numbers?

Best regards,

Vidar

[mjconnor57]

Hi Vidar I definitely can check the value in the array, I am just not sure which array you are referring to so I can add it to my watch list?

The board definitions and pin assignment has been steady state since i last provided you the project, could you tell me hte array to check?

[Vidar Berg]

The call stack shows that the assert is raised when nrf_gpio_pin_toggle() is called from the timer2_event_handler() interrupt handler. So my suggestion is to have a closer look at the "this[<index>].stepper_step_pin" assignment.

[mjconnor57]

It seemed normal when it errored out this time;

21 is the correct pin # for stepper_step_pin. Though I got a different UART output than usual, this time it <error> app: SOFTDEVICE: ASSERTION FAILED. 

I will continue to run to see if i can get the same error code I was  typically seeing as this was the first time I have seen the softdevice assertion failed

[mjconnor57]

The second fault was more in line with previous faults throwing <error> app: UNKNOWN FAULT at 0x00038B7F

stepper_step_pin is still 21

[mjconnor57]

And the 3rd failure I got what I typically experience:

<error> app: ASSERTION FAILED at C:/nRF5_SDK_17.1.0_ddde560/modules/nrfx/hal/nrf_gpio.h:492

Hope this information helps.

Thank you for your help so far

Matt

[Vidar Berg]

Could you check if the «id» in this[id].stepper_step_pin is correct too? I am wondering if there is a chance it may have become out of bounds.

Regarding the sd assert, the most common reason for it to occur is if you continue execution after having hit a breakpoint (it detects when its timing requirements have not been met, hence the assert). Could that be the explanation in this case maybe?

[mjconnor57]

You were 100% correct, the ID was being set to STEPPER_ID_MAX, which for us is wrong it should only be STEPPER_ID_LIFTER or_CAROUSEL. The interrupt for the motor stop was being executed at teh wrong time. That seems to have cleared up the nrf_gpio.h line 492.

But I am still seeing SD Assert. After I pause execution in debug mode, are you saying that that is normal and not an error? If so is there anything I can do or not do to try and avoid causing that? I only ask because setting breaks and pausing to inspect variables is going to be essential to trouble shoot an application issue I am investigating that got this whole ball rolling

[mjconnor57]

I am still getting <error> app: SOFTDEVICE: ASSERTION FAILED on every breakpoint or pause in debug mode

[Vidar Berg]

Thanks for confirming that it worked.

mjconnor57 said:

But I am still seeing SD Assert. After I pause execution in debug mode, are you saying that that is normal and not an error?

Yes, it is a limitation when working with the Softdevice, and it can take some getting used to, unfortunately. You can mitigate the problem by enabling Monitor mode debugging (it enables you to hit breakpoints in lower priority interrupts context without halting the CPU). But in my experience, it's often easier to adapt the debug approach a bit instead. E.g. rely more on logging, always reset after hitting a breakpoint, etc.

Also, as you might know, variables added to the "watch list" can be read periodically without halting the CPU: