• State Verified Answer
  • Replies 3 replies
  • Subscribers 73 subscribers
  • Views 1191 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 250651
Options
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

Constantin

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
  • +1

    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. 

Reply
  • +1

    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. 

Children
Related
Terms of service