This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
If CC2640R2F is work as SNP, how would the OAD be? Any reference design? Should it be in on-chip mode or off-chip mode? If it is in off-chip mode, the serial flash should be connected to MCU or CC2640?
Thanks.
- YY
Hi Jeff,
In that case, it is a wired transfer of new firmware to the host. How about OAD transfer to the host? In another words, how does OAD works in SNP mode? Does the external flash still required? Any guidelines on this topic?
Thanks.
- YY
Hi YY,
We do not provide a sample for OAD of a two-chip system using the SNP. You can define any custom characteristic to transfer a firmware file over BLE, and with any supported profile/service, the SNP will pass the received data to the host MCU. The host MCU can store the incoming firmware file, parse/validate it and program the CC2640R2F using the serial bootloader (we do provide sample bootloader code for CC26xx). In this case, no ext. flash is required on the SNP since it's assumed the host MCU will store the incoming file.
As is typically the case with multi-chip BLE network processor designs, other MCU(s) on the board will be updated during the firmware update. Since other MCUs have their own firmware packaging requirements, the implementation becomes board specific. What I have seen in the past is individual firmware binaries are globbed or "tarred" into one large file which is then encrypted/signed and sent to the network processor as one file via a custom BLE service. The host MCU will then un-tar the file and update the MCUs individually.
In other words, the SNP simply facilitates the transfer of the file(s) to the host MCU which is then responsible for resetting and updating the firmware of the SNP using the CC26xx ROM serial bootloader.
I hope this helps.
Best wishes