nrfutil generate incorrect bootloader settings (for nRF52840)

[Chibi]

Hi,

I'm having an issue with using nrfutil to generate a bootloader settings image for loading onto an nRF52840 MCU. The resulting image appears to have the wrong starting address.

Please find below the steps I followed:

1. I'm using the latest version of nrfutil, which is 6.0.1, e.g.:

2. I create the bootloader settings image for the nRF52840 MCU (SDK 16.0.0), e.g.:

nrfutil.exe settings generate --family NRF52840 --application MainModule.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2  bootloader_settings.hex

Note that the bootloader settings start address indicates 0x000FF000 for the nRF52840 which matches with the SDK 16.0.0 online reference:

3. And now I display the contents of the generated bootloader settings image, e.g.:

nrfutil settings display bootloader_settings.hex

Note that the start address now indicates 0x000FE000. There is also a bad access error.

I manually looked through the INTEL hex image and the extended linear address does appear to be incorrect, e.g.:

:02000004000FEB
:10E000002D73972C020000000100000001000000A9
:10E010000000000000000000D4200300C93D087C7F
:10E0200001000000000000000000000000000000EF
:10E0300000000000000000000000000000000000E0
:10E0400000000000000000000000000000000000D0
:10E0500000000000000000000000000000000000C0
:10E0600000000000000000000000000000000000B0
:10E0700000000000000000000000000000000000A0
:10E080000000000000000000000000000000000090
:10E090000000000000000000000000000000000080
:10E0A0000000000000000000000000000000000070
:10E0B0000000000000000000000000000000000060
:10E0C0000000000000000000000000000000000050
:10E0D0000000000000000000000000000000000040
:10E0E0000000000000000000000000000000000030
:10E0F0000000000000000000000000000000000020
:10E10000000000000000000000000000000000000F
:10E1100000000000000000000000000000000000FF
:10E1200000000000000000000000000000000000EF
:10E1300000000000000000000000000000000000DF
:10E1400000000000000000000000000000000000CF
:10E1500000000000000000000000000000000000BF
:10E1600000000000000000000000000000000000AF
:10E17000000000000000000000000000000000009F
:10E18000000000000000000000000000000000008F
:10E19000000000000000000000000000000000007F
:10E1A000000000000000000000000000000000006F
:10E1B000000000000000000000000000000000005F
:10E1C000000000000000000000000000000000004F
:10E1D000000000000000000000000000000000003F
:10E1E000000000000000000000000000000000002F
:10E1F000000000000000000000000000000000001F
:10E20000000000000000000000000000000000000E
:10E2100000000000000000000000000000000000FE
:10E2200000000000000000000000000000000000EE
:10E2300000000000000000000000000000000000DE
:10E2400000000000000000000000000000000000CE
:10E25000000000000000000000000000296520D53B
:10E2600000000000000000000000000000000000AE
:10E27000000000000000000000000000000000009E
:10E28000000000000000000000000000000000008E
:10E29000000000000000000000000000000000007E
:10E2A0000001C93D087C00000000000000000000E3
:10E2B000000000000000000000000000000000005E
:10E2C000000000000000000000000000000000004E
:10E2D000000000000000000000000000000000003E
:10E2E000000000000000000000000000000000002E
:10E2F000000000000000000000000000000000001E
:10E30000000000000000000000000000000000000D
:10E3100000000000000000000000000000000000FD
:03E32000000000FA
:10F000002D73972C02000000010000000100000099
:10F010000000000000000000D4200300C93D087C6F
:10F0200001000000000000000000000000000000DF
:10F0300000000000000000000000000000000000D0
:10F0400000000000000000000000000000000000C0
:10F0500000000000000000000000000000000000B0
:10F0600000000000000000000000000000000000A0
:10F070000000000000000000000000000000000090
:10F080000000000000000000000000000000000080
:10F090000000000000000000000000000000000070
:10F0A0000000000000000000000000000000000060
:10F0B0000000000000000000000000000000000050
:10F0C0000000000000000000000000000000000040
:10F0D0000000000000000000000000000000000030
:10F0E0000000000000000000000000000000000020
:10F0F0000000000000000000000000000000000010
:10F1000000000000000000000000000000000000FF
:10F1100000000000000000000000000000000000EF
:10F1200000000000000000000000000000000000DF
:10F1300000000000000000000000000000000000CF
:10F1400000000000000000000000000000000000BF
:10F1500000000000000000000000000000000000AF
:10F16000000000000000000000000000000000009F
:10F17000000000000000000000000000000000008F
:10F18000000000000000000000000000000000007F
:10F19000000000000000000000000000000000006F
:10F1A000000000000000000000000000000000005F
:10F1B000000000000000000000000000000000004F
:10F1C000000000000000000000000000000000003F
:10F1D000000000000000000000000000000000002F
:10F1E000000000000000000000000000000000001F
:10F1F000000000000000000000000000000000000F
:10F2000000000000000000000000000000000000FE
:10F2100000000000000000000000000000000000EE
:10F2200000000000000000000000000000000000DE
:10F2300000000000000000000000000000000000CE
:10F2400000000000000000000000000000000000BE
:10F25000000000000000000000000000296520D52B
:10F26000000000000000000000000000000000009E
:10F27000000000000000000000000000000000008E
:10F28000000000000000000000000000000000007E
:10F29000000000000000000000000000000000006E
:10F2A0000001C93D087C00000000000000000000D3
:10F2B000000000000000000000000000000000004E
:10F2C000000000000000000000000000000000003E
:10F2D000000000000000000000000000000000002E
:10F2E000000000000000000000000000000000001E
:10F2F000000000000000000000000000000000000E
:10F3000000000000000000000000000000000000FD
:10F3100000000000000000000000000000000000ED
:03F32000000000EA
:00000001FF

