DFU lockup fixed in SDK 16.0?

RE: DFU lockup fixed in SDK 16.0?

Bart Cerneels — Mon, 29 Jun 2020 09:44:47 GMT

We've found an issue in our application code. When an external SPI device was malfunctioning, probably keeping CLK low, nrfx_spim_xfer would hang in an infinite loop.

Initial deployment of a workaround looks good. No lockups after ~100 DFUs.

So we're very likely not hit by the mentioned bug. Thanks for the help.

RE: DFU lockup fixed in SDK 16.0?

Edvin — Fri, 19 Jun 2020 10:08:49 GMT

Sorry. I can't do that. You probably need to port at least the bootloader. Be aware that porting from SDK15.2.0 to 16 (or 17 which was just released) shouldn't be much job, as the softdevice API is more or less unchanged. The main features are support for new chipsets.

If you don't want to port, you can diff the bootloader between 15.2.0 and 16.0.0 (/17.0.0) and pick out the differences (essensially backport the bootloader to support the softdevice from SDK15.2.0)

Best regards,

Edvin

RE: DFU lockup fixed in SDK 16.0?

Bart Cerneels — Fri, 19 Jun 2020 08:57:33 GMT

[quote userid="26071" url="~/f/nordic-q-a/62755/dfu-lockup-fixed-in-sdk-16-0/255905"]Ok, then that may be related to the bug fix. Hard to say without knowing why it didn't reset, but it may sound like a bad state kind of situation. I wasn't aware of this bug/bugfix. You can try to upgrade, and see if it continues to occur. [/quote]

Could I get a patch for SDK15.2 with jus this bugfix?
It's dropped as one big zip without commit history and I'll likely make a mistake trying to figure it out.

Doing a full SDK16 is not feasible for our stable version. We are planning it for a future version.

RE: DFU lockup fixed in SDK 16.0?

Edvin — Fri, 19 Jun 2020 08:53:58 GMT

[quote user="Bart Cerneels"]This is happening only sporadically single digit percentage, more with android as DFU initiator even though it's only 20% of the updates so far. But because of the size of our fleet it's enough to hold the release.[/quote]

Ok, then that may be related to the bug fix. Hard to say without knowing why it didn't reset, but it may sound like a bad state kind of situation. I wasn't aware of this bug/bugfix. You can try to upgrade, and see if it continues to occur.

[quote user="Bart Cerneels"]Could the bootloader be affected by peripheral device interrupts? Or even internal hardware blocks that are not fully reset?
An example of peripheral device that is generating interrupts: our LED engine.[/quote]

My initial thought is no, because the nRF is reset when it enters bootloader mode, and this will reset all the gpios and peripherals, so none of the peripherals are initialized unless you actively do it in the bootloader.

BR,
Edvin

RE: DFU lockup fixed in SDK 16.0?

Bart Cerneels — Thu, 18 Jun 2020 14:51:39 GMT

[quote userid="26071" url="~/f/nordic-q-a/62755/dfu-lockup-fixed-in-sdk-16-0/255815"]The bug that is fixed is a bug that is present if you disconnect during the DFU, which is not a normal case.[/quote]

Our application's DFU process does do automatic reconnects if it loses connection to the bootloader. This is a feature of the Android DFU library from nordic.

We use the following configuration:

.setDeviceName("Cowboy")
.setForceDfu(true)
.setKeepBond(true)
.setForeground(true)
.setMtu(247)
.setNumberOfRetries(3)
.setPacketsReceiptNotificationsEnabled(true)
.setPacketsReceiptNotificationsValue(6)
.setDisableNotification(false)
.setUnsafeExperimentalButtonlessServiceInSecureDfuEnabled(true)

RE: DFU lockup fixed in SDK 16.0?

Bart Cerneels — Thu, 18 Jun 2020 14:35:24 GMT

This is happening only sporadically single digit percentage, more with android as DFU initiator even though it's only 20% of the updates so far. But because of the size of our fleet it's enough to hold the release.

I didn't manage to reproduce it under debug conditions yet. Doing one DFU after the other but no luck. I did try to force a disconnect right after the last block is received by the bootloader, manually using nRFConnect and turning BT off.

Could the bootloader be affected by peripheral device interrupts? Or even internal hardware blocks that are not fully reset?
An example of peripheral device that is generating interrupts: our LED engine.

RE: DFU lockup fixed in SDK 16.0?

Edvin — Thu, 18 Jun 2020 14:25:11 GMT

Hello,

No, I don't think the two are related. Is this issue something you see every time, or from time to time only?

The bug that is fixed is a bug that is present if you disconnect during the DFU, which is not a normal case.

Have you tried to monitor the log from the bootloader project to find out why the device doesn't reset after the DFU transfer is complete in SDK15.2.0?

BR,

Edvin