BLE Firmware Update CONFIRM_ONLY RESET stage issues

[jpowell]

Hello!

Recently while performing a BLE firmware update using the mcuMgr Library, the stages of the firmware update are as follows VALIDATE, RESET, and fail on UPLOAD. When I believe the order should be VALIDATE UPLOAD CONFIRM RESET. This has happened both within my project and within the nRF deivce manager test app. In addition to this, I usually receive the no_entry(5) error. I've additionally tried to use the logger suggested by the library, however it isn't compatible with the version of flipper I am using in my mobile project. Are there any known issues that would cause the reset to happen so early into the cycle, causing a failure in the update process?

Thanks in advance!

[Aleksander Nowakowski]

Hello,

In the VALIDATE state the library reads the image state on the target device by sending the "list" command from Image Group. As a result, a list of slots is returned with a hash of a firmware that currenlty is on that slot, and some flags. Then, based on the hashes, the flags and the properties of the selected firmware the library decides on what to do.

In the simplest case, where the "list" command returns just the slot 0 (primary), the new image is uploaded, confirmed and reset, like you would expect. On the next attempt, it returns slot 0 (with the new fw) and slot 1 (which now contains the old fw). When you try to update to version 3 the slot 1 will be erased (may take couple of seconds), but it will be done automatically, so the states of the library will be the same: VALIDATE, UPLOAD (10+ seconds gap before progress accelerates for erasing the slot), CONFIRM, RESET.

When the slot 1 already contains the fw which you wanted to update to, there is nothing to be sent, so we have VALIDATE, CONFIRM, RESET.

However, there are more complex situations. Let's say a user used Test instead of Confirm. The library goes: VALIDATE, UPLOAD, TEST, RESET. Now, when you reconnect, the slot 0 contains the "firmware under test" with active flag set, and slot 1 with the old firmware with confirmed flag set. Neither of them can be erased in this state. There are 2 options to exit this state: 1. sending Confirm command will confirm it, set both active and confirmed flags on the firmware in slot 0 making slot 1 available for erase, or 2. sending RESET command to revert to the previous firmware and erasing the new slot as a side effect. So the lib would do VALIDATE, RESET, UPLOAD, CONFIRM, RESET.

There is even more complex case, where a user would send a new fw, then send a Test command but not the Reset command. In that case the fw in slot 1 (secondary) has pending flag making it also non-erasable. There are again 2 ways to exit this state: 1. send Reset command to enter the test mode (like in the previous paragraph) and another Reset command to exit test mode, or 2. send Confirm command and then Reset command to switch to the firmware that was sent.

This last case was actually only fixed in version 2.4 of nRF Connect Device Manager library. Please update if you aren't using this version. Earlier versions were doing only one Reset and expecting it to work. If the slot 1 has a pending flag set sending a single Reset just enables the test mode, so an attempt to upload anything will end with error 5: NO_ENTRY. Solution is to send Reset, restart the device with a button or sending Confirm command and retrying DFU.

[jpowell]

Thanks for the response! Would you expect this behavior described to also occur with a pending state for CONFIRM_ONLY mode? Additionally, if this is the case would you expect the 2.4 software fix to be present on the nRF device manager tester app?

[Aleksander Nowakowski]

Yes, the latest version of nRF Connect Device Manager is 2.4. Instead of trying to calculate required steps from a single Validate, if it needs to reset it then again goes to Validate, and possibly again. 

With the secondary slot confirmed but not reset one Reset is required. After a reboot the second shot should be erasable and you shouldn't be getting error 5. Check what state the device is in before you get 5. 

Why nRF Logger isn't available on your phone?

[jpowell]

Oh sorry for the misunderstanding, the logging app does work on my phone. Just not the logging library that nordic uses in their library. Anyways, it seems like Slot 1 is stuck in a pending state, which by your description would be causing that reset correct? How would a slot get stuck in a pending state? I am also generally at the very beginning of the upload state when I get this error.

Thanks again!

[Aleksander Nowakowski]

The pending state is set when the user/app sends Test command after uploading an image but doesn't send Reset command to initiate the swap. In nRF Connect Device Manager this can be achieved on the Image tab / Advanced view, where in Image Control you can tap READ and TEST buttons.

If you'd use Basic view, which is using Firmware Update Manager, it is not very likely, as the possible modes (Test only, Confirm only, Test and Confirm) always send the Reset. Perhaps there is some weird case where you'd end up with a pending image in some other way, but I would say it's a bug and I have no idea how to.

jpowell said:

I am also generally at the very beginning of the upload state when I get this error.

Yes, the error 5 (No Entry) is called after sending the first packet which should erase the slot. Erasing isn't possible, so upload fails.

[jpowell]

Interesting, I have been recently getting the new Images I'm flashing stuck in pending mode, so even if I don't get the noEntry(5) error and the app say that the firmware update was successful, I still have the previous BLE version on the device. Additionally, when I read out the Images, slot 1 (the one I flashed) is not confirmed and stuck in pending. 

[Aleksander Nowakowski]

That looks like a bug on the firmware, perhaps Vidar Berg can help.

Confirm Only should set both pending and permament flags.

[Vidar Berg]

If it remains stuck in the pending state across resets, it suggests the bootloader is unable to swap the new FW image. This can happen if the memory layout used by the app and bootloader doesn’t match. Does your project use a static partition file to ensure the memory layout is consistent across builds/versions (Static partition requirement for DFU)?