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 ?

[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

[cemalb]

Hi,

I'm sorry that I haven't been able to write for a few days. I was busy.

Karl Ylvisaker said:

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.

I did this. I compared the sdk folder where my project is with the sdk folder I downloaded from nordicsemi.com. Unfortunately, the folders is not exactly the same. there are some differences.

Karl Ylvisaker said:

Are you developing on Widows, Linux or iOS?

i'm working with windows10

Karl Ylvisaker said:

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?

sdk 15.3.0 was used in the project. The project was unfortunately organized by different developers at different times.

Karl Ylvisaker said:

Regarding the error message you shared in your previous comment, I would still like to know what priorities you are using for your peripherals.

sorry, I did not understand exactly.

[Karl Ylvisaker]

cemalb said:

I'm sorry that I haven't been able to write for a few days. I was busy.

No worries at all - we continue whenever you are ready and have the time :) 

cemalb said:

I did this. I compared the sdk folder where my project is with the sdk folder I downloaded from nordicsemi.com. Unfortunately, the folders is not exactly the same. there are some differences.

Great, this is very good, well done!
I am curious as to what is changed in each of these files also. I do not know what or why he possibly would make changes in the softdevice folder, for instance. Does the tool you are using also do file-content comparisons?
I assume you downloaded the exact SDK version the project was using originally, could you confirm this?

cemalb said:

sdk 15.3.0 was used in the project. The project was unfortunately organized by different developers at different times.

I understand, thank you for clarifying. When this happens, it is paramount to learn what the previous developers were doing, and how they worked to achieve it. I feel we are on the right path here, since we now have a clearer view how they have worked with the SDK.
Still, it would be good to see file-content comparisons, to see exactly which changes have been made.

cemalb said:

sorry, I did not understand exactly.

In my earlier comment I asked if you could ensure that you were not trying to use any of the priority levels reserved for the SoftDevice: 

Karl Ylvisaker said:

Are you attempting to use any of the priority levels reserved for the SoftDevice in your application?

Could you take a look, verify that this is not the case?

Best regards,
Karl