nRF52532 can't quit ota mode if ble disconnect

RE: nRF52532 can't quit ota mode if ble disconnect

Einar Thorsrud — Fri, 23 Aug 2019 09:02:45 GMT

Hi,

Since the application is deleted there is no application to start, so the only option for the bootloader is to stay in DFU mode. The only way to prevent this from happening is by using dual bank upgrades. If so, the new application would have to fit between the end of the old application and the beginning of the bootloader, or even lower if you use FDS or other application data in flash below the bootloader (see memory layout). Since that is not being done I assume there is not enough free space to do a dual bank application upgrade? If there is no free space then you have to live with the fact that the app stays in DFU mode until a successful upgrade, or alternatively see if you are able to make the application smaller to make it fit.

RE: nRF52532 can't quit ota mode if ble disconnect

visionwang — Fri, 23 Aug 2019 08:53:15 GMT

After using "nrfjprog.exe --memrd 0 --n 0x80000 > flash_dump.txt", I find that part of the application is erased in DFU process;

How should I do to fixed it;

Thanks.

RE: nRF52532 can't quit ota mode if ble disconnect

visionwang — Fri, 23 Aug 2019 08:48:14 GMT

Hi,

SDK version is v12.3, and SoftDevice version is v3.0;

I mean the OTA process is interrupted in the middle of the upgrade, bootloader stays in DFU mode;

Why the OTA process is interrupted in the middle of the upgrade is because the phone disconnects. If there is no application in flash , could timeout still work? Timeout will restart device, but there is no application, will bootloader stay in DFU mode?

Thanks

RE: nRF52532 can't quit ota mode if ble disconnect

Einar Thorsrud — Fri, 23 Aug 2019 08:15:13 GMT

Hi,

Which SDK and SoftDevice version are you using?

[quote user=""] when device is in ota mode, app quits abnormly, we find device will in OTA forever;[/quote]

I am not sure I understood the question correctly. Do you mean that the OTA process is interrupted in the middle of the upgrade? If so, then there are a few things that could be happening:

If you use a single bank update of the application, then the application will be erased at the start of the DFU process. So in that case, there is no application to start and the bootloader will always enter and stay in DFU mode until a valid application is transferred via DFU. Is the application upgraded via a single bank or dual bank? (recent SDK versions will automatically use dual bank if there is room for it, if not single bank). You can check the state of the device by reading out the flash content using for instance "nrfjprog.exe --memrd 0 --n 0x80000 > flash_dump.txt". This will show you if the application is present or not.
If the phone disconnects somewhere in the DFU process, the bootloader might be stuck there. This should not happen with recent SDK versions though, as there is a timeout.

Or does the problem happen after successfully programming the application via DFU? If so, then a typical reason is if your new code writes to flash, and this flash is within the part of the application that the bootloader checks the CRC of (to see if the application has been corrupted for some reason). If so, the bootloader will enter DFU upgrade mode.

In either of the two cases using RTT logging in the bootloader is always a good idea, as it will most of the time tell you why the bootloader stays in DFU mode instead of starting the application. Note that you must use the debug bootloader project for this.

[quote user=""] There is 2 versions, A and B, A can quit ,but B can't, B just adds one function, OTA of B is same as A's;[/quote]

Can you elaborate?