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 

Thanks for the description. I didn't realize I had to click the search field and select default patient. 

Now everything seems to work as intended. After I flash the board and click the start advertising button it connects to the app, pairs, and starts sending simulated medical data. 

So I guess we are back to where we started: Trying to figure out why it seems to work fine for me, but not for you ;)

brianreinhold said:

I think I made a video at one time on how to use the app. I should have one, but I do not have any decent video making software!

Privately I use Davinci Resolve. It's not the easiest application to use, but even the free version is surprisingly feature rich. Worth a try

Best regards
Torbjørn

[brianreinhold]

I will need to try that Davinci thing.

What happens if you change the simulated device type? In the GhsControlStructs.h you will find a list like this

#define BP_CUFF 1
#define PULSE_OX 0
#define GLUCOSE 0
#define SPIROMETER 0
#define SCALE 0
#define THERMOMETER 0

(I've moved all the specialization stuff into one location now).

Above it is set to be a Blood Pressure cuff. Set that to 0 and then pick something else. I wonder if something gets messed up when switching specializations (it would be in the flash). That shouldn't happen as I have put a variable at the start of the flash indicating which specialization is being run, and if what is read is different from what is currently set, flash is not read at program start.

Note that if the Android is paired for a given specialization and the DK is not, the DK will disconnect when the Android tries to invoke encryption. You will need to unpair the Android to work. That can be done in the app by clicking the hamburger menu (three horizonal bars in the upper left) and clicking on 'Known Devices' at the top of the Navigation drawer/ You should see a list of devices the app knows about. Just click 'forget'.

Actually, when I power up the board the error is not happening. It only seems to happen when I do a build-run in SES. In that case I get the error

<debug> app: Main start GHS
<info> app_timer: RTC: initialized.
<error> app: ERROR 8 [NRF_ERROR_INVALID_STATE] at E:\projects\utech\nRF5_SDK_17.0.2_d674dde\examples\ble_peripheral\ble_app_ghs_epoch\main.c:1532
PC at: 0x0002D661
<error> app: End of error report

If I press the reset button then all is nice. If I power cycle the board all is nice. If I do build-run the error above occurs, but if I power cycle the board it works just like pressing the reset button.

Could it be Segger Embedded Studio? I have release 5.50a.

[ovrebekk]

Hi 

Thanks for adding the information about build-run, now I can also reproduce the issue here

I am not sure why I didn't see it before, but this issue appears to be related to situations where you try to run the code without having to reflash the board. 

According to the error the issue occurs in the nrf_sdh_enable_request() function, and the reason you get the NRF_ERROR_INVALID_STATE error is that the SoftDevice is already enabled when this function is run. 

Why this would happen is a bit of a mystery to be honest. I have discussed it with some of my colleagues, but unless you were using a bootloader there are no good explanations why the SoftDevice would remain running while the application is reset, which seems to be what is happening. 

I will have to investigate this a bit more and try to look for an explanation. 

Best regards
Torbjørn

[brianreinhold]

Torbjørn

Thanks for the examination and following through on this. I did follow the source of the error but I did not understand why I would get that error, as I specifically disable SoftDevice before I write to flash. I do a reset in the main loop when I find SoftDevice is disabled (which should only happen after I complete the flash write). Would it make sense to check if SoftDevice is enabled before calling the method that ends up calling  nrf_sdh_enable_request()?

[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.