Device HANG - Program counter stuck at __SEV() (Address 0x00078d58)

[shreyab]

I'm using SDK 15.1, nRF52 in custom units, toolchain GDB, addr2line

A little background -

• We use System off mode and then use a button press to come out of it.
• Before going back to system off mode again, we delete all flash records (requirement calls)
• While repeating above sequence, System hung and would not respond to button press.

Debugging Observations-

• arm-none-eabi-gdb was used to find the point of hang
• debugger also stuck at Address 0x00078d58 which is at __SEV()
• using  $nrfutil settings display file.hex on this hanged unit and another working unit of same version, the bootloader version was found to be different (ie 5 ) instead of 0 as is in the working unit.

What can be the possible reasons for this? Can anybody please help, Thanks.

[bjorn-spockeli]

We use System off mode and then use a button press to come out of it.

Are you entering System OFF from the application or the bootloader? Have you configured the button to be a wakeup source in both the bootloader and the application?

debugger also stuck at Address 0x00078d58 which is at __SEV()

 The address indicated that you're in the bootloader. Are using the SoftDevice in your bootloader is it not dependent on the SD? The __SEV() function is used in the wait_for_event() function, so the bootloader is simply waiting for an event. 

Best regards

Bjørn

 

[shreyab]

bjorn-spockeli said:

Are you entering System OFF from the application or the bootloader? Have you configured the button to be a wakeup source in both the bootloader and the application?

We are entering System OFF from the application, and we have configured the button to be a wakeup source in JUST the application.

bjorn-spockeli said:

Are using the SoftDevice in your bootloader is it not dependent on the SD?

Bootloader is not dependent on softdevice.

UPDATE -

Further investigation reveals that, both data storage flash pages are full (probably corrupted) and in certain addresses there are random characters stored in ASCII sequence (the swap space is empty though and not at all corrupted).

[bjorn-spockeli]

OK,  if the bootlaoder is SD independent then it will call __SEV() as a part of the wait_for_event() function which is called in the infinite for loop. So for some reason you are not jumping from the bootloader to the application when waking up from SystemOFF. 

shreyab said:

Further investigation reveals that, both data storage flash pages are full (probably corrupted) and in certain addresses there are random characters stored in ASCII sequence (the swap space is empty though and not at all corrupted).

How are you erasing the pages prior to entering SystemOFF? Are you using the NVMC directly to do the erase or are you using the fstorage or FDS APIs?

[shreyab]

bjorn-spockeli said:

How are you erasing the pages prior to entering SystemOFF?

yes, we are waiting for FDS_EVT_DEL_RECORD  event before entering into System OFF.

bjorn-spockeli said:

Are you using the NVMC directly to do the erase or are you using the fstorage or FDS APIs?

We are using fds APIs for all flash related activities.

[bjorn-spockeli]

Ok, are you running the garbage collection, i.e. fds_gc, to reclaim the flash space? fds_record_delete only marks the record for deletion. Quote from the FDS API documentation.

Note that deleting a record does not free the space it occupies in flash memory. To reclaim flash space used by deleted records, call fds_gc to run garbage collection.