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]

cemalb said:

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

Yes, but which example specifically are you working with? The UART or RTT comment was meant to ask how you display your loggings. 

cemalb said:

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

Please check your sdk_config.h file, and look for the following definitions:

#define NRF_LOG_BACKEND_RTT_ENABLED 1

#define NRF_LOG_BACKEND_UART_ENABLED 0

 
Which of these are defined to 1? This will determine where your logger outputs its messages, either to a UART terminal, or an RTT terminal (such as RTT Viewer).

cemalb said:

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

You are in the right place, but please change to display the 'common' configuration in the second window, like shown in my included image - you are currently looking at the 'Release' configuration, and as you can see it only inherits from the 'common' configuration.
If DEBUG is not already defined in the 'common' configuration, please add it, like shown in the image from my previous comment.

Looking forward to resolve these issues together,

Best regards,
Karl

[cemalb]

Karl Ylvisaker said:

If DEBUG is not already defined in the 'common' configuration, please add it, like shown in the image from my previous comment

Hi,

it doesn't defined in the 'common' configuration. I have just defined it. 

I also looked at sdk_config.h. NRF_LOG_BACKEND_RTT_ENABLED is configured 1.
NRF_LOG_BACKEND_UART_ENABLED is configured 0.

[Karl Ylvisaker]

cemalb said:

it doesn't defined in the 'common' configuration. I have just defined it. 

Yes, it is not defined there by default. Great! With this in place, you should see detailed error messages output to your logger backend.

cemalb said:

I also looked at sdk_config.h. NRF_LOG_BACKEND_RTT_ENABLED is configured 1.
NRF_LOG_BACKEND_UART_ENABLED is configured 0.

Are you seeing the logger's outputs in the debug terminal of SES? Or, are you using the RTT Viewer application from Segger?

Best regards,
Karl 

[cemalb]

Karl Ylvisaker said:

Are you seeing the logger's outputs in the debug terminal of SES?

No I don't see anything. 

When the program runs, all it does is stop at NRF_BREAKPOINT_COND. There is no log information coming to the debug terminal.

[Karl Ylvisaker]

As I mentioned, the SES debug terminal is an RTT terminal - so if you are going to see the output there, you would need to change back the sdk_config.h definitions you changed earlier, so that the logger uses the RTT backend.
Try this, and let me know if you then again see your loggers output in the debug terminal.

Best regards,
Karl

[cemalb]

Hi !
I was running my project with SES v5.20 before. Now when I run it with SES v5.40, log information appeared in the debug terminal. The information is follow:

<error> app: ERROR 3735928559 [Unknown error code] at ../../../../../../integration/nrfx/nrfx_glue.h:107
PC at: 0x000327F7
<error> app: End of error report

[Karl Ylvisaker]

cemalb said:

I was running my project with SES v5.20 before. Now when I run it with SES v5.40, log information appeared in the debug terminal. The information is follow:

Thank you for provided the error message. I am glad to hear that the loggers outputs are now appearing as expected.
This is quite the strange error, since line 107 of nrfx_glue.h is actually an assert in case the provided interrupt priority is not valid..
Are you attempting to use any of the priority levels reserved for the SoftDevice in your application?
Could you confirm for me that you have not made any changes to the libraries and drivers provided with the SDK?

Best regards,
Karl

[cemalb]

Hi,

Karl Ylvisaker said:

Are you attempting to use any of the priority levels reserved for the SoftDevice in your application?
Could you confirm for me that you have not made any changes to the libraries and drivers provided with the SDK?

I've never been changes to the libraries or drivers. But the person who worked on this project before may have done it. I do not know that, Because unfortunately I cannot reach him. I have no information about the past of the project.

If there is a suspicious place, I can look there and make the necessary corrections. Or if you can help migrate the project to the new SDK I can also try doing that.

[Karl Ylvisaker]

cemalb said:

I've never been changes to the libraries or drivers. But the person who worked on this project before may have done it. I do not know that, Because unfortunately I cannot reach him. I have no information about the past of the project.

Aha, I see. That makes it harder, but not impossible to root out.
Just to make sure, are you saying that you were just handed the application code as part of an SDK folder, with all its contents?
If so, I recommend that you do a full check of the SDK, to root out any changes that might have been made to the drivers and libraries provided with the SDK. This might save your tremendous amounts of debugging headaches later on, and if left unchecked can cripple your ability to migrate SDK versions later on.
You could do this by downloading a mint condition SDK of the same version that you are using now, and then using any kind of directory-and-file comparison tool on the two.
Are you developing on Widows, Linux or iOS?

cemalb said:

If there is a suspicious place, I can look there and make the necessary corrections. Or if you can help migrate the project to the new SDK I can also try doing that.

Which SDK version are you working with, and how long has it been used for development?
Is it only a single person that has developed on this project prior?

Migrating to a mint SDK might break the product's code, if the application code relies on changes to certain drivers and libraries.
Modifying the provided drivers and libraries in place is very bad coding practice, and hopefully, the difference check I recommended above will reveal that the prior developer did not modify the SDK libraries or drivers, but it is a big uncertainty to leave unchecked, in my opinion.

The error you posted earlier does not necessarily indicate that drivers and/or libraries have been modified, so checking whether the SDK has been modified or not is more of a sidetrack to that particular debugging, but as mentioned it could save you a great deal of debugging and frustration down the line, if it turns out that modifications have been made in places you are not aware of.
Regarding the error message you shared in your previous comment, I would still like to know what priorities you are using for your peripherals. Could you also please tell me which SDK version you are working with?

Best regards,
Karl