How can I find source of problem?

[cemalb]

Hi !

I'm trying to debug. I followed this video : https://www.youtube.com/watch?v=uP8RYgYGRvI&list=PLx_tBuQ_KSqGHmzdEL2GWEOeix-S5rgTV&index=7 .  But I can't completely.

the program stop at NRF_BREAKPOINT_COND in app_error_weak.c.

I used breakpoint to understand which function the error occurred after.  I guess there is a problem when setting Uart. What should I do to better interpret the problem? What can be the problem ?

The program enters the following functions respectively:

1- nrf_drv_uart_init(...);

2- nrfx_uart_init(....);

3- interrupts_enable(....)

4- NRFX_IRQ_PRIORITY_SET(nrfx_get_irq_number((void *)p_instance->p_reg), interrupt_priority);

5- nrfx_get_irq_number(.....)

I added the 5 step's photos to explain better

1)

2)

3)

4)

5)

after step 5, the program stop at at NRF_BREAKPOINT_COND in app_error_weak.c

[Karl Ylvisaker]

Hello,

Are you working on an example from the SDK? If so, which example is this?
Are you using the RTT or UART logger backend?

Could you also confirm for me that you have DEBUG defined in your preprocessor defines, like shown in the included image?

This will print a detailed error message to your logger output, if a non-NRF_SUCCESS error is passed to an APP_ERROR_CHECK.

Looking forward to resolving this issue together!

Best regards,
Karl

[cemalb]

In fact, this is a project developed on ble_peripheral example. It is not an example of UART or RTT.

 

Karl Ylvisaker said:

Are you using the RTT or UART logger backend?

Is this what you mean? actually, I do not have information on this subject:

Karl Ylvisaker said:

Could you also confirm for me that you have DEBUG defined in your preprocessor defines, like shown in the included image?

the current settings are like this, what should I do ?

[Karl Ylvisaker]

I see from your screenshot that this is in fact line 385 and 386.
Please share the snippet of the function containing line 377.

cemalb said:

I forgot to share the code on line 377 because I was tired. sorry. 

No need to apologize - I hope you get some rest soon! :) 

Best regards,
Karl

[cemalb]

[Karl Ylvisaker]

You are not checking the returned error of your call to app_timer_stop on line 377, you are checking the randomly instantiated value of err_code.

Best regards,
Karl

[cemalb]

I'm really angry with myself for my carelessness.

I added the error code.the program does not fail anymore. I could not understand why. So adding the error code solved everything?

[Karl Ylvisaker]

cemalb said:

I added the error code.the program does not fail anymore. I could not understand why. So adding the error code solved everything?

No, not exactly. you were passing in a declared variable to your error check, but you never initialized it. When you declare a variable that only means that the compiler will allocate the required memory for that variable type, it does not provide it with a value. So the variable will hold whatever value existed in the allocated memory prior to its allocation - which is pretty much random.

When you then passed this random-valued error code to the error check it immediately failed, because it was != NRF_SUCCESS, causing your application to reset.

I am happy to hear that your program is not failing any more, either way!

Best regards,
Karl

[cemalb]

So what happened to the NRF_ERROR_INVALID_STATE error?Why does that error message no longer occur?

[Karl Ylvisaker]

It is unfortunately very hard to say exactly why the creation of those two timers failed before you started checking their returned error codes.. but it looks like their creation failed, which led to you call to app_timer_start also failing. I can't really say much more than that, because I do not have any information about whether the conditions of your testing has changed since then, or if you have made any other changes to the code, etc.

Best regards,
Karl

[cemalb]

In fact, it cannot be said that I have made much changes in the codes. Although we cannot explain it exactly, the problem seems to be fixed. If I encounter the same problem again, I would bother you :) 

Thank you for your help and patience.

[Karl Ylvisaker]

cemalb said:

the problem seems to be fixed. 

I am happy to hear that the problem seems to be resolved!
While we may not have added a lot of new features during this back-and-forth, we certainly have improved the overall quality of your project, and minimized a lot of potential for future frustration and failure.

cemalb said:

If I encounter the same problem again, I would bother you :) 

Sure, that sounds all right with me!

cemalb said:

Thank you for your help and patience.

No problem at all, I am happy to help! :) 

Please do not hesitate to open a new ticket if you should encounter any other issues or questions in the future.

Good luck with your development!

Best regards,
Karl