• State Not Answered
  • Replies 2 replies
  • Subscribers 67 subscribers
  • Views 428 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 304655
Options

Wondering the best place to add transport layer for DFU?

bmalchow

Hello,

I am wondering where the best place to add a transport layer for DFU is?  I have both bootloader examples working, but now i need to add the transport layers.  On one board it will be SPI, the other it will be Thread.

I could accept Thread frames / SPI (CAN Controller IC) frames via the app and write to the slot, and invoke a NVIC RST when the number of image bytes have been received.

I could also write a secondary stage bootloader to facilitate this.

Per reading, it is advised not to add a secondary bootloader if not necessary.

Am I thinking about this correctly?

Thanks,

Ben

Parents
  • 0
    Sorry for late response, this thread seems to have fallen into wrong cracks.
    I will respond and close this thread as this is a bit old.
    You were on the right track. The DFU process is designed to be transport agnostic, as long as a reliable transport layer is used. The DFU transport module defines a generic interface that must be implemented for each transport layer. Currently, the DFU transport module supports BLE, UART, and USB CDC transport, but you can add your own transport layers such as SPI or Thread.
    For implementing the SPI transport layer, you can use the DFU target library. This library allows you to handle the image received over SPI on the server side
    For implementing the Thread transport layer, you might want to start with the SMP Server sample and see how it uses mcuboot.c and flash_img.c to place the update binary in slot 1.As for adding a secondary bootloader, it's generally advised to avoid it if not necessary. However, if your use case requires it, you can certainly implement it. Just make sure to thoroughly test it to ensure it works as expected.
    you might need to develop a custom solution as there is no direct reference in the provided sources.
    As for the bootloader, it is generally advised to avoid adding a secondary bootloader if not necessary. However, if your use case requires it, you can consider it.
Reply
  • 0
    Sorry for late response, this thread seems to have fallen into wrong cracks.
    I will respond and close this thread as this is a bit old.
    You were on the right track. The DFU process is designed to be transport agnostic, as long as a reliable transport layer is used. The DFU transport module defines a generic interface that must be implemented for each transport layer. Currently, the DFU transport module supports BLE, UART, and USB CDC transport, but you can add your own transport layers such as SPI or Thread.
    For implementing the SPI transport layer, you can use the DFU target library. This library allows you to handle the image received over SPI on the server side
    For implementing the Thread transport layer, you might want to start with the SMP Server sample and see how it uses mcuboot.c and flash_img.c to place the update binary in slot 1.As for adding a secondary bootloader, it's generally advised to avoid it if not necessary. However, if your use case requires it, you can certainly implement it. Just make sure to thoroughly test it to ensure it works as expected.
    you might need to develop a custom solution as there is no direct reference in the provided sources.
    As for the bootloader, it is generally advised to avoid adding a secondary bootloader if not necessary. However, if your use case requires it, you can consider it.
Children
Related