Attachments (2) Download All
Nordic Case Info
  • Case ID: 328842
Options

nrf_dfu_flash_store change to QSPI function -> callback issue in nrfx_qspi_write

Dominik Eugster

Hi

I'm chnaging the Secure Bootloader to an external falsh for bank1, connected with QSPI.

In the function on_data_obj_write_request is the call for nrf_dfu_flash_store (file nrf_dfu_req_handler.c

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
static void on_data_obj_write_request(nrf_dfu_request_t * p_req, nrf_dfu_response_t * p_res)
{
NRF_LOG_DEBUG("Handle NRF_DFU_OP_OBJECT_WRITE (data)");
if (!nrf_dfu_validation_init_cmd_present())
{
/* Can't accept data because DFU isn't initialized by init command. */
p_res->result = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
return;
}
uint32_t const data_object_offset = s_dfu_settings.progress.firmware_image_offset -
s_dfu_settings.progress.firmware_image_offset_last;
if ((p_req->write.len + data_object_offset) > s_dfu_settings.progress.data_object_size)
{
/* Can't accept data because too much data has been received. */
NRF_LOG_ERROR("Write request too long");
p_res->result = NRF_DFU_RES_CODE_INVALID_PARAMETER;
return;
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

There is a callback which is needed:

Fullscreen
1
2
ret_code_t ret =
nrf_dfu_flash_store(write_addr, p_req->write.p_data, p_req->write.len, p_req->callback.write);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

inside this function I use the QSPI function:

Fullscreen
1
hal_qspi_write(&p_src, len, (dest & EXTERNAL_FLASH_ADDRESS_LOWER_BYTES), (void*)callback))
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

which at the end is calling the nrfx function nrfx_qspi_write. 

Here I should have a callback, but I don't know what I should implement.

The original callback in the nrf_fstorage_write is implemented like this:
return (p_fs->p_api)->write(p_fs, dest, p_src, len, p_context);

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
ret_code_t nrf_fstorage_write(nrf_fstorage_t const * p_fs,
uint32_t dest,
void const * p_src,
uint32_t len,
void * p_context)
{
NRF_FSTORAGE_PARAM_CHECK(p_fs, NRF_ERROR_NULL);
NRF_FSTORAGE_PARAM_CHECK(p_src, NRF_ERROR_NULL);
NRF_FSTORAGE_PARAM_CHECK(p_fs->p_api, NRF_ERROR_INVALID_STATE);
NRF_FSTORAGE_PARAM_CHECK(len, NRF_ERROR_INVALID_LENGTH);
/* Length must be a multiple of the program unit. */
NRF_FSTORAGE_PARAM_CHECK(!(len % p_fs->p_flash_info->program_unit), NRF_ERROR_INVALID_LENGTH);
/* Source and destination addresses must be word-aligned. */
NRF_FSTORAGE_PARAM_CHECK(addr_is_aligned32(dest), NRF_ERROR_INVALID_ADDR);
NRF_FSTORAGE_PARAM_CHECK(addr_is_aligned32((uint32_t)p_src), NRF_ERROR_INVALID_ADDR);
NRF_FSTORAGE_PARAM_CHECK(addr_is_within_bounds(p_fs, dest, len), NRF_ERROR_INVALID_ADDR);
return (p_fs->p_api)->write(p_fs, dest, p_src, len, p_context);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Now the DFU is strating on bank1 but the App is generating an error because data is missing because of this callack I guess?

I was following this topic:

https://devzone.nordicsemi.com/f/nordic-q-a/48961/dfu-with-external-qspi-memory

Parents
  • 0

    I add the 2 files, bank 0 was DFU process with call to internal flash, this one was running ok like expected. (stopped the transfer in debugging mode after some packets)

    The other log of bank1 with call to external QSPI falsh has failed.

    Fullscreen Bank1 QSPI.txt Download
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2024-06-21
    No name (F9:3E:58:83:16:DF)
    V 13:15:26.644 Connecting to F9:3E:58:83:16:DF...
    D 13:15:26.644 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 13:15:26.973 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 13:15:26.973 Connected to F9:3E:58:83:16:DF
    V 13:15:26.977 Discovering services...
    D 13:15:26.977 gatt.discoverServices()
    D 13:15:26.990 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    I 13:15:27.319 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    D 13:15:27.632 [Callback] Services discovered with status: 0
    I 13:15:27.632 Services discovered
    V 13:15:27.648 Generic Access (0x1800)
    - Device Name [R W] (0x2A00)
    - Appearance [R] (0x2A01)
    - Peripheral Preferred Connection Parameters [R] (0x2A04)
    - Central Address Resolution [R] (0x2AA6)
    Generic Attribute (0x1801)
    - Service Changed [I] (0x2A05)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Fullscreen Bank_0 internal flash.txt Download
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2024-06-21
    DFU_09 16:DF (F9:3E:58:83:16:E0)
    V 12:59:17.720 Connecting to F9:3E:58:83:16:E0...
    D 12:59:17.720 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 12:59:17.785 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 12:59:17.785 Connected to F9:3E:58:83:16:E0
    V 12:59:17.798 Discovering services...
    D 12:59:17.798 gatt.discoverServices()
    D 12:59:17.813 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    I 12:59:18.196 Connection parameters updated (interval: 15.0ms, latency: 0, timeout: 6000ms)
    I 12:59:18.400 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    D 12:59:18.499 [Callback] Services discovered with status: 0
    I 12:59:18.499 Services discovered
    V 12:59:18.503 Generic Access (0x1800)
    - Device Name [R W] (0x2A00)
    - Appearance [R] (0x2A01)
    - Peripheral Preferred Connection Parameters [R] (0x2A04)
    - Central Address Resolution [R] (0x2AA6)
    Generic Attribute (0x1801)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Dominik Eugster

    I saw that the Offset of the packet 2 is still 4096 and therefore from packet 1, here is the error:

  • 0 in reply to Dominik Eugster

    Hi,

    I see. Yes, you are right. The image_copy function is where the image is copied to the final destination (during actication), so there sould be nothing special here (other than that you read from a different location).

  • 0 in reply to Einar Thorsrud

    ok, just for clarification:
    in the function static uint32_t image_copy(...

    I will check if the src_addr is in the external QSPI flash and read it to the buffer in the RAM:

    Fullscreen
    1
    __ALIGN(4) uint8_t m_buffer_rx[CODE_PAGE_SIZE];
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    which I use to call the function following function and use this buffer instead of src_addr, correct?

    Fullscreen
    1
    2
    3
    4
    ret_val = nrf_dfu_flash_store(dst_addr,
    (uint32_t *)src_addr,
    ALIGN_NUM(sizeof(uint32_t), bytes),
    NULL);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Dominik Eugster

    Yes, that sounds correct.

  • 0 in reply to Einar Thorsrud

    Hi Einar. The falsh store and read write from the external falsh has to be added in a lot of functiomns like hash and crc32 calc and image copy but at the end it's working now.

    I will add some features to trigger the FW update without downloading over the BLE DFU, becuase the goal was to reaceiv ethe APP over BLE Mesh (system bootloader) and use the same crypto features like the point to point DFU. But now it's working to flash the application from the external QSPI so the entry pont is where the image copy function is used.

  • 0 in reply to Dominik Eugster

    Hi
    the complete handling with the QSPI functions between is working now.

    If I receive ethe data for the init package directly to the QSPI and not over the APP. I have to read this data for the size and information for the encryption. This information is stored in the dat file. the bin file contains the application, the dat file the information for this.

    Which function is used to read this dat file? Then I can read this from the external flash with the same function.

    Thank you

Reply
  • 0 in reply to Dominik Eugster

    Hi
    the complete handling with the QSPI functions between is working now.

    If I receive ethe data for the init package directly to the QSPI and not over the APP. I have to read this data for the size and information for the encryption. This information is stored in the dat file. the bin file contains the application, the dat file the information for this.

    Which function is used to read this dat file? Then I can read this from the external flash with the same function.

    Thank you

Children
  • 0 in reply to Dominik Eugster

    Hello,

    Einar is out of office for a few weeks.

    Perhaps I misunderstand, but there is no function reading the dat file directly, but since the dat file contains the information from the init packet, the init packet is validated in nrf_dfu_validation_prevalidate() I think. This is found in nrf_dfu_validation.c, and is typically triggered by nrf_dfu_validation_init_cmd_execute().

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Hi Edvin

    Yes I was digging and found this function aswell. What I don't understand is where the data in m_packet is written, beacuse in may case the dat file is stored in the external flash and I have to point on this region and read the dat file from the external falsh. The question is where is this happing in BLE standart DFU? Then I can interchange this function.

    There is if (m_packet.has_signed_command) which I have to set before, but I can't find this code where will be set on or off.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    nrf_dfu_result_t nrf_dfu_validation_prevalidate(void)
    {
    nrf_dfu_result_t ret_val = NRF_DFU_RES_CODE_SUCCESS;
    dfu_command_t const * p_command = &m_packet.command;
    dfu_signature_type_t signature_type = DFU_SIGNATURE_TYPE_MIN;
    uint8_t const * p_signature = NULL;
    uint32_t signature_len = 0;
    if (m_packet.has_signed_command)
    {
    p_command = &m_packet.signed_command.command;
    signature_type = m_packet.signed_command.signature_type;
    p_signature = m_packet.signed_command.signature.bytes;
    signature_len = m_packet.signed_command.signature.size;
    }
    // Validate signature.
    if (signature_required(p_command->init.type))
    {
    ret_val = nrf_dfu_validation_signature_check(signature_type,
    p_signature,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Is this the function where I have to read from the external flash?

    pb_istream_from_buffer in the pb_decode.c

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    /** @brief Function for decoding byte stream into variable.
    *
    * @retval true If the stored init command was successfully decoded.
    * @retval false If there was no stored init command, or the decoding failed.
    */
    static bool stored_init_cmd_decode(void)
    {
    m_pb_stream = pb_istream_from_buffer(s_dfu_settings.init_command,
    s_dfu_settings.progress.command_size);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The data from the flash has to be stored here I guess, correct?

    m_pb_stream = pb_istream_from_buffer(s_dfu_settings.init_command, s_dfu_settings.progress.command_size);

    and then call the function nrf_dfu_validation_init with the call to stored_init_cmd_decode)

  • 0 in reply to Dominik Eugster

    Hello,

    The original secure bootloader (both uart and BLE) is a passive bootloader. This means that this event is triggered by the "DFU master", which is typically a mobile phone (BLE) or another MCU on the board (uart). 

    The callstack to this is quite long, but I managed to trace it back to on_write() in nrf_dfu_ble.c.

    Something like:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    on_write()
    nrf_dfu_req_handler_on_req()
    nrf_dfu_req_handler_req()
    nrf_dfu_req_handler_req_process()
    nrf_dfu_obj_op()
    nrf_dfu_command_req()
    on_cmd_obj_execute_request()
    nrf_dfu_validation_init_cmd_execute()
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    So this is triggered by the DFU master, where it sends the init packet, containing some metadata on the DFU image (size, CRC, and the signature). And then it sends the execute command for that init packet.

    However, if you already have this packet stored when you restart into DFU mode, you need to do some check to decide whether to check the stored data. If that check passes, it means that you can do this immediately after that. Normally we use the dfu_enter parameter in nrf_bootloader.c to decide whether to enter DFU mode or not. You can check some of the typical checks in dfu_enter_check(). The NRF_BL_DFU_ENTER_METHOD_GPREGRET method is great to use if you want to set it from the application. Then you write a value to the GPREGRET register before you reset the device using NVIC_SystemReset(). Then this register will be checked from the bootloader, and this will tell it to enter DFU mode, or in your case to check the init packet stored on the external flash chip.

    If you are in this state, and the init packet is checked and found valid, then you can proceed to what the nrf_dfu_validation_init_cmd_execute does with:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    nrf_dfu_result_t nrf_dfu_validation_init_cmd_execute(uint32_t * p_dst_data_addr,
    uint32_t * p_data_len)
    {
    nrf_dfu_result_t ret_val = NRF_DFU_RES_CODE_SUCCESS;
    if (s_dfu_settings.progress.command_offset != s_dfu_settings.progress.command_size)
    {
    // The object wasn't the right (requested) size.
    NRF_LOG_ERROR("Execute with faulty offset");
    ret_val = NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED;
    }
    else if (m_valid_init_cmd_present)
    {
    *p_dst_data_addr = nrf_dfu_bank1_start_addr();
    ret_val = update_data_size_get(mp_init, p_data_len);
    }
    else if (stored_init_cmd_decode())
    {
    // Will only get here if init command was received since last reset.
    // An init command should not be written to flash until after it's been checked here.
    ret_val = nrf_dfu_validation_prevalidate(); // ************* You jump in after this ************
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    (you jump in after line 21, so probably duplicate this function).

    Make sure that the rest of the API in this function works with your QSPI implementation.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Hi Edvin

    Thank you for the analysis.

    I will use Bit2 in GPREGRET to indicate that there is a firmware and init package in the external flash.

    in the functiuon nrf_bootloader_init with the function dfu_enter_check the return value will be true.

    In this case I will read the size and data from the external flash to s_dfu_settings.init_command and s_dfu_settings.progress.command_size and call the function stored_init_cmd_decode.

    Then the init package will be decoded and signed as valid.

    After I will call  nrf_dfu_validation_prevalidate.

    The function stored_init_cmd_decode I will call in the dfu_enter_check.

    Now:

    I will jump to nrf_dfu_validation_init_cmd_execute line 21.

    Like I understand call this in a seperate function? (without the if)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    else if (stored_init_cmd_decode())
    {
    // Will only get here if init command was received since last reset.
    // An init command should not be written to flash until after it's been checked here.
    ret_val = nrf_dfu_validation_prevalidate();
    *p_dst_data_addr = 0;
    *p_data_len = 0;
    // Get size of binary.
    if (ret_val == NRF_DFU_RES_CODE_SUCCESS)
    {
    ret_val = update_data_size_get(mp_init, p_data_len);
    }
    // Get address where to flash the binary.
    if (ret_val == NRF_DFU_RES_CODE_SUCCESS)
    {
    ret_val = update_data_addr_get(mp_init, *p_data_len, p_dst_data_addr);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    This I can implement in the dfu_enter_check aswell? Or where should the code follow later?

    ***************************************************

    dfu_enter will be true and nrf_dfu_req_handler_init will be called.

    Where is the call to update the image from bank1 (my external flash)? Should I call something additional or set some bank1 = valid or something?

    Edvin said:
    Make sure that the rest of the API in this function works with your QSPI implementation.

    This is working, QSPI flash (bank1) is working with bootloader or application sent with the BLE App from Nordic.

    Thank you so much

  • 0 in reply to Dominik Eugster
    Dominik Eugster said:
    Like I understand call this in a seperate function? (without the if)

    That was my idea, at least. Because you don't have an external device telling you what to do, this would be the first step if the bootloader has decided to enter DFU mode. 

    After validating the init packet, the next step is to start swapping out the actual application with the new image. We now assume that the application is legit, so the bootloader should then delete the old application from flash, and start receiving the new application. Since you don't have anyone pushing the new application to the bootloader, you need to make the bootloader read it from the external flash, and place it in it's internal flash. After the entire new application is in flash, in bank 0, I believe you can just reset the device, and the bootloader will discover that there is a new application present, and it will validate this one. 

    So in all, the steps you are bypassing is the "wait and receive init packet" followed by "validate the init packet command", in addition to "wait and receive full application" and "application transfer complete -> reset" command. 

    The bootloader has the possibility to use dual bank. In which case, it can receive the new application before deleting the old one. However, if the new application is larger than half of the old application, it will delete the bank0, and store it directly there. However, when the bootloader uses BLE to receive the image, it doesn't risk bricking the device if the transfer fails, or if the image following the valid init packet is actually invalid. So it may be a good idea to try to validate the actual image while it is still stored in the external flash before erasing the old application (because I assume that it is the application that put it in the QSPI in the first place). 

    I am not 100% sure how this is done by default, but you can look for a place that validates the image in bank 1, and try to use this on the image in the QSPI flash.

    Best regards,

    Edvin

Terms of service