Keil SDK13 BLE OTA upgrade failure causes the device to become unbootable, requiring re-flashing. How can this be resolved? We are using the bootloader_secure_ble bootloader. Does it support dual-bank OTA? Could you provide a reference sample?
Keil SDK13 BLE OTA upgrade failure causes the device to become unbootable, requiring re-flashing. How can this be resolved? We are using the bootloader_secure_ble bootloader. Does it support dual-bank OTA? Could you provide a reference sample?
I'm using SDK13, but the protocol stack I'm using is s132_nrf52_4.0.3_softdevice.hex. This doesn't seem to be the protocol stack included in SDK13 - the protocol stack in SDK13 is s132_nrf52_4.0.2_softdevice.hex.
Will this affect DFU OTA? Currently, after killing the app, the hardware cannot boot up. How should I handle this issue?
Hi,
Thanks. This show that the program is inside the sd_app_evt_wait() function. This suggests that the device program has not "crashed" but is just staying in sleep waiting for an interrupt. Unfortunately it is not possible to tell from this if the function was called from the bootloader or the application. Next step is to try debug the bootloader and application and see if the program reaches the main app.
"According to the log, the application has been erased. What caused this?"
:DEBUG:Erasing old settings at: 0x0007f000
:DEBUG:Erasing: 0x0007f000, num: 1
:DEBUG:Writing 0x00000057 words
:DEBUG:Writing settings...
:DEBUG:Sending Response: [0x4, 0x1]
:DEBUG:Received create object
:INFO:Before OP create
:INFO:Valid Data Create
:DEBUG:Erasing: 0x00020000, num: 1
:INFO:Creating object with size: 4096. Offset: 0x00001000, CRC: 0x4f9e1f67
:DEBUG:Sending Response: [0x1, 0x1]
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x000010c8, CRC:0x7c50c9ab]
:INFO:Storing 256 B at: 0x00020000
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001190, CRC:0xe34c5138]
:INFO:Storing 256 B at: 0x00020100
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001258, CRC:0xf4dbf38c]
:INFO:Storing 256 B at: 0x00020200
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001320, CRC:0xfad69a8d]
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x000013e8, CRC:0x8d2c78ad]
:INFO:Storing 256 B at: 0x00020300
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x000014b0, CRC:0x123582c1]
:INFO:Storing 256 B at: 0x00020400
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001578, CRC:0xba371df4]
:INFO:Storing 256 B at: 0x00020500
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001640, CRC:0xd7218135]
:INFO:Storing 256 B at: 0x00020600
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001708, CRC:0xc04f36db]
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x000017d0, CRC:0x42b9c0f1]
:INFO:Storing 256 B at: 0x00020700
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001898, CRC:0xe39aa5f6]
:INFO:Storing 256 B at: 0x00020800
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001960, CRC:0x274d3e23]
:INFO:Storing 256 B at: 0x00020900
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001a28, CRC:0x9d4fdb36]
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001af0, CRC:0x0687401b]
:INFO:Storing 256 B at: 0x00020a00
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001bb8, CRC:0x7714f0ad]
:INFO:Storing 256 B at: 0x00020b00
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001c80, CRC:0x181b197b]
:INFO:Storing 256 B at: 0x00020c00
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001d48, CRC:0x08e0dcd3]
:INFO:Storing 256 B at: 0x00020d00
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001e10, CRC:0x650d0d52]
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001ed8, CRC:0x004cb4be]
:INFO:Storing 256 B at: 0x00020e00
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00001fa0, CRC:0x1af7dfa8]
:INFO:Storing 256 B at: 0x00020f00
:DEBUG:Received calculate CRC
:INFO:Before OP crc
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00002000, CRC:0x5fcdda05]
:DEBUG:Received execute object
:INFO:Before OP execute
:INFO:Valid Data Execute
:DEBUG:Erasing old settings at: 0x0007f000
:DEBUG:Erasing: 0x0007f000, num: 1
:DEBUG:Writing 0x00000057 words
:DEBUG:Writing settings...
:DEBUG:Sending Response: [0x4, 0x1]
:DEBUG:Received create object
:INFO:Before OP create
:INFO:Valid Data Create
:DEBUG:Erasing: 0x00021000, num: 1
:INFO:Creating object with size: 4096. Offset: 0x00002000, CRC: 0x5fcdda05
:DEBUG:Sending Response: [0x1, 0x1]
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x000020c8, CRC:0xd8a02b44]
:INFO:Storing 256 B at: 0x00021000
:DEBUG:Sending CRC: [0x60, 0x03, 0x01, 0:x00002190, CRC:0x19e25c16]
Why does the bootloader erase the app region (0x1f0000) when the app is terminated/killed?
Why does the bootloader erase the app region (0x1f0000) when the app is terminated/killed?
Are you referring to this line: ":DEBUG:Erasing: 0x0007f000, num: 1"? This is the location of the bootloader settings page containing the nrf_dfu_settings_t struct used by the bootloader for state keeping during DFU.
0x0007f000 is app address，it is bank0 address
0x0007f000 is app address，it is bank0 address
0x0001f000 is app address，not 0x0007f000,it is bank0 address,not 0x0007f000 is bootloader settings page
What you are seeing is that the FW is being uploaded to bank 1, so it is indeed a dual bank update.
Judging from the logs, it seems the device has been staying in DFU mode, waiting for connection and data transfer. Is there no timeout mechanism in place?
Yes, there is a timeout mechanism, but that does not help if there is no valid application to fall back to. Can you please post the full log? When adding the log, please do so in a code block using the Insert->Code button.
What I provided is the complete log, starting from device boot, the app initiating the update, to killing the app, and then the device staying in the bootloader's DFU mode. Later, I added a reset in the BLE disconnect callback, and it worked normally. The issue is likely with the timeout mechanism. Alternatively, how should I properly implement the reset, and where should I add this reset?