NICLA SENSE ME (nRF52832) Undefined Behavior in Bootloader

[ijf1]

HI,

Following is the procedure to flash application we have tried:

1. Mass Erase
2. Write bootloader start address
3. Flash soft device
4. Flash bootloader 
5. Flash application 

The application loads perfectly when we follow the above procedure. I can re-flash application / bootloader when the board is on with application running.

We have implemented push button press to switch to boot mode. Once the board switches to boot mode, that is with ble_dfu_bootloader and if I try to flash application or re-flash the bootloader itself the bootloader crashes with signal interrupt.  The signal interrupt is randomly getting generated in bootloader. 

A reference screenshot is given below.

Also observed that, an led is kept ON to indicate boot mode. That led keeps glowing even if i flash application or re-flash bootloader. Button press is configured as interrupt, that also does not work in this scenario. The only way to get out is power cycle the board.

But if I power cycle the board, the recently flashed application get loaded successfully. 

Any suggestion would be really appreciated. Thanks.

Regards,

Ijaz  

[Vidar Berg]

Hello,

From your call stack, it looks like the fault exception may be triggered by the call to sd_softdevice_disable(). Is this function being called in an interrupt context, and in that case, what is the interrupt priority of the interrupt it's called from?

Regards,

Vidar

[ijf1]

Hi Vidar,

The fault exception is triggered from random positions in the code. Why fault exception is getting triggered when i flash application from bootloader through OpenOCD command.

It is not being called in an interrupt context.

Regards,

Ijaz

[Vidar Berg]

Hi,

Thanks for confirming. Is the exception only raised after flashing with openocd? I.e. are you able to enter dfu mode afterwards when you have performed a power on reset?  Also, you say it is triggered from random positions, do you have stack trace showing it crashing in another place?

[ijf1]

Sure Vidar.

Please see below screenshot. The line 285 in app_switch() is " nrfx_timer_init "

Yes, If I do a power on reset it loads the application.

[Vidar Berg]

This trace is basically showing the same failure as in the original one you shared. Can you post the app_switch() implementation here, or try to comment sd_softdevice_disable() function and see if you get the same error?

ijf1 said:

Yes, If I do a power on reset it loads the application.

Maybe I'm misunderstanding how it is supposed to work, but my question is if the mechanism used to enter boot mode starts working after a power cycle, or if it still crashes with the same error.

[ijf1]

If I comment sd_softdevice_disable() function, its working fine.

please find below app_switch() implementation (in bootloader code):

{

sd_mbr_command_t com = { SD_MBR_COMMAND_INIT_SD, };

(void) sd_mbr_command(&com);

(void) sd_softdevice_disable();

void (*App_ResetJumpAddr)(void);

#Logic to check magic location for a specific key word. Depending on the key word found, it decides whether to stay in bootloader or load application

} 

[Vidar Berg]

The (void) sd_softdevice_disable(); function is redundant here as the Softdevice is being initialized right before by the MBR command.

I'm not sure why it is crashing though. Maybe the openocd script is changing the PC register when it programs the bootloader?

[ijf1]

Can you please explain how sd_softdevice_disable(); function is redundant. This code is being ported to nicla. I have not seen any enable api in bootloader. 

Is this disable api really required logically ?

As I understand after flashing the program, the openocd does attempt modify CPU state and PC.

[Vidar Berg]

I have not seen this code before nor do I know the reason for why sd_softdevice_disable(); was added in the first place. But I know that you can't issue the SD_MBR_COMMAND_INIT_SD command if the SD is already enabled.

ijf1 said:

As I understand after flashing the program, the openocd does attempt modify CPU state and PC.

The debugger should be configured so it does not alter the boot sequence described here: Master boot record and SoftDevice reset procedure. That is, it must let the execution start from address 0x4 and not directly from the bootloader.