Downloading a hex file image and writing it to Flash Bank 1

[MrFoley]

My device is an nRF52840 running a C Code application that is built on nRF5_SDK_17.1.0
I am implementing a FOTA solution where a hex file fw image and a .dat file will be dowloaded from the cloud, the fw image being written
to Bank1 and the .dat file containing the necessary DFU info written to it's appropriate space.
This functionality has been confirmed to work via the use of the various available Nordic command line tools (ie. nrfjprog) to write flash.

The question now is how to download the FW hex file and write it to Flash Bank 1?
This data is coming in HTTP chunks through a Telit modem via AT#HTTPQRY and AT#HTTPRCV=0 commands to the modem.

This will require me to parse the Intel Hex records and convert the Ascii data to binary records that I can then write to Flash.

I feel like I'm once again reinventing the wheel here...

Do I really have to write a hex record parser?

Am I overlooking some much easier way to accomplish this?
It seems like there should be some code out there that already does this (Hex file parsing, etc).

Suggestions?

[EAn]

Hi MrFoley . It is possible to reroute the packets to the bootloader using nrf_mesh_dfu_rx (in mesh case, I guess you could search from there and find a suitable function that performs the same operation of forwarding DFU packets to the bootloader. . You need to generate the DFU binary in bin format instead of hex format, and send the properly formatted DFU packets to the bootloader, bin chunk by bin chunk...

Check if in your sdk there's a function connecting to
/** Bootloader command callback function pointer type. */
typedef uint32_t (*bl_if_cmd_handler_t)(const bl_cmd_t* p_bl_cmd);

which would be analogous to nrf_mesh_dfu_rx.

To generate the BIN and DAT file use nrfutil dfu genpkg .

I hope that points you somewherehelpful!

Regards!

//EA

[MrFoley]

As I mentioned I do have a working 'prototype'. If I write the DAT file to it's expected location, the hex file to Bank1 and then issue a reset to the device, the bootloader will successfully boot the image in Bank 1. This is of course tested using command line utilities.

Downloading a binary via the modem I think requires me to escape out of command mode else incoming data is expected to be ascii, so there's that.

Assuming I can get binary data down, you're saying that I can build DFU packets from this binary stream and send them to the bootloader, who will write them to the Bank1 address I provide, and then when I reset the device the bootloader will load and run the image if all's well?

Any examples of this out there?

[EAn]

That's exactly what I am saying :) .

We use an ethernet connection to download DFU binaries from our backend to our nrf5 devices all the time, and get firmware updates like that. Basically you can circumvent the software that runs on your computer and use any transport layer you please to convey the binary to your nrf5, it can be UART, any radio protocol, binary smoke signals (lol :P ) anything you please and then send the bitstream to the bootloader as it is done in any DFU(OTA). Just make sure you format the DFU packets according to what the bootloader is expecting, with the correct preamble, seqnum, whatever it need.

Look for the DFU example in nRF5_SDK_17 and check how the internal machinery of it works. I did the same for the mesh DFUOTA so I can run DFUs without using the open-mesh protocol that was used in Nordic's example. Once you break free from that you can use whatever means to convey the binary to the target systems...  I hope that helps :)

[MrFoley]

Well it's encouraging to hear that someone is successfully doing something similar. The two files, the fw image binary and the .dat file - Do you handle these separately, or is it just one DFU binary that you download that has all of the information?

[EAn]

In my implementation - following from the DFU OTA used in Mesh SDK  - you need the DAT to tell you the exact number of bytes of the FW image, and to tell you the APP ID and FW version, which is used to compute the need for that update... etc... There are other useful metadata that can be coded there also.
I haven't looked into the normal SDK DFUOTA engine for a long time, but my guess is that there is similar information coded in the DAT file, which is used by the bootloader . Usually the DFU Start Packet and DFU Ready packets are sending info coded in the DFU DAT file, check it out ;)