How to upgrade my nrf52810 over I2C (or UART) by using a nrf52832 as a bridge

[Aurele]

Hello,

In our product we have the following hardware configuration that implies two MCUs :

- a nrF52832 with BLE capability and running as an I2C master

- a nrf52810 runing as an I2C slave (without any BLE connection possibility)

I can upgrade the nrf52832 without any issue by using DFU and nRF Toolbox app but my question was about upgrading the nRF52810. In that case, the nRF52832 will acte as a bridge and it will transfer data over I2C (or UART if i reconfigure the pin, i didn't decide yet) to the nRF52810 DFU.

I know i will need to rewrite my own DFU for the nRF52810 but what i'm missing is the entry point. For the nRF52832, i can use nRF-Toolbox from my phone but which tool can i use for the nRF52810 ?

The BLE from my nRF52832 is the only interface to upgrade both CPU.

Is there someone that has already accomplished this ?

Best regards,

Aurélien

[Aurele]

Finally, i just needed to add the fc option (-fc 0) to disable the flow control on laptop side and the upgrade is working now with an external serial port ! ;)

Now, i come back on the nrf52832 side in order to finalysed the upgrade !

[Einar Thorsrud]

Sounds good! Thank you for sharing the good news

[Aurele]

Hi Einar

I succeeded to start the transfer from my BLE device through the nrf52832 until the nrf52810 but i'm stuck with the first write function.

Here is my logs : 

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<info> app: No firmware to activate.
<info> app: Boot validation failed. No valid app to boot.
<info> nrf_bootloader_wdt: WDT is not enabled
<info> app: Entering DFU mode.
<info> nrf_dfu_req_handler: ==> nrf_dfu_req_handler_req_process
<info> nrf_dfu_req_handler: NRF_DFU_OBJ_TYPE_COMMAND
<info> nrf_dfu_req_handler: NRF_DFU_OP_OBJECT_SELECT
<info> app: TX_DONE
<info> app: RX_DONE 60
<info> app: RX_DONE 06
<info> app: RX_DONE 01
<info> app: RX_DONE 00
<info> app: RX_DONE 02
<info> app: RX_DONE 00
<info> app: RX_DONE 00
<info> app: RX_DONE 8D
<info> app: RX_DONE 00
<info> app: RX_DONE 00
<info> app: RX_DONE 00
<info> app: RX_DONE 82
<info> app: RX_DONE 9A
<info> app: RX_DONE 88
<info> app: RX_DONE 18
<info> app: RX_DONE C0
<info> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_req_handler: ==> nrf_dfu_req_handler_req_process
<info> app: TX_DONE
<info> app: RX_DONE 60
<info> app: RX_DONE 02
<info> app: RX_DONE 01
<info> app: RX_DONE C0
<info> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_req_handler: ==> nrf_dfu_req_handler_req_process
<info> nrf_dfu_req_handler: NRF_DFU_OBJ_TYPE_COMMAND
<info> nrf_dfu_req_handler: NRF_DFU_OP_OBJECT_CREATE 8D
<info> app: TX_DONE
<info> app: RX_DONE 60
<info> app: RX_DONE 01
<info> app: RX_DONE 01
<info> app: RX_DONE C0
<info> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_req_handler: ==> nrf_dfu_req_handler_req_process
<info> nrf_dfu_req_handler: NRF_DFU_OBJ_TYPE_COMMAND
<info> nrf_dfu_req_handler: NRF_DFU_OP_OBJECT_WRITE 141
<info> app: Data : 79 536936188 62
<info> app: TX_DONE
<info> app: Data : 17 536936188 62
<info> app: TX_DONE
<info> app: Data : 0 536936188 62
<info> app: TX_DONE
<info> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_req_handler: ==> nrf_dfu_req_handler_req_process
<info> nrf_dfu_req_handler: NRF_DFU_OBJ_TYPE_COMMAND
<info> nrf_dfu_req_handler: NRF_DFU_OP_CRC_GET
<info> app: TX_DONE
<info> app: RX_DONE 60
<info> app: RX_DONE 03
<info> app: RX_DONE 01
<info> app: RX_DONE 8D
<info> app: RX_DONE 00
<info> app: RX_DONE 00
<info> app: RX_DONE 00
<info> app: RX_DONE 82
<info> app: RX_DONE 9A
<info> app: RX_DONE 88
<info> app: RX_DONE 18
<info> app: RX_DONE C0
<info> nrf_dfu_req_handler: Request handling complete. Result: 0x1

Indeed, there is a get from the phone that is transfered to nrf52810. In the response, the offset seems to be OK but the phone stops the transfer and says : DFU INVALID RESPONSE !

The error code : 0x01 indicates a success

The offset : 0x8D is exactly the size of the write.

Here is the hook function in nrf_dfu_req_handler : 

        case NRF_DFU_OP_OBJECT_CREATE:
        {
            NRF_LOG_INFO("NRF_DFU_OP_OBJECT_CREATE %x",p_req->create.object_size);
#ifndef MAIN_DFU
            on_cmd_obj_create_request(p_req, p_res);
#else
            uart_send_object_create_packet(p_req->create.object_type,p_req->create.object_size,(uint8_t*)p_res);
#endif
        } break;

        case NRF_DFU_OP_CRC_GET:
        {
            NRF_LOG_INFO("NRF_DFU_OP_CRC_GET");
#ifndef MAIN_DFU
            on_cmd_obj_crc_request(p_req, p_res);
#else
            uart_send_crc_get_packet((uint8_t*)p_res);
#endif
        } break;

        case NRF_DFU_OP_OBJECT_WRITE:
        {
            NRF_LOG_INFO("NRF_DFU_OP_OBJECT_WRITE %d",p_req->write.len);
#ifndef MAIN_DFU
            on_cmd_obj_write_request(p_req, p_res);
#else
            uart_send_object_write_packet((uint8_t*)p_req->write.p_data,p_req->write.len,(uint8_t*)p_res);
#endif
        } break;

Do you have an idea of the issue ?
Regards,

[Einar Thorsrud]

Hi,

I do not see any indication of what actually went wrong. Can you upload a detailed log from the DFU master (Phone or nRFConnect for desktop)?

[Aurele]

Hi

Here is what i get from nrfconnect on my desktop : 

It seems that the CRC is wrong.

Why do i receive 141 bytes as size for the write ? It is not word align ? Moreover i was thinking about slip encode/decode but i don't it is slip