Internal flash corruption in MBR_PARAM_ADDR flash sector

[AKYR]

Hello devzone members,

We are producing a device based on nrf52840 that uses MBR + bootloader and an app with SDK 15.3.0.

We have set up the MBR with MBR_BOOTLOADER_ADDR at the address of the bootloader in flash and MBR_PARAM_ADDR the address of the page just before. 

I'm working on a bug that locks devices in MBR because of a corruption of internal flash. 

The corrupted page is the page pointed by MBR_PARAM_ADDR, and it appears that the MBR tries to read a data there with a wrong value which locks the device.

We don't use any SD_MBR_COMMAND function that require this page in flash so we'll remove them in future deployment which will resolve the lock bug. 

BUT I need to understand why the memory was corrupted in the first place, I reviewed the code and did multiple tests and my setup won't reproduce the corruption. We use only NVMC write functions in the app and only on firmware release.

It could be that  the app corrupts the memory randomly, and only when it is in the MBR page we realize it because it locks the device, but I don't think so because it would have broke the app in other ways  if it was the case.

My guess is that something MBR related could corrupt the memory because we used the MBR_PARAM_ADDR  which definetely access the flash memory even if no  SD_MBR_COMMAND is use. Could you give me your review about this ? 

Thanks in advance,

Regards,

Aloïs KYROU

[Sigurd]

Hi,

1) How many devices did the issue occur on? 1 or multiple?

2) Is this product returned from the field/customers?

3) Are you able to reproduce the issue?

4)

The corrupted page is the page pointed by MBR_PARAM_ADDR,

How do you determine that? What is the content of that page now? and what was it before?

PS:

and an app with SDK 15.3.0.

There are known bugs in FDS in nRF5 SDK 15.3 that could cause file corruption, that have been fixed in recent SDK versions. E.g. from the release notes in SDK 16:

- FDS: fixed two bugs where a power loss at very specific times during garbage
  collection could corrupt the file system, making FDS unable to initialize and return
  FDS_ERR_NO_PAGES on initialization.

But these FDS bugs does not corrupt the Bootloader, only the FDS file system.

BR,

Sigurd

[AKYR]

Hello,

The issues has been resolved. It was corrupted memory on an handler with the address of the handler being the address of the MBR corresponding to a DFU function.

Thanks for your answers ! 

Have a good day,

Aloïs KYROU