From what I can see the scenario where you have a serialized app running from a separate CPU and how to do firmware update on that is not discussed anywhere on the Nordic site and I am trying to get some ideas so I will not find myself duplicating a lot of work that Nordic software engineers are already doing somewhere and maybe release at some point in the (near?) future.
So to make a long story short:
-
we have a pretty complex solution with a STM32F4 + NRF51 (which could soon be updated to STM32F7 + NRF52 and then go to much larger-scale production); the STM32 has a very well designed firmware update procedure where we can activate options that can make that one safe enough
-
the BLE part of it is almost perfect, no serious problems there since softdevice S130 v2.0.0
-
however the very quick move from 2.0.0 to 2.0.1 raises the valid question if we would not be much better on the longer term having a very clean upgrade path in the Nordic circuit too
-
for the moment we do not want a DFU update over BLE, we would be perfectly fine just updating the Nordic from the main CPU over the same connection (SPI) that we already use for serialization
-
from what I can see that is not already supported
-
one way to add that would be to add a new packet type , something like SER_PKT_TYPE_USER_CMD = 0x80 , and then directly encode and decode (ser_conn_pkt_decoder.c) those packets
-
probably a more elegant way would be to extend the existing SER_PKT_TYPE_CMD = 0 with new commands and just add handlers for those (basically extending conn_mw_item[] list) with new custom commands like SD_USER_CUSTOM_CMD_1 and/or - and here I would like to know if that is not already done by Nordic software engineers themselves - adding serialization handlers for functions like sd_mbr_command() and ble_flash_block_write() (even if that might not be an easy task).
I do not know if I explained well enough what I need - but I am open to any other suggestions or ideas on the topic.
