This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Add firmware for different MCU inside the NRF flash

Hi,

I have a low level mcu (128 kbyte flash) connected via UART to the nRF52840.

My current flash usage (text output arm_gcc) is about 256 kbyte + the softdevice.

Since the nrf52840 has 1MB flash I would like to add the firmware of the smaller MCU within the nrf firmware.

During DFU I would then flash first the nRF and then proof the included firmware of the low level MCU with a checksum and the flash the low level MCU reading from the flash.

What would be the easiest way to do so? How can I reserve this space in flash since I am using as well the fds module of the nrf52 low level library.

Thanks in advance,

C.W.

Parents
  • Hi Constantin, 

    Please correct me if I'm wrong. Your plan is piggybacking the image of the external MCU in the DFU package for the nRF52840. And when you update the NRF52840 via BLE/Serial you will send the image of the nRF52840+image of the low level mcu in one shot. After that the nRF52840 will send ( do DFU) the image down to the low level MCU. 

    If it's the case I think it's possible. You can find here  in my DFU master code where I use a nRF52 as the master to do DFU on another NRF52 (DUT). The nRF52 master is flashed with the image of the DUT in addition to the nRF52 master running firmware. You can use it as a reference. 
    The challenge here is how to create an DFU image that combine the image of the nRF52840 and the low level mcu. My idea is to simply follow what I did in the example, use loadbin to put the binary of the low level MCU into the nRF52840 that runs the new image. You can put the init packet and the image right at the location right after the new image.

    To detect that you may need to have a special trunk of data for example 0x5555AAAA to mark that it's the start of the new image. Then you can dump the hex out and then generate the .zip from that hex. You may need to edit the hex file so the length of the hex match the nRF52840 image + init packet  + low level mcu image instead of 1MB binary. There can be other way of doing that with other tool to convert binary - hex, but I think this could be an easy one. 

  • Thanks for the help. I've found a different solution in the forum which uses https://github.com/AntumDeluge/bin2header.

    Then one could include the other firmware via a header file inside the FLASH and call it inside the application. I did not yet tried all parts of it but at least it compiles and give me the size of the binary file. So so far we can close this issue.

    Thanks

  • Follow up:
    I've just managed to piggy bag the firmware of the low level MCU inside the NRF firmware with the bin2header tool. The nice thing is, that one can use the binfile and thus can save some space of the overall firmware in case the low level controller does not need all flash and one can do checks during the compilation with checksums. The overall software is then always bundled.

Reply
  • Follow up:
    I've just managed to piggy bag the firmware of the low level MCU inside the NRF firmware with the bin2header tool. The nice thing is, that one can use the binfile and thus can save some space of the overall firmware in case the low level controller does not need all flash and one can do checks during the compilation with checksums. The overall software is then always bundled.

Children
No Data
Related