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]

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

[cemalb]

Karl Ylvisaker said:

I assume you downloaded the exact SDK version the project was using originally, could you confirm this?

Yes, I downloaded sdk 15.3.0 from https://www.nordicsemi.com/

Karl Ylvisaker said:

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?

Yes it also compares the contents of the files. I also compared the contents of files. however, when I examined the contents of the files, I could not see any difference.

but when I wanted to do this it gave a warning like this:

I don't know exactly what that means.

Karl Ylvisaker said:

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

I did not add anything related to priority level to the program. Or I haven't made any changes to the current settings. However, developers before me may have made a change.

uart is used in the project. There may be a priority level setting for its interrupt function. but I don't know how to find out.

[Karl Ylvisaker]

cemalb said:

Yes, I downloaded sdk 15.3.0 from https://www.nordicsemi.com/

Great, thank you for confirming.

cemalb said:

Yes it also compares the contents of the files. I also compared the contents of files. however, when I examined the contents of the files, I could not see any difference.

Does the program not generate a file, which contains all the differences between the files?
I am not familiar with the particular program you are using/showing screenshots from, but that is how the comparison programs usually work, in my experience.

cemalb said:

but when I wanted to do this it gave a warning like this:

cemalb said:

I don't know exactly what that means.

Carrier Return is a character used to delineate the end of a line. I am not aware of any changes we have made to the used carriage return type in our SDK's, so I am not sure why this would throw an error, if nothing is changed in the SDK files by the previous developer.
I suppose you could do as the warning suggests, and treat them as equal for the purpose of the comparison. This is not really the changes we are looking for, we are primarily concerned with changes to the functionality.

cemalb said:

I did not add anything related to priority level to the program. Or I haven't made any changes to the current settings. However, developers before me may have made a change.

Are you seeing anything show up in your comparison, when compared with the original example?
Changes here would be in the sdk_config file.

cemalb said:

uart is used in the project. There may be a priority level setting for its interrupt function. but I don't know how to find out.

This is usually defined in the sdk_config file. For example, if you are using the nrfx_uart driver, it would in the sdk examples be named NRFX_UART_CONFIG_IRQ_PRIORITY. The priority to use is passed to the peripheral during its initialization, so you may look there too, if the previous developer has not defined the IRQ_PRIORITY in the sdk_config.

Best regards,
Karl

[cemalb]

Hi !

Karl Ylvisaker said:

Are you seeing anything show up in your comparison, when compared with the original example?
Changes here would be in the sdk_config file.

As a result of my review, I realized that the project I was working on was developed on a "ble_app_template" project. I compared the sdk_config.h file of the project I am working with and the sdk_config.h files of the "ble_app_template" project. The comparison program I use has generated a report in html format. You can find it attached. 

In this way, I think we will reach a better solution.

report.htm

[Karl Ylvisaker]

Hello,

cemalb said:

As a result of my review, I realized that the project I was working on was developed on a "ble_app_template" project.

I am happy to hear that the comparisons are revealing these details, and proving tangible results.
This is very helpful information.

Have you been able to confirm that no changes have been made within the drivers of the SDK?

cemalb said:

The comparison program I use has generated a report in html format. You can find it attached. 

Thank you - is there anything in particular you would like me to take a closer look at?
I must once again emphasize that I think it would be better to have the output of the comparison only contain the differences - this will make the work of manually tracking differences much easier for you - I am certain that this must be an option in the comparison tool you are using.

I also see from the generated report that your project's path includes 'space'/empty characters. I recommend that you replace these, to avoid future compatibility issues with applications and tools not originally developed on/for windows.

cemalb said:

In this way, I think we will reach a better solution.

So, we are back to the original issue?
Are you still getting the same 'unknown error' printed to your RTT terminal when the program is run?

Best regards,
Karl