flash sharing of bootloader and app

RE: flash sharing of bootloader and app

name — Thu, 16 Jan 2025 10:45:20 GMT

[quote userid="4240" url="~/f/nordic-q-a/117055/flash-sharing-of-bootloader-and-app/513789"]

[/quote]

我明白了，我又看了你之前的记录，结合后台的DFU例子，我理解的是在应用程序中往bank1写入bin文件数据，每次通过flash写入的时候更新setting里的进度就可以了吗？但是下面这些内容的更新我不太明白
1. firmware_image_offset 能不能是我每次往bank1写入的固件数据的大小？
2. command_size，command_offset，command_crc，data_object_size 能不能不更新，因为我好像不需要这些命令。

正如你之前回答中所说，settings 会自动计算 CRC。如果我直接通过 flash 更新上面的 stttings 内容，它也会自动计算 CRC 吗？还是只有在使用 settings 模块时才会自动计算？

RE: flash sharing of bootloader and app

Vidar Berg — Thu, 16 Jan 2025 09:58:44 GMT

First you need to "memcpy" the original settings page to your write buffer, then you can change the struct members which the app is allowed to change. The app is *not* allowed to update .bank_0 and .bank_1, see the picture I posted earlier. You also need to update the CRC to match the new settings. You can use the settings module as a reference if you don't want to use this module in your app.

RE: flash sharing of bootloader and app

name — Thu, 16 Jan 2025 09:16:25 GMT

Yes, I use nrfjprog --memrd 0xFF000 to read data.
This is the new content of the settings page I wrote. I did not use the settings module to write the settings page content, because I found that using the settings module requires adding some settings module library files in the bootloader. During the adding process, I encountered some difficulties (reporting undefined), so I wrote directly through flash. As for settings_crc_ok, it is rewritten in the application with reference to the bootloader.
I checked the relevant background DFU examples, and the application has a settings page module. To add the settings page module, do I need to add some macros in the sdk.config of the application?
In addition, the project originally used FDS, which involves initializing fstorage when upgrading the firmware. I don’t know if this is the reason
。

RE: flash sharing of bootloader and app

Vidar Berg — Thu, 16 Jan 2025 08:37:46 GMT

What does the settings page contain after programming the application and bootloader and resetting the device?

Reading settings page with nrfjprog

nrfjprog --memrd 0xFF000 --n 256

[quote user="hklsa"]. However, settings_crc_ok cannot verify the CRC (i.e., the result of settings_crc_ok is 0). The value read from address 0xFF000 through nrfjprog also does not match what I wrote. I wonder why.[/quote]

Do you use the settings module to write to the settings page? This will automatically compute a new crc when you write something to it. Also, what values are you trying to change? Remember that there are several of the struct elements which the app is not permitted to change. Doing so will cause the bootloader to restore the original settings from the backup page at 0xFE000

RE: flash sharing of bootloader and app

name — Thu, 16 Jan 2025 03:35:27 GMT

Sorry, I always fail to set breakpoints in the bootloader. I plan not to modify any code in the bootloader. This article devzone.nordicsemi.com/.../dfu-approach-from-cloud-to-esp32-to-nrf52840 explains the cloud to nrf52840 DFU approach. The original value of nrf_dfu_settings_t that I read from flash in the application is 0. After writing some values to flash, they are read correctly. However, settings_crc_ok cannot verify the CRC (i.e., the result of settings_crc_ok is 0). The value read from address 0xFF000 through nrfjprog also does not match what I wrote. I wonder why.

RE: flash sharing of bootloader and app

Vidar Berg — Tue, 07 Jan 2025 06:22:35 GMT

Did you place a breakpoint in the bootloader's error handler?

RE: flash sharing of bootloader and app

name — Tue, 07 Jan 2025 01:54:45 GMT

Hello, I'm sorry, I followed your instructions, may be the reason for my operation, and failed to solve the problem. Can I provide bootlaoder program and seek effective help?

RE: flash sharing of bootloader and app

Vidar Berg — Mon, 16 Dec 2024 15:44:35 GMT

You can debug the bootloader the same way you debug your application. The difference is that you need to open the bootloader project in Keil instead. The application project does not include the debug symbols needed to debug the bootlaoder.

RE: flash sharing of bootloader and app

name — Mon, 16 Dec 2024 03:36:10 GMT

