Bank 1 DFU settings empty in bootloader after custom DFU in app

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

TOCGRE — Wed, 17 May 2023 09:36:15 GMT

Hi,

I've found the issue : the nrf52832 does not behave the same way with or without debugger attached when logs are enabled in release config.

As my app size is too big in debug config to do a dual bank DFU, I just added some logs to the release config to make the app smaller and enable dual bank DFU.

When debugger is attached, the whole dfu process goes on without any error and new bootloader settings are written correctly. However if I attach debugger in the app project the program gets stuck when resetting to the bootloader (I still don't know why). So the only way I found to debug the bootloader was to wait for the app to make DFU without attaching the debugger and attach the debugger as soons as the bootloader starts (supposedly at the end of the DFU process in app) thanks to a LED blink. But when running app without attaching debugger, I discovered that an error occurs and leads to a reset (which I thought was the one at the end of successful DFU process). Thus the bootloader I'm debugging does not find new firmware info in bootloader settings. Hence the bootloader starts and launches the current app in bank0.

I found that this error occuring during the in app DFU was due to logs. So I just disabled the logs in release config and copying the bank1 to bank0 and jumping to it works !

So I don't know exactly what the problem is but I guess that mayby logs in release are in conflict with dfu modules or share a common area in flash...

Anyway thanks for helping me

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

Einar Thorsrud — Tue, 16 May 2023 14:07:08 GMT

Hi,

[quote user="TOCGRE"]What can happen during the reset that can change flash in bootloader settings section ?[/quote]

The reset itself does not cause any writing to flash, so it would have to be either the application before the reset, or the bootloader after. And the bootloader will normally only write to bootloader settings during a DFU update, and if some of the "forbidden" parts have been changed. If this change does not happen during settings_forbidden_parts_copy_from_backup(), perhaps you can experiment with setting a breakpoint (or an eternal loop to prevent further execution or something else) in the bootloader and moving it around to try to narrow down where the data is changed (there are not that many part of the bootloader that writes to the bootloder settings page)?

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

TOCGRE — Fri, 12 May 2023 13:51:48 GMT

Hi,

Thanks for the reply.

After looking closer, the bank_1 part of struct s_dfu_settings is also empty in my app when dfu is completed so I guess it is normal to get it empty from the bootloader after the reset. My problem is just for bank_current.

As you mention it I confirm that my app successfully copies the init packet to the bootloader settings at the beginning of DFU.

I've investigated a little more and the issue does not seem to come from settings_forbidden_parts_copy_from_backup() function in the bootloader.

I have looked to flash memory closer and at the bootloader settings address 0x0007F000 data are not the same when the app ask for reset and when the bootloader starts. It seems that data is lost in between.
When I call nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_RESET); in the app to reset right after custom DFU, the bank_current value at address 0x0007F014 is 0x01. But at the beginning of the bootloader (first instruction of main()) the bank_current value at address 0x0007F014 is 0x00.

So I was wondering if bootloader settings were considered to be at the same flash memory address in the app and in the bootloader but apparently in both projects m_dfu_settings_buffer[] is set at address 0x0007F000. Thus both projects are reading/writing the same flash area.

What can happen during the reset that can change flash in bootloader settings section ?

I also tried to migrate the SDK to 17.1.0 but it does not solve the issue.

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

TOCGRE — Fri, 12 May 2023 07:22:09 GMT

Hi erk1313,

Thanks for helping ! It seems that ACL registers are only for nrf52840. On nrf52832 only BPROT peripheral is used to protect memory but I did not find any related issue in my case.

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

erk1313 — Fri, 05 May 2023 17:30:11 GMT

Check ACL register for what regions are protected:

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

erk1313 — Fri, 05 May 2023 14:22:27 GMT

Could it be that dfu settings is write protected by ACL and though the write operation returns success, it actually failed to write?

// <i> The settings page may be used to exchange information between the bootloader and the application.
// <i> In that case it should not be protected.

#ifndef NRF_BL_SETTINGS_PAGE_PROTECT
#define NRF_BL_SETTINGS_PAGE_PROTECT 1
#endif

RE: Bank 1 DFU settings empty in bootloader after custom DFU in app

Einar Thorsrud — Tue, 02 May 2023 08:09:51 GMT

Hi,

[quote user=""]1. Is my understanding of postvalidation ok ? The app dfu modules write the necessary settings to flash for the bootloader to postvalidate, activate and swap bank1 and 0. The postvalidation is made in the bootloader since I set NRF_DFU_IN_APP to 1 in my app sdk_config.h.[/quote]

Yes, this is correct. I do not see all you have done, but I wonder if the issue here is related to the backup and restoration of the bootloader settings page. The current bank is overwritten as you can see from the implementation of settings_forbidden_parts_copy_from_backup() in components/libraries/bootloader/dfu/nrf_dfu_settings.c. Based on what you write, it could be that it would be enough to remove the line that copies the bank_current from the backup. Byt normally the bootloader would handle this for you, as long as you have copied the init packet to the bootloader settings (this is not overwritten by the backup when you have NRF_BL_DFU_ALLOW_UPDATE_FROM_APP enabled). See this post for more on that.

[quote user=""]2. Why is s_dfu_settings empty for bank1 in the bootloader ?[/quote]

If s_dfu_settings.bank_1 was not empty before, then the only reason I can think of that would make it empty is if nrf_dfu_bank_invalidate() was called with it's address. And this happens close to the end of postvalidate().

[quote user=""]3. More generally, do you have an idea why my bootloader does not copy the new firmware from bank1 to bank0 ?[/quote]

I believe it is because of the backup restoration explained above, which means that the active bank will be reverted to bank0.

PS: I recommend that you use nRF5 SDK 17.1.0 instead of 17.0.2, as that has support for the latest revision of the nRF52832 (alternatively you must update the MDK as explained in IN142).