nrf52832 OTA over ESB based on SDK17.1.0

[Lurn_Z]

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.

[Lurn_Z]

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.

[Edvin]

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

[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

[Lurn_Z]

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

[Edvin]

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

[Lurn_Z]

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

[Lurn_Z]

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

[Edvin]

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

[Lurn_Z]

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

Fullscreen dfu3.txt Download

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

Fullscreen dfu.txt Download

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

[Lurn_Z]

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.

Fullscreen 0420_DFU_test_1448.log Download

# 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:

Fullscreen 0420_DFU_test_1456.log Download

# 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

[Edvin]

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

[Lurn_Z]

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