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 

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