Firmware update using TFTP


#1

Hi,

I am attempting to do firmware update using a WIZ550io shield on a Nordic Semiconductor nRF52 Development Kit. To do this, I try to follow the example here: https://github.com/Wiznet/WIZBLE510_ETHERNET/tree/master/nRF5_SDK_12.2.0_WIZBLE510_TFTP_DFU_Release1

I am able to connect to the TFTP server and download a file to the development kit. The issue is that the example does not state how the firmware file should be generated and uploaded to be compatible with Wiznet’s implementation of DFU. I have tried with the files provided with Nordic’s SDK that Wiznet’s example is built upon, but I get an error saying that the downloaded application is not valid after it is downloaded.

The README file in the example I link to, only shows a picture of a “firmware.bin” file, but does not provide information about how to make this file, what it should contain and how its settings should be.

Does anyone here know how this should be done?


#2

Hi, I’m Mason for WIZnet.

What do you use a complier?
If your compiler does not output the .bin file, you have to convert .hex to a .bin file.
I recommend Segger’s JFlash

Execute JFlash. And open your .hex file. And click “File -> the save data file as”.
You can change the file format to bin.

Thank you.


#3

Thanks for your answer, Mason, that’s much appreciated.

I compile with Keil, and after your advice, I have now used J-Flash to convert the output hex-file to .bin.
I am able to transfer the .bin file to the Development Kit, but i get the following log after the transfer is complete:
0> :INFO:In nrf_bootloader_init
0> :INFO:In real nrf_dfu_init
0> :INFO:running nrf_dfu_settings_init
0> :INFO:Enter nrf_dfu_continue
0> :INFO:Single: Invalid bank
0> :INFO:Enter nrf_dfu_app_is_valid
0> :INFO:Return false in valid app check
0> :INFO:After real nrf_dfu_init
0> :INFO:After nrf_bootloader_init
0> :INFO:Running nrf_bootloader_app_start with address: 0x0001f000
0> :INFO:Disabling interrupts
0> :INFO:Setting SD vector table base: 0x0001f000

And then the application never starts, and it looks like the application is not valid for some reason: “INFO:Return false in valid app check”

The applications I have tried, are from SDK 12.2.
One of them is found in the DFU examples: examples\dfu\ble_dfu_send_hex\test_images_update_nrf52

The other is the Blinky example: examples\ble_peripheral\experimental_ble_app_blinky

None of them works when i convert them to .bin and transfer them via TFTP.
It would be great if an example .bin file that works could be provided here or in the GitHub example so it would be possible to confirm that the setup is correct.


#4

Hi,

I attached “firmware.bin”.
The firmware.bin file is SDK 12.2 ble_app_hrs project.
Please test the bin file.

firmware.bin (31.1 KB)

If an error occurs, Please follow the steps below.

  1. Write the SoftDevice V3.1.0
  2. Build and Write TFTP Bootloader
  3. Copy & Paste the firmware.bin in the tftp server

Thank you.


#5

Thanks for your help, Mason, it works now.
The error I did, was using SoftDevice v3.0.0 that was provided with SDK 12.2. Switching to SoftDevice v3.1.0 solved the problem.

Thank you.


#6

I have one extra question: Is there a similar example for nRF52840 or any plans about making one?


#7

I am glad that you have successfully tested it.
There is no additional plan yet. But if you tell me other example you want, We will review it.


#8

It would be really great with a similar example to the one you have already created, but for nRF52840 using SDK 14.2.

I have been able to establish connection from a nRF52840 and WIZ5500io moduoe to the TFTP server and seemingly download the file, but application is not running. When reading the memory address where the application should be placed it only contains the letters “meout 5” followed by zeros, which suggests the connection timeouts and not actually downloads anything. An example for how to do this properly would be much appreciated.

Update: Using Wireshark I’m able to see that all data is transferred and ACK’ed as it should. The problem must be on the firmware side when copying the data to the application region.