This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Different FW behavior if flashed using BLE DFU

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?

  • I removed watchdog code from project. And now device hangs up. So now I am 100% sure restart was done by nrfx_wd.

    It looks now for me like interrupts (or FreeRTOS mutex) dead lock. 

    But I still wonder why it never happens if device was flashed using debugger.

  • "I removed watchdog code from project. And now device hangs up. so now I am 100% sure restart was done by nrfx_wd"

    I don't understand whether you mean that it was caused by the watchdog or not.

    Do you have any possibility for logging? I suggest that you define DEBUG in your preprocessor defines of your application. If you do, then the log should tell you where the device restarts.

    Either way, you should define DEBUG and try to set some breakpoints in app_error.c. I can't tell you exactly where, since it is dependent on the compiler you use. Try to add an APP_ERROR_CHEK(1); in your main() function, and debug through it, and you should see what handler that is called. See if you can see where it tells you what err_code (=1), what file name (main.c) and what line_number (the line number containing APP_ERROR_CHECK(1)) it comes from. When you find this, remove APP_ERROR_CHECK(1), and keep the breakpoint. Then you should see where the error comes from.

    Best regards,

    Edvin

  • No, problem is not caused by watchdog. It is something in code.

    With debugger I never catch this issue. Otherwise I probably would not post.

    I will try to analyse interrupts and post here when I have information.

  • I see. You can still try to read the reset register. After the chip resets, you can use "nrfjprog --memrd 0x40000400"

Related