Debugging possible HW Issue with DFU

Hi support, 

We have a product that successfully utilizes DFU and is currently in production. However, we have been seeing a couple units that failed DFU but can still transmit via BLE.

As soon as these units start DFU, the units restart instead of entering advertising state.

I have tried to minimized the impact of our application code and only load the bootloader provided in nrf5 SDK and can also verify the same behavior. 

We are using a bluetooth module, BL653u, created by Laird (link attached at the end) which utilizes the nrf52833. As soon as we replaced the Laird module on the failed unit, we can verify the DFU issue is fixed so we know it has something to do inside the module. 

What HW would DFU depends on? any suggestions on how we can root cause the issue?

https://www.lairdconnect.com/wireless-modules/bluetooth-modules/bluetooth-5-modules/bl653-micro-series-bluetooth-51-802154-nfc-modules?utm_source=google&utm_medium=cpc&utm_campaign=Bluetooth&gclid=Cj0KCQiAkMGcBhCSARIsAIW6d0DW1VgkyXfQWHMI4IFX5g0Vns8jXQl0uctsCnL2h6vxFb-htNAkwX4aAioPEALw_wcB

Thanks,

Huy

Parents Reply Children
  • It does see like the modules might be at fault. Either our SoC or the components used by Laird within the module. So maybe Laird can check the modules (do some Failure Analysis) since they might have data related to it's testing etc. If not, we can also try to do some failure analysis for the same, but I would suggest waiting for response from Laird.

    For DFU, you would require a good RF output power/reception. And you would also require a good clock. Other than that I am not sure what else is required. Could you tell us how many units are affected? Have you tried replacing the module from a bad one onto a good unit (just to confirm that it's the module's fault) ?

    -Priyanka

  • Good news, after replacing the module from a bad one onto a good unit, we were able to get DFU working. So looks like it was a board issue and not a module one.  

    Thank you for your help

Related