Soft Device enable function "sd_softdevice_enable" returns with code NRF_ERROR_INVALID_STATE on IAR debugger reset when bootloader is flashed

[Federico]

Hi,

I'm developing on the current setup:

• nRF52833 DK, emulating an nRF52820. 
• Soft Device 113 version 7.2.0
• SDK 17.1.0, with updated MDK (see link)
• IAR EW ARM 9.30

I'm having issues with the debugger on my project. The issues seem to arise from including the secure bootloader based on example "\examples\dfu\secure_bootloader\pca10100e_s112_ble". 

The linker configuration for the bootloader project is:

/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x38000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__   = 0x38000;
define symbol __ICFEDIT_region_ROM_end__     = 0x3dfff;
define symbol __ICFEDIT_region_RAM_start__   = 0x200022c8;
define symbol __ICFEDIT_region_RAM_end__     = 0x20007fff;
export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__   = 2048;
define symbol __ICFEDIT_size_heap__     = 0;

And the application linker configuration is:

/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x1C000;

/*-Memory Regions-*/

// FLASH
define symbol __ICFEDIT_region_ROM_start__   = 0x1C000;				
define symbol __ICFEDIT_region_ROM_end__     = 0x37fff;				

// RAM
define symbol __ICFEDIT_region_RAM_start__   = 0x20003DA8;		
define symbol __ICFEDIT_region_RAM_end__     = 0x20007fff;		

export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__   = 3072;
define symbol __ICFEDIT_size_heap__     = 0;

I generate the dfu settings with the following command (note I'm using everything as if it were the nRF52820, whereas I'm actually flashing on a nRF52833 DK)

nrfutil settings generate --family NRF52QFAB --application app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 dfu_settings.hex

After that, I merge all hex files (bootloader, dfu_settings, app and softdevice) using the mergehex utility. Because IAR's J-Link driver can't flash the UICR addresses, I'm flashing the fully merged image using jprog with this command:

nrfjprog.exe --program Fullimage.hex --family NRF52 --verify --recover --log

Then I start a debugging session with IAR, which flashes the App and SoftDevice on top of that again and runs to main. This appears to work fine: the app executes and I can connect and communicate. The DFU fails when I run it for some reason, nRF Connect Desktop crashes and the Android version gets stuck in a loop of starting, connecting, etc. but I guess that's an issue for another post (here)

The issue at hand here is that if I reset the debugger hitting the "Reset" button in IAR or if I add the "--reset" flag to the nrfjprog,  When our app calls "nrf_sdh_enable_request" to enable the SoftDevice, sd_softdevice_enable returns with code NRF_ERROR_INVALID_STATE. Apparently this means that the SoftDevice has already been initialized, but this doens't seem to be the case (not by the app at least, there's no call to enable it before).

Calling NVIC_SystemReset doesn't trigger this error. Without including the bootloader (just flashing SoftDevice and app from IAR when debugging starts on a blank chip), it works just fine, the IAR Debugger reset doesn't generate the error.

This post seems like a very similar problem, but I can't figure out if it's the same thing. For one, I haven't modified the bootloader example an I'm on a much newer SDK.

Thanks for the help!

Thank you!

[Hung Bui]

Hi Federico, 

I think we can try to solve the other case first before continue to this one. 

But my observation with SES is that it doesn't re-flash the softdevice and application if they are already flashed on the board. And I can debug the application after the bootloader finished booting and jumped to the application. 
In your case, there is a chance that after IAR flash the softdevice, the bootloader would run and when it's running the application is flashed and then IAR jump straight to the application, causing the issue (because the bootloader at that moment would initialize softdevice and might have enabled it). 

I'm not so sure with IAR but is there any option that the debugger can run without reflashing the application ? When you receive NRF_ERROR_INVALID_STATE can you simply do a debug-reset to start debugging again. It's important that the reset wouldn't cause programming again. 

I also suggest to test using a normal BLE example instead of buttonless example. You can modify the bootloader so that it doesn't do CRC checking so that you can directly flash the BLE application without generating bootloader setting. Please check dfu_enter_check() function to remove app_is_valid() check. It's only for debugging. 

[Federico]

Hi Hung,

Thanks for the answer. I'm coming back to this one now that the other issue is solved. This issue stills happens, exactly the same as before, even after that bootloader fix.

In your case, there is a chance that after IAR flash the softdevice, the bootloader would run and when it's running the application is flashed and then IAR jump straight to the application, causing the issue

Although this sounds like a good explanation, I'd say that since nothing changed after solving the other issue, it kind of seems unlikely, because the bootloader wasn't even initializing the soft device properly. Furthermore, IAR is only flashing the application when the debug session starts. The softdevice and bootloader are flashed with:

nrfjprog.exe --program Fullimage.hex --family NRF52 --verify --recover --log

This doesn't include the "--reset" flag, so I'm guessing the nRF should stay reset and not start executing right away, it should wait until the debugging session starts.

I'm not so sure with IAR but is there any option that the debugger can run without reflashing the application ? When you receive NRF_ERROR_INVALID_STATE can you simply do a debug-reset to start debugging again. It's important that the reset wouldn't cause programming again. 

What you mention about simply doing a debug-reset is what I was doing in the first place, how I found the error. I'm pretty sure the reset doesn't cause a programming. Whenever I press the reset button within the debugger and start again, I get this error.

I also suggest to test using a normal BLE example instead of buttonless example. You can modify the bootloader so that it doesn't do CRC checking so that you can directly flash the BLE application without generating bootloader setting. Please check dfu_enter_check() function to remove app_is_valid() check. It's only for debugging. 

I will try to do this and see what happens.

I'm really thinking that what they saw here is somewhat related. To me, this looks like the debugger reset is just moving the PC without triggering the proper reset event or something like that, because NVIC_SystemReset does work. So, somehow, the code that initializes the Soft Device RAM is not running. The post mentions that

The variables in RAM are instead initialized by the reset handler.

When is that handler executed, exactly? How do I now if it's running?

Thanks!

Federico

[Hung Bui]

Hi Federico, 

I assume that if you don't use the bootloader and use only softdevice and application you didn't see the issue ? 

I have seen issue with bootloader and newer compiler compare to what we have used in our SDK development. 

Could you please try to reproduce the issue with IAR v7.80.4 ? And try to test with the stock examples/Bootloader ? 

Regarding your question: 

Federico said:

The variables in RAM are instead initialized by the reset handler.

When is that handler executed, exactly?

The reset handler is pointed to from the top of the vector table after the stack pointer. AFAIK It's executed first when the application/bootloader/MBR booting.