Hello,
Could it be possible to do an update with a zip DFU file stored in a flash memory ?
What is the best way to do the modifications (mainlines) ?
Thank you
Hello,
Could it be possible to do an update with a zip DFU file stored in a flash memory ?
What is the best way to do the modifications (mainlines) ?
Thank you
Hi,
This is possible. Nordics DFU solution is designed to be flexible when it comes to data transport, and essentially you can perform DFU as long as you are able to make API calls with the data to nrf_dfu_transport. Based on your requirements there is a simple way to do this and a better but more complex way to do it:
The simple way to do it is to treat the SD card as yet another transport layer for the DFU process. The DFU process is already designed around the concept that the DFU process doesn't know or care how data is being exchanged and it's up to the transport layer to implement the API for communication with the DFU correctly. You can implement your own DFU host running within the transport layer and sending the firmware piece by piece to the DFU process. This solution should be fairly quick, but there is still some overhead to it. The big advantage an SD card gives is that there is more storage space available, and this solution will not take advantage of this.
Your job in implementing this is not too complex. You should be able to do this with few or no changes to the deeper layers of the DFU. This is very good since it means that you can rely mostly on Nordic having tested these modules before shipping them. A bug in the DFU protocol part of the DFU can brick a device, while a bug in the transport layer will give an error without breaking the device. You can start with the serialized DFU and the transport layer implementation present in that example and implement the rest yourself. You will have to implement something which reads the data from the SD card and operates as a DFU host. As a starting point for how the DFU process operates you can have a look at the python implementation in nrfutil.
The other alternative is to implement a more tailored solution utilizing that your device can read/write data directly from the SD card. You would keep the security features which verify the signature of the firmware and performs the actual copying when the firmware has been verified. This will require you to design your own system and ensure that there are no bugs which may brick the system or be exploited to bypass the security. The advantage is that you may be able to do these updates faster and without erasing the old application to receive the data over the air.
For its simplicity, I would recommend going with the first option. It lets you reuse much more of the existing solution from Nordic Semiconductor.
Do not hesitate to ask further questions regarding these suggested solutions.
Best regards,
Rune Holmgren
Hi,
This is possible. Nordics DFU solution is designed to be flexible when it comes to data transport, and essentially you can perform DFU as long as you are able to make API calls with the data to nrf_dfu_transport. Based on your requirements there is a simple way to do this and a better but more complex way to do it:
The simple way to do it is to treat the SD card as yet another transport layer for the DFU process. The DFU process is already designed around the concept that the DFU process doesn't know or care how data is being exchanged and it's up to the transport layer to implement the API for communication with the DFU correctly. You can implement your own DFU host running within the transport layer and sending the firmware piece by piece to the DFU process. This solution should be fairly quick, but there is still some overhead to it. The big advantage an SD card gives is that there is more storage space available, and this solution will not take advantage of this.
Your job in implementing this is not too complex. You should be able to do this with few or no changes to the deeper layers of the DFU. This is very good since it means that you can rely mostly on Nordic having tested these modules before shipping them. A bug in the DFU protocol part of the DFU can brick a device, while a bug in the transport layer will give an error without breaking the device. You can start with the serialized DFU and the transport layer implementation present in that example and implement the rest yourself. You will have to implement something which reads the data from the SD card and operates as a DFU host. As a starting point for how the DFU process operates you can have a look at the python implementation in nrfutil.
The other alternative is to implement a more tailored solution utilizing that your device can read/write data directly from the SD card. You would keep the security features which verify the signature of the firmware and performs the actual copying when the firmware has been verified. This will require you to design your own system and ensure that there are no bugs which may brick the system or be exploited to bypass the security. The advantage is that you may be able to do these updates faster and without erasing the old application to receive the data over the air.
For its simplicity, I would recommend going with the first option. It lets you reuse much more of the existing solution from Nordic Semiconductor.
Do not hesitate to ask further questions regarding these suggested solutions.
Best regards,
Rune Holmgren