Adding nrf_nvic_state_t nrf_nvic_state = {0}; causes code not to build. No reason for build failure

[brianreinhold]

I am still trying to figure out what NVIC_SystemReset actually does and why a build and run always gives an error forcing me to press the reset button on the DK to function,

I found this text in the documentation:

In order to use this module, the following code has to be added to a .c file:

nrf_nvic_state_t nrf_nvic_state = {0};

Definitions and declarations starting with __ (double underscore) in this header file are not intended for direct use by the application.

I had not done this, so I added it as a global in my 'main' file to see if NVIC_SystemReset() would behave in an expected manner and if that would fix the build and load issue I have on the nRF523840 DK. Well, after adding that line of code the build simply fails. No reason, no indication that this line of code caused it. The only reason I knew that it was the reason is because the code built before adding that one line of code.

So now I have another question. How is it that the documentation states that I MUST add this line to use NVIC calls through SoftDevice yet adding it causes the build to fail? Without that line the code mostly works, especially in debug mode. I did not catch this requirement earlier because it is not noted in the functions, but in a different place.

Is the documentation wrong? Perhaps misleading and that line is only needed for SOME of the NVIC SotfDevce calls? I am very confused. Something is not working right with respect to loading new code, and doing an NVIC_SystemReset when the module finishes (after a BTLE disconnect). The idea is that the NVIC_SystemReset should bring the module back to the program start as if the board just powered up.

Just did a global search for the implementation in some example in the SDK and there was none. The comment was found in several nrf_nvic.h files. This gets more confusing by the hour. Am I running down a rathole?

[ovrebekk]

Hi

I believe the build problem is caused by the fact that the nrf_nvic_state variable is already implemented in app_util_platform.c, causing an error when you define it again. Essentially this is already handled by the SDK, and you don't need to define it in the application. 

I don't understand why the build error lacks any further description though, I had to open the map file to realise it was already defined somewhere else. 

Then to perform a soft reset you just need to call sd_nvic_SystemReset();

Still, doing a system reset in this case feels a bit like treating the symptom rather than the cause, and we might want to look into why you need a reset to get the code to run in the first place. 

Are you able to run the code if you start a debug session?

Are you able to give me a brief overview of the functionality of your application, and what standard SDK example you started out with, if any?

Also the type and version of chip, SDK and SoftDevice could be useful. 

Best regards
Torbjørn

[brianreinhold]

I will give you the entire project if you want and it will help.

I am using the nRF52840 DK and SoftDevice s140 7.2.0 (I see 7.3.0 is out; should get that). The SDK package I started with is 17.0.2. I started with the ghs example but you would not recognize it anymore. I started with that to get all the board setups, buttons and LEDs, and hardware initializations correct.

If I run using the SES build and debug option, I do not need to press the DK's reset button to start the app and after the NVIC_SystemReset() call that I make after a disconnect. App restarts as desired.

I do not call the reset method on program startup but only on program termination (after a disconnect) to restart the program as if it entered 'main()'  from a power up. It is difficult to get output during a real power up because putty won't open a session on the COM port until powered up, and once powered up, its too late to catch the output in the putty window. I assume a SES 'build and run' does effectively the same thing.

As I stated in the initial question, I am NOT using the SDK but just SoftDevice. Well, I am not using the SDK for Bluetooth or flash writes and I have been able to remove those directories from the project s well as a few libraries. However, there are many libraries for RTC and other hardware setups that I don't dare to touch and really don't know what they do.

So I am trying to solve two problems. The first is the fact I have to push the DK's reset button to start the program (that's in a separate issue) and why calling NVIC_SystemReset() is also working inconsistently. (This issue.) They are likely related. I suppose I could call sd_nvic_SystemReset(). Does it make a difference?

[ovrebekk]

Hi

I looked into this a bit more, and also got a colleague to test it. It seems this will happen with any standard Bluetooth SDK example, so it is not related to your project, but it only happens in Segger Embedded Studio, and not in Keil. 

Our working theory is that SES will start execution at the application start address after a Build & Run, and not at address 0x00000000 as it should. This will bypass the SoftDevice init, with the result that the SoftDevice will just keep running and cause an error when you try to enable it again. 

I will contact Segger about this issue and ask if they can look into it. 

In the mean time I think you will just have to make it a habit to press the reset button after flashing ;)

Best regards
Torbjørn

[brianreinhold]

Thank you very much for your efforts here. I will continue with the 'reset'.

[Thomas U]

I have the same issue. Is there a solution?

[brianreinhold]

Thomas,

I have not found a solution when using SES. The problem is SES. I have become so used to it whenever I build with SES and do the 'build and run', I go right for that reset button on the DK.

However, if I power cycle the DK I don't need to do that. The answer above appears to be correct for I can see that when I try to initialize the stack, SoftDevice is already enabled, and it should not be.

[ovrebekk]

Hi 

We reported this to Segger, and was essentially told that this is working as intended

In other words I don't expect they will ever change this behavior. 

Best regards
Torbjørn

[Thomas U]

Thank you for getting back to me and explaining the situation.