Our device is equipped with the secondary bootloader in external flash (@0x00008) as well as 2 product images (@0x08000 and 0x13000).
Wether it is a good idea to place the secondary bootloader in external flash is not in the scope of this topic.
During development of SUOTA, done through an app in IOS, one of our developers managed to brick the device by using SUOTA.
He was using a valid image that works just fine through SmartSnippets SUOTA and runs after reboot.
I managed to analyze the flash and found out that 158 consequtive bytes in the middle of the secondary bootloader in external flash were not what they supposed to be.
This caused the secondary bootloader to not execute and hence the device didn't boot the product image.
The product header (@0x1f000) was still correct.
He is not sure how this happened but the fact that the secondary bootloader in flash can be mangled causes somewhat heated discussions in our team.
Can you think of a way this can happen, f.i. power shortage during the SUOTA proces or executing SUOTA operations in the incorrect order?
We relied on the fact that the SUOTA service designed by Dialog is bullet and fool-proof...
我分析了代码,especially app_spotar.c and think there is a way to get into this situation.
The app_spotar_read_mem modifies spota_state.mem_dev and spota_state.mem_base_add and even calls app_spotar_start. If that happens because our IOS application had started 2 suota processes in parallel by accident, one process might be writing pages into flash, the other process might just indirectly called app_spotar_start.
The spota_state.mem_dev and spota_state.mem_base_add then are set to a value that is unexpected and hence the next write of a page is done to an address that isn't of base address 0x8000 or 0x13000.
In the app_spotar_img_hdlr there is no check anymore if the spota_state.mem_base_add is still correct or not before calling spi_flash_write_data.
Note:, I checked the image @0x8000 and it only contained the first 1200 bytes, the rest was 0xff, so the image was erased and the first 1200 bytes were written. This triggered me into looking for the address that is used in app_spotar.c calling spi_flash_write_data.
Hi paul.deboer,
I am not aware of any similar issue with SUOTA, is this issue a one time occurence or it happens every now and then ? and also can it be replicated with dialog's SUOTA application ? Also i really dont get what you mean that your application starts 2 suota processes in parallel by accident, you mean that from the iOS application two instances of your application start to write both at the same time in order to update the peripheral device ?
I can't imagine how the secondary bootloader in the flash was altered by the SUOTA procedure, or even with a power shortage how the SUOTA wrote on the secondary bootloader area. Are you sure that the incident occurs when the SUOTA procedure is ongoing and that flash corruption isn't a side effect from something else ?
Thanks MT_dialog
这是每一个现在then. No, we didn't manage to replicate that with Dialog's SmartSnippets nor Dialog's SUOTA application. If you do every correct and in the correct order, the problem will not show itself.
I only happens when you have > 1 parallel SUOTA process by accident, our IOS application suffered from that bug a while ago (so not 2 instances of the application but 2 processes within that application).
Yes, the incident only ocurred when executing SUOTA, we'll try to come up with a scenario that reproduces the incident.