Any ideas what I'm missing or doing wrong?

Thanks to all in advance.

[Edvin]

Hello,

The bootloader settings doesn't actually start before 0x000FF000, but the MBR parameters are stored from 0x000FE000, as it says in the memory range table that you have posted.

So this is expected.

Best regards,

Edvin

[Chibi]

Hi Edvin,

Thanks for your reply but I am still a bit confused. I agree with your observation but that is not what I'm seeing (I think) from the generated bootloader settings image.

From what I can see in the bootloader settings hex image, the settings is written to flash starting from address 0x000FE000 and ends at address 0x000FE320. There is an additional block which is written between address 0x000FF000 and 0x000FF320.

Is this the backup page (0x000FE000 - 0x000FE320) - the contents and size looks identical to the second block? As per your observation, this memory is reserved for the MBR parameter storage.

Cheers,

Chibi

[Edvin]

Hello Chibi,

I don't know exactly what is written where (you would have to look at the implementation of nrfutil for that), but I get the same output as you when I use the settings display command, the "Bad access" message. It has been around for a while, but I don't think it actually does any harm. You can check the nrfutil implementation for why it is printed. However, the settings file works just fine (also tested with the same version that you use).

Do you experience any issues with the settings file? If so, can you please describe the symptoms? In my opinion, everything looks good.

[Chibi]

Hi Edvin,

I am having some issues with a hard fault when used in conjunction with the secure bootloader and the bootloader settings. Whilst debugging, I spotted the oddity with the bootloader settings.

I don't think that is the cause of the issue I am seeing but I just wanted to understand that the settings I have created is valid because the documentation is perhaps not 100% clear (or more likely I failed to read it properly).

Thanks.

[Edvin]

Are you sure it is a hardfault? 

Did you do any changes to the bootloader project? If so, can you try to unzip an unmodified version of the SDK, and check if it behaves the same. If so, try the ..._debug project for the bootloader (if you use pca10056_ble now, use pca10056_ble_debug instead) and monitor the RTT log output. What does it say?

Perhaps the bootloader is working, but the application crashes before it has time to do anything sensible (that you can see in the log/LEDs)?

If not, the bootloader log should reveal some information.

Best regards,

Edvin

[Chibi]

Hi Edvin,

The hardfault is happening in my main application (which uses SoftDevice S140 7.0.1) on my custom hardware. It was reported by my IAR debugger.

Actually, I have tried the DFU bootloader a while ago and confirmed its correct operation on the dev kit.

Perhaps you can help me with a slightly different question? If I called sd_nvic_SystemReset (e.g. to enter the secure bootloader from my main application, after setting the GPREGRET register with 0xB1), does it preserve the GPIO settings or will they get reset as well?

Thanks.

[Edvin]

Hello,

The GPIOs are reset by a soft reset (sd_nvic_SystemReset). You can see the reset behavior for different peripherals based on different reset reasons in this table.

[Chibi]

Hi Edvin,

Thanks for the URL link - it was very informative.

I may have also solved my original issue concerning the hard fault (in my main application) - at least  I'm no longer seeing it for the time being.

I have another unrelated question - do you mind if I ask it here or should I create another case? My new issue concern the usage of the RTC (Real Time Counter) peripheral.

Thanks again.

[Edvin]

I think we should take it in a new case, because it may be helpful for other users as well. And it is certainly easier to find if it is related to the title of the case

Best regards,

Edvin

[Chibi]

That's a good idea, I'll open a new case. Thanks.