Hello, I tried extending the watchdog timer in the app, but it didn't solve the problem. I tried setting breakpoints in Keil, but when the debugger jumped to the bootloader, it disconnected. I wonder if there's something wrong with my debugging method. I would like to ask how to set breakpoints for debugging in the bootloader, or if there are any tools or related documentation.

RE: flash sharing of bootloader and app

Vidar Berg — Thu, 12 Dec 2024 09:57:43 GMT

Hello,

The bootloader will feed the watchdog if it sees that it is enabled by the application prior to entering dfu mode, but it will not enable it. Can you please a breakpoint in the bootloader's error handler to see if the error may have been triggered by a runtime error?

RE: flash sharing of bootloader and app

name — Thu, 12 Dec 2024 07:29:51 GMT

Hello, thank you very much for your time. Now I can successfully write firmware data to bank_1 area through the app, and I can also successfully pass the verification of setting after entering the bootloader. I have successfully made the bootloader recognize the firmware data written by me as valid. However, the problem is that the process of copying firmware data from bank_1 to bank_0 in the bootloader is restarting. The following is the run log. The log for the first image shows that the watchdog turned on when entering image_copy is not turned on. I wonder if that's what caused the reboot?

RE: flash sharing of bootloader and app

Vidar Berg — Tue, 10 Dec 2024 10:45:20 GMT

Hello,

The bank 1 start address should be found using the nrf_dfu_bank1_start_addr() function. It is based on the start address and size of the current application image. If you use another address than this, the bootloader will not be able to activate the update.

[quote user="hklsa"]Update_start_address, s_dfu_settings bank_1. Image_size, s_dfu_settings.bank_1.image_crc, s_dfu_settings.bank_1.bank_code, s_dfu_settings.crc.[/quote]

The application is not permitted to change .bank_1.

[quote user="hklsa"]But init_command looks like something like a command, how do I change it?[/quote]

The init command contains metadata about the update which is needed by the bootloader to activate the update and should be uploaded along with the binary image. The init command is created with nrfutil.

[quote user="hklsa"]NRF_BL_DFU_ALLOW_UPDATE_FROM_APP is enabled in sdk_config.h, it will not protect the Settings page". I also want to keep the original BLE OTA way. NRF_BL_DFU_ALLOW_UPDATE_FROM_APP Should I disable it?[/quote]

You will still be able to perform dfu within the bootloader with this setting enabled.

RE: flash sharing of bootloader and app

name — Fri, 06 Dec 2024 10:08:01 GMT

Hello, I have changed the method now.
Create a flash space (shared by app and bootlaoder) to store bank_1's new address, firmware size, and whether or not to customize OTA tags. Enter bootloader back to read the original s_dfu_settings to modify these values s_dfu_settings after RAM. The progress. Update_start_address, s_dfu_settings bank_1. Image_size, s_dfu_settings.bank_1.image_crc, s_dfu_settings.bank_1.bank_code, s_dfu_settings.crc. As you said I should modify bank_current and init_command again, right? But init_command looks like something like a command, how do I change it?
Also, as you said "NRF_BL_DFU_ALLOW_UPDATE_FROM_APP is enabled in sdk_config.h, it will not protect the Settings page". I also want to keep the original BLE OTA way. NRF_BL_DFU_ALLOW_UPDATE_FROM_APP Should I disable it?

RE: flash sharing of bootloader and app

Vidar Berg — Fri, 06 Dec 2024 09:44:23 GMT

Hello,

The bootloader enables read and write protection on itself with the ACL before booting the application. However, it will not protect the settings page if you have the bootloader built with NRF_BL_DFU_ALLOW_UPDATE_FROM_APP enabled in sdk_config.h.

Note that the app can only changes that are not within the red squares below, those are off limits to the app. Therefore you must load the stored values for the other elements into your RAM buffer. The app must not write to the backup either, the bootloader is responsible for that.

The struct elements you must update to make the bootloader activate your update are: crc (is the checksum of settings struct - see settings_module for how it is calculated), bank_current (set it to bank 1), progress, and init_command.

RE: flash sharing of bootloader and app

name — Fri, 06 Dec 2024 09:11:18 GMT

Hello, I have solved the above problem, and now there is a new problem:
When the bootloader copies the new firmware from bank1 to bank0, there is a dead loop when the app is finally started. The run log file is as follows

The background to these questions is: The nrf52840 external 4G module sends the firmware data to the app through http, and then the app saves the firmware data to bank_1 through flash, and then modifies these configurations in the bootloader, so that the bootloader copies the bank_1 data to bank_0. Here is the code added to the bootloader

