flash sharing of bootloader and app

I open up a flash shared space in app and bootloader, write values from app, bootloader read, bootloader read values such as 0xFFFFF, and not ideal values, may I ask why this is.

Based on the background of this problem, I want to customize the protocol OTA without any verification. I have correctly transferred the firmware data to bank1 through flash, and I want to modify s_dfu_setting myself to make the bootloader know that the firmware is valid and can be updated.

Parents
  • 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.

  • 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?

Reply
  • 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?

Children
  • 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.

    name said:
    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.

    The application is not permitted to change .bank_1.

    name said:
    But init_command looks like something like a command, how do I change it?

    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

    name 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?

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

Related