Failure to start due to MBR parameter storage

[obbe]

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.

[Vidar Berg]

Hello,

The MBR param page is mostly used by the bootloader as backup to mirror the bootloader settings page. Although, its main purpose is to give the MBR a flash page it can keep persistent state information in during DFU of the bootloader itself (Master boot record).

Either way, based on the sequence you describe (i.e. booting up for the 2nd time), I would expect the MBR param page to contain a copy of your bootloader settings page.

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.

Does it appear to enter a boot loop, or does it get "stuck" somewhere? If it gets stuck, can you run "nrfjprog --readregs" to find out where?

Best regards,

Vidar

[obbe]

Hi,

Thanks for taking the time to look into our issue.

 I’ve read the reference to the MBR, and I can’t find anything in that, that would point to the MBR being involved. But since it’s the only difference I can find, I was wondering if there was more to it than described in the documentation, or (much more likely) something I failed to understand and connect to our issue.

We have two spare GPIO. I used one in the bootloader and can see that it starts and exits. I used the second in the application main and can see that it also enters. Then it is a bit unclear what happens. We have a C++ application with a “composition root”, meaning we call a lot of constructor methods. The constructors don’t do any external interaction and usually no logic. There could be occasional register writes. (For instance, I believe GPIO will write register to configure pins) This code never exits. Then, the bootloader starts again, indicating it was reset. (I presume)

The period is around 330ms. (Which would be plenty of time for all constructors to finish) The watchdog is configured to 500ms, and if we change the period to 2s, the pattern is the same.

I have not (yet) verified that the GPIO modification still works with DFU, but I would expect so. (Again, the application is identical when dumping the flash)

[Vidar Berg]

Thanks for clarification. I have a few follow up questions that I hope can help narrow down the problem a bit more:

1.

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.

What do J-link SW to you use to load the hex file with? Is it nrfjprog, through an IDE such as Segger embedded studio, or something else?

2. Did you load the bootloader settings page along with the application? At least with the original SDK bootloader, the settings page is required to mark the application as valid to the bootloader (it will fall back to DFU mode if this page is not configured - Generating and displaying bootloader settings).

3. What SDK version is the bootloader based on? If version > 15.2.0, did you set the bootloader settings version to '2' ( "--bl-settings-version 2")

4. Does the device recover after a reset, or does it keep going in a reset loop?

Thanks,

[obbe]

Hi,

1. We use nrfjprog. We've also tried different JTags to check that its not associated with that.
2. Yes, I think so. I've included the full commands to generate our image file below. (Both what we are flashing in production, as well as the .zip-file for DFU) If I output the boot loader settings from the two flash dumps, they are equal. (But, as mentioned, the MBR storage parameters in flash are different)
3. The boot loader is based on SDK 12.
4. No, its stuck in a reset loop.

nrfutil settings generate --family NRF52 --application build/APP_NAME.hex --application-version 10203 --bootloader-version 1 --bl-settings-version 1 build/APP_NAME_settings.hex
mergehex --merge build/APP_NAME_settings.hex build/APP_NAME.hex --output build/APP_NAME_BL
mergehex --merge build/APP_NAME_BL s132_nrf52_3.0.0_softdevice.hex bootloader/BOOTLOADER.hex --output build/APP_NAME_IMAGE.hex
nrfutil pkg generate --hw-version 52 --application-version 10203 --application build/APP_NAME.hex --sd-req 0x8C --key-file cfg/private.key build/APP_NAME.zip

I'm calling these v1 and v2, but they are in fact not the first and second releases. We've done a handful before, but never had this behaviour. We haven't changed boot loader or the way we build our production images.

[Vidar Berg]

Hi,

We did not have the bootloader use the MBR param page for backup in SDK v12. So in this version, the values should normally only have been populated by the MBR itself.

Can you check your hex files to see if any of them may contain data in this area, or if the MBR page is being written to at runtime by the bootloader/application? I can to it as well if you are able to share your hex files here or in a private support ticket.

[obbe]

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!