void nrf_dfu_settings_reinit(void)
{
// nrf_dfu_flash_read(0xFF000, m_dfu_settings_buffer, sizeof(new_dfu_setting_t));
bool settings_valid = settings_crc_ok();
bool settings_backup_valid = settings_backup_crc_ok();


if (settings_valid)
{
NRF_LOG_DEBUG("Using settings page.");
memcpy(&s_dfu_settings, m_dfu_settings_buffer, sizeof(nrf_dfu_settings_t));
new_dfu_setting_t new_dfu_setting = {0};

uint32_t setting_addr = 0;
// setting_addr = 0x27000 + s_dfu_settings.bank_0.image_size;
// setting_addr += 4096;
nrf_dfu_flash_read(0x78000, &new_dfu_setting, sizeof(new_dfu_setting_t));
NRF_LOG_INFO("new_dfu_setting.flag: %d", new_dfu_setting.flag);
NRF_LOG_INFO("new_dfu_setting.fw_addr: 0x%08x, new_dfu_setting.fw_size: 0x%08x", new_dfu_setting.fw_addr, new_dfu_setting.fw_size);
if(new_dfu_setting.flag == 0x01)    //Added the user-defined OTA mode, which is directly written to s_dfu_settings.
{
s_dfu_settings.progress.update_start_address = new_dfu_setting.fw_addr;
s_dfu_settings.bank_1.image_size = new_dfu_setting.fw_size;
s_dfu_settings.bank_1.image_crc = crc32_compute((uint8_t*)(s_dfu_settings.progress.update_start_address),s_dfu_settings.bank_1.image_size,NULL);
s_dfu_settings.bank_1.bank_code = NRF_DFU_BANK_VALID_APP;
s_dfu_settings.crc = settings_crc_get(&s_dfu_settings);
memcpy(s_dfu_settings.boot_validation_app.bytes, &s_dfu_settings.bank_1.image_crc, 4);
ret_code_t err_code = nrf_dfu_settings_write(NULL);
if(err_code != NRF_SUCCESS) return;

new_dfu_setting.flag = 0;
err_code = nrf_dfu_flash_store(0x78000, &new_dfu_setting, sizeof(new_dfu_setting_t), NULL);
if(err_code == NRF_SUCCESS)
NRF_LOG_INFO("write new_dfu_setting success");
//nrf_dfu_flash_erase(0x78000, 1, NULL);

}
else if (settings_backup_valid)
{
NRF_LOG_DEBUG("Copying forbidden parts from backup page.");
settings_forbidden_parts_copy_from_backup((uint8_t *)&s_dfu_settings);
}
}
else if (settings_backup_valid)
{
NRF_LOG_INFO("Restoring settings from backup since the settings page contents are "
"invalid (CRC error).");
memcpy(&s_dfu_settings,
mp_dfu_settings_backup_buffer,
sizeof(nrf_dfu_settings_t));
}
else
{
NRF_LOG_WARNING("Resetting bootloader settings since neither the settings page nor the "
"backup are valid (CRC error).");
memset(&s_dfu_settings, 0x00, sizeof(nrf_dfu_settings_t));
s_dfu_settings.settings_version = NRF_DFU_SETTINGS_VERSION;
}

if (NRF_DFU_SETTINGS_COMPATIBILITY_MODE && !NRF_DFU_IN_APP && (s_dfu_settings.settings_version == 1))
{
NRF_LOG_INFO("Old settings page detected. Upgrading info.");

// Old version. Translate.
memcpy(&s_dfu_settings.peer_data, (uint8_t *)&s_dfu_settings + DFU_SETTINGS_BOND_DATA_OFFSET_V1, NRF_DFU_PEER_DATA_LEN);
memcpy(&s_dfu_settings.adv_name, (uint8_t *)&s_dfu_settings + DFU_SETTINGS_ADV_NAME_OFFSET_V1, NRF_DFU_ADV_NAME_LEN);

// Initialize with defaults.
s_dfu_settings.boot_validation_softdevice.type = NO_VALIDATION;
s_dfu_settings.boot_validation_app.type = VALIDATE_CRC;
s_dfu_settings.boot_validation_bootloader.type = NO_VALIDATION;
memcpy(s_dfu_settings.boot_validation_app.bytes, &s_dfu_settings.bank_0.image_crc, sizeof(uint32_t));

s_dfu_settings.settings_version = NRF_DFU_SETTINGS_VERSION;
}

return;
}

devzone.nordicsemi.com/.../2474.log.txt