Failure to start due to MBR parameter storage

Hi,

We have an issue that is puzzling us.

The symtoms are the following.

If we flash v1 of our application (using Segger Link) to our target, it works correctly, no issues. We can then perform a DFU to v2 of our application, which also works correctly.

However, if we instead flash our v2 directly, it will start once, but after a second power-on it will run the boot loader, but when starting our application it appears to reset during start-up. From what we can determine, it seems to crash when objects are initialised; no external hardware interactions.

I can then perform the following test.

  1. Flash v1 to the device and start device.
  2. Perform DFU to v2
  3. Copy flash and UICR using nrfjprog
  4. Flash v2 to the device and start device.
  5. Copy flash and UICR using nrfjprog

I can then diff the contents. The UICR is identical between the version. The application flash is identical, except from a few pages that are allocated for persistent storage.

What is different though, is the MBR storage parameters. (Located at address 0x7E000) I would expect them to be similar, as we generate the settings as part of building our application. (Using nrfutils settings generate)

I'm trying to figure out if this is the cause of our issues. However, I cannot find any documentation on how to interpret the MBR storage parameters. I can post the contents here, if they don't contain any sensitive information. Is there any documentation on how to interpret the MBR parameter storage data?

I should mention that the changes between v1 and v2 are very minor.

I cannot directly see any reason why the MBR parameter storage would cause this change in behaviour, but its the only thing we got at the moment, so I would like to investigate it a little further.

  • Hi Vidar,

    Sorry for the late reply. We figured it was highly unlikely that the boot loader would be the culprit, so we went back to start and found that we had incorrectly identified the version where the issue arrived.

    Once we had figured that out, and found a consistent way to reproduce the issue, it was, as expected, an error in our code that caused problems in certain situations.

    Thank you very much for your helpful replies and patience!

Related