Embedding firmware for external MCU in firmware image

[nrbrook]

I have another MCU on the same board as the Nordic 52832. The firmware update image for the MCU is about 50kb in size, so instead of adding a parallel DFU for the MCU through Bluetooth I figured I could just embed the firmware in the Nordic firmware. What is the best way to store this data in the firmware image so it isn't loaded into RAM but can be read directly from flash as required? I'm guessing if I store it in an array it will be loaded into RAM.

[Hung Bui]

Hi Nick, 

Could you explain a little bit more on what you are planing to do ?

How do you send the firmware from the nRF52 chip to the 2nd MCU ? 

How do you receive this firmware to the NRF52  ?

You can merge 2 binary image in flash. I don't see the reason of using an array here. 

[nrbrook]

I want to store the firmware binary data inside the Nordic firmware so I can just use the Nordic DFU and don’t need to add a second DFU process. The data will then be sent to the MCU via serial. So I need to read the data from flash and send it over serial on the nRF.

[Hung Bui]

Okey, so your plan is to send one single image from the phone via BLE to the NRF52. And the NRF52 will update both itself and the 2nd MCU. 

I think it's possible. You just need to combine to binary images (binary .bin not the .hex file) into one binary. Then create a .zip DFU packet from that combined binary. Then you can update the .zip file. In your application, you can then read the 2nd image and send it via UART. 

You may need to convert the combined binary back to hex to create the .zip file. 

One draw back of this is that you need big enough swap bank area to receive 2 images at once. 

[nrbrook]

Yes correct.

How can binary images be combined? Can nrfutil or mergehex do this? Then how can I get the flash location of this data in code?

I thought DFU bootloader overwrites application flash directly?

[Hung Bui]

Hi Nick, 

I think it's easiest to use J-Link Commander to do the combination. There are functions called loadbin and savebin that you can load a binary file in a location that you choose and then you can load the combined binary out. 

I have used the tool in my example for DFU master, you can find here. Check the documentation. 

When you have the binary, you need to modify the .zip and the initpacket manually because nrfutil doesn't support .bin as input. Or you need to convert .bin to .hex (or use nrfjprog to read hex but you may need to modify the .hex so that it only contain the meaningful part not the 0xFFFFFFF part). 

DFU bootloader when running in dual mode will not overwrite the application until the image is received. 

[nrbrook]

Ok thanks, is there a tool that can convert bin to hex? And how can I obtain a flash address and length of data from the application?

[Hung Bui]

What you want to achieve is kind of advance. It's not something out of the box that we can provide. Knowledge on binary (and hex) image is needed.

If you want to do something, please do search before asking. 

[nrbrook]

I understand that it is not a normal task, and I did search before asking but found nothing. But guidance on how this can roughly be achieved can lead me in the right direction. I’m not asking for it done for me, just how it could be done. So far I’m not sure how I would be able to get the address and length of the data. I guess I would need to store the data at a fixed place in flash specified in the hex file. The length could be stored in the data. But I am asking because perhaps there is another way. I see ARM have a bin2hex tool so I guess I could merge the data into the firmware hex directly using that? And then just use nrfutil to generate zip normally?

[Hung Bui]

Yes you can use bin2hex to convert to hex file.

When you have the .bin file (can be from hex2bin or from nrfutil) you will have the size of the .bin file equal to the size of the actual image. 

Note that unlike .hex file, in .bin file there is no concept as address. Bin file is simply binary, the actual image data, no address. 

The challenge is just to create a hex file that contains the 2 images. I haven't done this but I do think that it should be possible using the 2 .bin files, combine them and convert them back to .hex.

In your code, to detect where the image started you can make a pattern that mark the start of your firmware for example 100 bytes of 0xAA continuously. (in my DFU master code, I simply going backward and look for first byte which is not 0xFF as the marking of the end of the image, please have a look in find_image_size() ). But it's the best if you can modify the bootloader to write to a place in bootloader setting to mark where the image is and the size of the image.