nrf52832 OTA over ESB based on SDK17.1.0

Hi everyone:    I developed an application based on ESB wireless communication protocol ofr the nRF52832, and I would like to perform an OTA DFU with it.    Do you know any example of some over the air FW upgrade of nRF52832 chip via ESB protocol.

    SDK is 17.1.0.

Best regards,

Lurn.

Parents
  • I only found examples of ble and uart in the dfu/secure_bootloader folder, Which one should I use or how should I modify it to adapt my program.

  • Hello,

    It is correct that you will only find BLE and UART in our samples, but I know that several customers have ported this to SPI, so if you need it over ESB, then that should also be possible. The transport layers in the bootloader for the nRF5 SDK are on purpose quite separated from the rest of the libraries, to make it easier to change the transport layer, or to add your own transport layer.

    But you do need to implement it yourself. Also note that we do not have the "DFU Master" as an official part of our SDK. We have tools like nrfutil (open source) or nRF Connect for Desktop (not open source), and applications for mobile phones that are open source (but mobile phones doesn't have ESB). However, there is an unofficial implementation (not properly tested. You can use it, but on your own "risk"), which you can find here. I have not tested these myself, but you can give it a go. I suggest you test out the UART master, in combination with the uart bootloader, and then you can port both to ESB once you are up and running.

    Best regards,

    Edvin

  • No worries, Lurn,

    What you are writing makes sense to me! So we are back at having a UART bootloader without the possibility to use nrfutil, if I understand correctly.

    However, you could still use nrfutil to generate the DFU images on a computer, and then somehow transfer that to the computer that will transfer the image to the nrf-device, right?

    In that case, you would only need the ARM device to run the part of nrfutil that does the transfer, which is only a small part of nrfutil.

    While we do not have a strip down version of nrfutil, the colleague that wrote the getting started with DFU guide also wrote a sample application that can run on another nRF device, and will update the target nRF device over UART. Click that link, and search for "DFU Master Code". 

    I believe it may be easier to analyze and reverse engineer the process from that sample than it is to interpret the nrfutil source code.

    Unfortunately, we don't have very much good documentation on nrfutil, but a couple of useful links are:

    A general description of the DFU procedure can be found here.

    The UART Serial protocol is described here.

    Just in case, the link to nrfutil source code. But I find it difficult to navigate to understand the protocol.

    Lastly, one additional hint could be to hook on a UART to computer sniffer/analyzer, and observe an update, to see if you can make sense of the packets, as described in the links above.

    Best of luck!

    Best regards,

    Edvin

  • Hi Edvin,

    I read the code about "DFU Master", I think in this code it use another nrf-device, and what I should do is make sure my nrf-device is in DFU mode, and just run the "DFU Mast code", am I understand currently?

    And a question about it, what is the format of image .hex/.bin or .zip?

    If it run a part of nrfutil that does the transfer, I think it should be a .zip which made by nrfutil, Am i right?

    Best regards,

    Lurn

  • The DFU master does what the computer running nrfutil does when transferring the image. 

    Lurn_Z said:

    what I should do is make sure my nrf-device is in DFU mode, and just run the "DFU Mast code", am I understand currently?

    Yes.

    I have not tested this, but I believe there is some description saying how to do the test. Check out the DFU_SPI_readme.docx (yes, it is written for the SPI variant, but it covers your questions).

    It explains how to transfer the DFU image (.zip file) to the flash of the DFU master by using JFlash. I played around with .bin files the other day. The thing with these is that they are not address mapped, like hex files are. But there is a tool that you can test (pip install bin2hex.py), and you can use this to convert .bin files to .hex files with an offset, so that you can program them using nrfjprog (for testing purposes).

    bin2hex.py --offset 0x12000000 bin_file.bin hex_file.hex
    nrfjprog --program hex_file.hex

    Lurn_Z said:
    And a question about it, what is the format of image .hex/.bin or .zip?

    Read the doc for the SPI sample, and you will see, but in short, it is the .bin and .dat inside the .zip that actually contains the data that is needed.

    BR,
    Edvin

  • I didn't find the file "nrf_serial_dfu.h"

    and also I did not have the pack.

    the download log is here.

    Cannot download file developer.nordicsemi.com/.../NordicSemiconductor.nRF_DeviceFamilyPack.8.15.0.pack: Object not found

  • Hi Edvin,

    I want to port this code to an example for my SDK such as \examples\peripheral\blinky

    but it have too much Compile Error, although I included the header file still got many undefined errors.

    can you give me a code base SDK 17.1.0 ? I want to test it.

    Best regards,

    Lurn

Reply Children
  • Regarding the 8.15.9 DeviceFamilyPack, click the "Select Software Packs button in the toolbar in Keil, and select "latest" instead of "fixed":

    Then, you need to click "OK" -> "OK" (in the next popup), then right click "device" in the project menu to the left, select "options for..." then select "8.44.1" in the "Version" option (or whatever version the "latest" in the previous step selected). 

    As long as you placed the sample in SDK14.2.0\examples\peripheral, so that it has a similar folder structure as the other examples, it should compile. 

    Lurn_Z said:
    can you give me a code base SDK 17.1.0 ? I want to test it.

    Sorry, I don't have time to port this to 17.1.0 now. Seeing as you probably won't be running this on an nRF in the end either way, and this is only to see a possible implementation, I don't think you need to port it either. 

    What you probably want to start looking into is how the uart_send_init_packet() sends the init packet, and how uart_send_application_image() is used to send the application image (which is split over several packets). 

    Best regards,

    Edvin

  • Hi Edvin,

    Yes, I won't run it on nRF, but I think the quickest way to test whether there is a problem with this process is to use this example

    About the DFU master, I can transfer the packet successfully(i think), but my pending update device log shows no data received.

    The process is as follows

    I set the device in DFU mode, connect the DFU master with UART, then just run the DFU master.

    In order to confirm that there is no abnormality in my DFU mode, I use the nrfutil to update it, and it was worked.

    the dfu master log like this

    10> RX Id:2 len:100
    10> UART initialized
    10> TX req id:2 length: 3.
    10> Tx data[0]: = 9
    10> Tx data[1]: = 1
    10> Tx data[2]: = 192
    10> uart_send_ping_packet
    10> while  start_DFU
    10> TX done len:3
    10> Init data size: 1
    10> Data : FF FF 62
    10> TX req id:2 length: 7.
    10> Tx data[0]: = 1
    10> Tx data[1]: = 1
    10> Tx data[2]: = 1
    10> Tx data[3]: = 0
    10> Tx data[4]: = 0
    10> Tx data[5]: = 0
    10> Tx data[6]: = 192
    10> TX done len:7
    10> Data : 0 536881536 62
    10> TX req id:2 length: 3.
    10> Tx data[0]: = 8
    10> Tx data[1]: = 255
    10> Tx data[2]: = 192
    10> TX done len:3
    10> TX req id:2 length: 2.
    10> Tx data[0]: = 3
    10> Tx data[1]: = 192
    10> TX done len:2
    10> TX req id:2 length: 2.
    10> Tx data[0]: = 4
    10> Tx data[1]: = 192
    10> TX done len:2
    10> Image size: 1
    10> TX req id:2 length: 7.
    10> Tx data[0]: = 1
    10> Tx data[1]: = 2
    10> Tx data[2]: = 1
    10> Tx data[3]: = 0
    10> Tx data[4]: = 0
    10> Tx data[5]: = 0
    10> Tx data[6]: = 192
    10> TX done len:7
    10> Data : 0 536881536 62
    10> TX req id:2 length: 3.
    10> Tx data[0]: = 8
    10> Tx data[1]: = 255
    10> Tx data[2]: = 192
    10> TX done len:3
    10> TX req id:2 length: 2.
    10> Tx data[0]: = 3
    10> Tx data[1]: = 192
    10> TX done len:2
    10> TX req id:2 length: 2.
    10> Tx data[0]: = 4
    10> Tx data[1]: = 192
    10> TX done len:2

    and my device in DFU mode log is here

    10> <info> app: Inside main
    10> 
    10> <info> app: Bootloader -1
    10> Settings -1 
    10>  Application -1
    10> 
    10> <debug> app: In nrf_bootloader_init
    10> 
    10> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    10> 
    10> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    10> 
    10> <warning> nrf_dfu_settings: Resetting bootloader settings since neither the settings page nor the backup are valid (CRC error).
    10> 
    10> <debug> nrf_dfu_settings: Writing settings...
    10> 
    10> <debug> nrf_dfu_settings: Erasing old settings at: 0x0007F000
    10> 
    10> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007F000, len=1 pages), queue usage: 0
    10> 
    10> <debug> nrf_dfu_flash: Flash erase success: addr=0x0007F000, pending 0
    10> 
    10> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007F000, src=0x2000073C, len=896 bytes), queue usage: 1
    10> 
    10> <debug> nrf_dfu_flash: Flash write success: addr=0x0007F000, pending 0
    10> 
    10> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    10> 
    10> <debug> nrf_dfu_settings: Writing settings...
    10> 
    10> <debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000
    10> 
    10> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 1
    10> 
    10> <debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 0
    10> 
    10> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x20000ABC, len=896 bytes), queue usage: 1
    10> 
    10> <debug> nrf_dfu_flash: Flash write success: addr=0x0007E000, pending 0
    10> 
    10> <debug> app: Enter nrf_bootloader_fw_activate
    10> 
    10> <info> app: No firmware to activate.
    10> 
    10> <info> app: Boot validation failed. No valid app to boot.
    10> 
    10> <debug> app: DFU mode because app is not valid.
    10> 
    10> <info> nrf_bootloader_wdt: WDT is not enabled
    10> 
    10> <debug> app: in weak nrf_dfu_init_user
    10> 
    10> <debug> app: timer_stop (0x20000020)
    10> 
    10> <debug> app: timer_activate (0x20000020)
    10> 
    10> <info> app: Entering DFU mode.
    10> 
    10> <debug> app: Initializing transports (found: 1)
    10> 
    10> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
    10> 
    10> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
    10> 
    10> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    10> 
    10> <debug> app: Enter main loop
    10> 

    Can you tell me what is wrong?

    Update:

    I checked the log when updating with nrfutil, at first I get a PING event and the data is 0x9, 0x1 with a SLIP_BYTE_END  0300

    10> <info> nrf_dfu_serial_uart: len = 1, ret_code = 17, p_data[0] = 9
    10> 
    10> <info> nrf_dfu_serial_uart: len = 1, ret_code = 17, p_data[0] = 1
    10> 
    10> <info> nrf_dfu_serial_uart: len = 1, ret_code = 0, p_data[0] = C0
    10> 
    10> <debug> nrf_dfu_serial: Received ping 1
    10> 
    10> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    10> 
    10> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_PING
    10> 
    10> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    10> 
    10> <debug> nrf_dfu_serial: Sending Response: [0x9, 0x1]

    in the DFU master, it also send the ping command log, you can see it in the dfu mater log, but my device didn't get it.

    In order to confirm that the DFU mater send it ok, I connect it to my pc with UART, and I can get the data.

    So I think maybe my device which is in DFU mode didn't receive the packet, but why?

    Update 2:

    I found that the GND of both of them is not connected, when I connect them, I can receive data.

    Best regards,

    Lurn

  • Update:

    I can transfer files but never succeed.

    The process is as follows.

    1. I flash the DFU master application on the master board.

    2. make sure my target board in DFU mode.

    3. program the init.bin and app.bin to master board.

    4. connect master board and target board.

    5. run the DFU master.

    In source code the application_image_address = 0x30000;

    and I get error like this

    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
    00> <debug> nrf_dfu_req_handler: Whole firmware image received. Postvalidating.
    00> <error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x200046F0

    the full log file is here.

    # SEGGER J-Link RTT Viewer V7.00a Terminal Log File
    # Compiled: 15:35:52 on Apr 16 2021
    # Logging started @ 20 Apr 2023 14:48:20
    (Connection lost)
    (Connection lost)(Connection lost)(Connection lost)(Connection lost)(Connection lost)
    (Connection lost)(Connection lost)(Connection lost)(Connection lost)(Connection lost)(Connection lost)(Connection lost)(Connect
    00> <info> app: Inside main
    00> 
    00> <info> app: Bootloader 0
    00> Settings 2 
    00>  Application 0
    00> 
    00> <debug> app: In nrf_bootloader_init
    00> 
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> 
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> 
    00> <debug> nrf_dfu_settings: Using settings page.
    00> 
    00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <debug> app: Enter nrf_bootloader_fw_activate
    00> 
    00> <info> app: No firmware to activate.
    00> 
    00> <info> app: Boot validation failed. No valid app to boot.
    00> 
    00> <debug> app: DFU mode because app is not valid.
    00> 
    00> <info> nrf_bootloader_wdt: WDT is not enabled
    00> 
    00> <debug> app: in weak nrf_dfu_init_user
    00> 
    00> <debug> app: timer_stop (0x20000020)
    00> 
    00> <debug> app: timer_activate (0x20000020)
    00> 
    00> <info> app: Entering DFU mode.
    00> 
    00> <debug> app: Initializing transports (found: 1)
    00> 
    00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
    00> 
    00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
    00> 
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> 
    00> <debug> app: Enter main loop
    00> 
    00> <debug> nrf_dfu_serial: Received ping 1
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_PING
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x9, 0x1]
    00> 
    00> <debug> app: Shutting down transports (found: 1)
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (command)
    00> 
    00> <debug> app: timer_stop (0x20000020)
    00> 
    00> <debug> app: timer_activate (0x20000020)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x1]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 200005D8
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 200005D8
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 200005D8
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (command)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 200005D8
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
    00> 
    00> <error> nrf_dfu_validation: Execute with faulty offset
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x8
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x4, 0x8]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 200005D8
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
    00> 
    00> <error> nrf_dfu_req_handler: Cannot create data object without valid init command
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x8
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x8]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x8
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (data)
    00> 
    00> <debug> nrf_dfu_req_handler: Offset:0, CRC:0x00000000
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
    00> 
    00> <debug> nrf_dfu_req_handler: Whole firmware image received. Postvalidating.
    00> 
    00> <error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x200046F0
    00> 
    
    # Logging stopped @ 20 Apr 2023 14:50:07
    

    In readme it shows the address.

    so I change the application_image_address = 0x10000;

    the error log is here

    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
    00> <error> nrf_dfu_req_handler: Cannot create data object without valid init command
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x8
    00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x8]
    00> <error> app: Received an error: 0x00000004!

    and log file:

    # SEGGER J-Link RTT Viewer V7.00a Terminal Log File
    # Compiled: 15:35:52 on Apr 16 2021
    # Logging started @ 20 Apr 2023 14:56:49
    00> <debug> nrf_dfu_serial: Received ping 1
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_PING
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x9, 0x1]
    00> 
    00> <debug> app: Shutting down transports (found: 1)
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (command)
    00> 
    00> <debug> app: timer_stop (0x20000020)
    00> 
    00> <debug> app: timer_activate (0x20000020)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x4
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x4
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x4]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 200005D8
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
    00> 
    00> <error> nrf_dfu_validation: Init command larger than expected.
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x3
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x3
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
    00> 
    00> <error> nrf_dfu_validation: Init command larger than expected.
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x3
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x3
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (command)
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
    00> 
    00> <error> nrf_dfu_validation: Handler: Invalid init command.
    00> 
    00> <error> nrf_dfu_validation: Failed to decode init packet
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x5
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x5
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x4, 0x5]
    00> 
    00> <info> nrf_dfu_serial_uart: Allocated buffer 20000554
    00> 
    00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
    00> 
    00> <error> nrf_dfu_req_handler: Cannot create data object without valid init command
    00> 
    00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
    00> 
    00> <warning> nrf_dfu_serial: DFU request completed with result: 0x8
    00> 
    00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x8]
    00> 
    00> <error> app: Received an error: 0x00000004!
    00> 
    
    # Logging stopped @ 20 Apr 2023 14:57:33
    

    Another question:

    In readme it said that

    3) Open the .zip file and unzip the init .dat file and the binary image .bin of the application or the softdevice/bootloader.

    it should be unzip the .zip file instead of unzip the init.data?

    Hope you can give some solutions.

    Best regards,

    Lurn

  • Ok, so I ran the DFU Master sample (for the first time, actually). 

    It is correct, as you said that at least the UART sample expects the application binary to be present at address 0x30000 on the device running the DFU Master application. The init packet is expected at address 0x9000.

    Important:

    I found one bug that caused the bootloader to assert after the first application image packet was sent. The reason was that the bootloader was trying to write 62 bytes to flash. The reason for this was that in the DFU Master application, the MAX_ACTUAL_PAYLOAD is set to (MTU_SIZE/2-2), which gives 62. nrf_fstorage_write requires the length of the chunk that it is going to write to be a multiple of 4 bytes. So I changed MAX_ACTUAL_PAYLOAD to MTU_SIZE/2 instead of (MTU_SIZE/2-2), and after that it worked.

    So, what I did was that I unzipped the dfu image which was a zip file. Inside that file, there are 3 files. The json file we will not use. The smallest file, called new_app.dat is the init packet. I renamed it init_packet.bin. The other, which is the application file, I renamed app_image.bin. Just to keep track of what is what.

    Then I used this script (in a .bat file):

    del files\dfu_img\app_image.hex
    del files\dfu_img\init_packet.hex
    bin2hex.py --offset 0x9000 files\dfu_img\init_packet.bin files\dfu_img\init_packet.hex
    bin2hex.py --offset 0x30000 files\dfu_img\app_image.bin files\dfu_img\app_image.hex

    This generated the init packet and app image hex files, which I then programmed together with the dfu master (compiled in SDK14.2.0)

    nrfjprog -e --snr 682396787
    nrfjprog --program files\DFU_MASTER.hex --verify --snr 682396787
    nrfjprog --program files\dfu_img\init_packet.hex --verify --snr 682396787
    nrfjprog --program files\dfu_img\app_image.hex --verify --snr 682396787
    nrfjprog --reset --snr 682396787

    now, connecting the UART wires between the two DKs. Put the target DK in DFU mode, and pressed button 1 on the DFU Master. That performed the DFU transfer of the new image, and the application changed.

    Actually, I scripted everything, except unpacking the application image (which you could probably also script). Attached for reference:

    make -j9
    make -j9 -C ..\..\..\..\peripheral\blinky\pca10056\mbr\armgcc
    
    
    
    del files\app.hex
    del files\settings.hex
    del files\bl.hex
    copy ..\arm5_no_packs\_build\nrf52840_xxaa_mbr.hex files\bl.hex
    
    copy ..\..\..\..\peripheral\blinky\pca10056\mbr\armgcc\_build\nrf52840_xxaa.hex files\app.hex
    nrfutil settings generate --family NRF52840 --application files\app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 files\settings.hex
    
    nrfjprog -e --snr 683963588
    nrfjprog --program ..\..\..\..\..\components\softdevice\mbr\hex\mbr_nrf52_2.4.1_mbr.hex --verify  --snr 683963588
    nrfjprog --program files\bl.hex --verify  --snr 683963588
    nrfjprog --program files\app.hex --verify --snr 683963588
    nrfjprog --program files\settings.hex --verify --snr 683963588
    nrfjprog --reset --snr 683963588
    
    nrfutil pkg generate --application files\new_app.hex --application-version 2 --hw-version 52 --sd-req 0x00 --key-file ..\..\..\private.key files\dfu_img.zip
    
    timeout 10
    
    del files\DFU_MASTER.hex
    copy ..\..\..\..\..\..\14.2.0\examples\test\DFUMaster_UART\pca10040\blank\arm5_no_packs\_build\nrf52832_xxaa.hex files\DFU_MASTER.hex
    del files\dfu_img\app_image.hex
    del files\dfu_img\init_packet.hex
    bin2hex.py --offset 0x9000 files\dfu_img\init_packet.bin files\dfu_img\init_packet.hex
    bin2hex.py --offset 0x30000 files\dfu_img\app_image.bin files\dfu_img\app_image.hex
    
    nrfjprog -e --snr 682396787
    nrfjprog --program files\DFU_MASTER.hex --verify --snr 682396787
    nrfjprog --program files\dfu_img\init_packet.hex --verify --snr 682396787
    nrfjprog --program files\dfu_img\app_image.hex --verify --snr 682396787
    nrfjprog --reset --snr 682396787
    ::nrfutil dfu serial -pkg files\dfu_img.zip -p COM8

    Best regards,

    Edvin

  • Hi Edvin,

    At first, thanks for your help.

    So now you can run the DFU master correctly.

    Due to the time difference, I will try to modify the MAX_ACTUAL_PAYLOAD to MTU_SIZE/2 tomorrow.

    And I used the  j-flash to program the init.bin and app.bin, it can set the offset. and I think there won't be a problem with that. If something wrong, I will make a script to do this.

    Best regards,

    Lurn

Related