This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Internal flash corruption in MBR_PARAM_ADDR flash sector

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

  • Hi !

    1) ../bin-host/nrfjprog/nrfjprog.exe --memrd 0xfb000 --n 4096

    0x000FB000: E37E56AA FFFFFFAA 20006D70 2000473C |.V~.....pm. <G. |
    0x000FB010: 00000000 00000001 00000000 00000000 |................|
    0x000FB020: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB030: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB040: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB050: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB060: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB070: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB080: 00000729 00000733 3DAF01D3 0840008C |)...3......=..@.|
    0x000FB090: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB0A0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB0B0: 0840008C 3DAF01D3 00000733 00000729 |..@....=3...)...|
    0x000FB0C0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB0D0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FB0E0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|

    ...

    ...

    0x000FBFC0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FBFD0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FBFE0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
    0x000FBFF0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|

    2) I can't use the insert image function on the post so here is an imgur link:

    https://imgur.com/a/thl0N1f

    Not  that it should matter but the top of the app has 3 more small splits of memory:

    6299 bytes from 0xA63B9 to 0xA7C53

    5955 bytes from 0xA7C95 to 0xA93D7

    8 bytes bytes from 0xA9419 to 0xA9420

    I don't know why but the new programmer app seems to splits a lot more the different memory chunks.

    Best regards,

    Aloïs

  • Hi,

    The data does not seem to be completely random, but it's not e.g. a valid settings page either. If you don't do any DFU, not using e.g. FDS, or not writing to this address with nvmc functions, then it's not easy to say why this data have been written.

  • 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 

Related