Hello!
I have very strange issue when same firmware works fine if it is flashed using segger debugger and randomly fails (with device restart) when it is flashed using BLE DFU. It is quite hard to realize exact place that provide this restart. Could be even restart done by nrfx_wdt.
SDK version 15.0.0.0
NRF52832
SD 132
Any help, ideas or recommendations?
Hello,
Does the device restart during DFU, or after the packet is transferred, and the application has started?
You use WDT in your application? Do you feed it with when you are in DFU mode? (this is an sdk_config.h setting. Search for NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS)
When you say "randomly fails (with device restart)", does this means that the DFU was successful, and that the new firmware resets occasionally? And that it doesn't happen when you flash it with the segger debugger? Can you try to flash it with DFU, and then debug it? As long as you use the same .hex file, you should be able to debug using segger embedded studio, Keil or IAR (or another debugger application). Does it still sometimes reset? And can you check whether it is one of your APP_ERROR_CHECK(err_code); that receives an err_code != 0?
Best regards,
Edvin
Hello Edvin,
After I flash device over BLE, packet (that has only application code) is transfered and application starts.
I can even see new application version in one of custom characteristics.
I don't have NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS ins SDK config.
Situation is exactly as you say:
```DFU was successful, and that the new firmware resets occasionally```
And it never happens if I flash it using segger debugger.
How can I debug it if Segger IDE always reflash the device?
NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS is in the sdk_config.h file of the bootloader project, not the application project. At least it is there if you use SDK15.0.0.
If you compile your project, create the dfu packet with the new hex file, and perform the DFU, then you can use Segger IDE to debug your device. It is true that it will reflash the device, but as long as you don't do any changes, the application .hex file will be the same, and the bootloader will accept the application.
Alternatively, if you don't want to perform the DFU process every time you make some changes you can look into the bootloader settings tool for nrfutil. If you generate this with your application, and flash it to your device together with your .hex application, it will allow the application to start. Then you can debug, as if you have transferred the application via DFU.
Best regards,
Edvin
NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS is set for bootloader with 10000
In app period is set to 2000 and I feed it up every 1500.
Shall I change it for bootloader as well to 1500? And isn't it related only to case when DFU is in process, is it?
Yes. The NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS is only used during the DFU process, so if the issue isn't happening there, that is not the problem.
I assume that the DFU takes more than 2000ms, which is your WDT timeout, right? So I am surprised it doesn't fail during this period. It might be that if you go to sleep the WDT sleeps as well (during DFU). Although it doesn't time out, it may be that when the application start, it believes it has longer time until timeout than it actually has.
Try to set NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS to 1500.
Have you managed to debug your application? If it resets, can you check the RESETREAS register to check what the reset reason was. The description is in the link. The address of the register is 0x40000000 + 0x00000400 = 0x40000400
Best regards,
Edvin
