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

nRF52 DFU working on dev kit, not on custom board

I've been having a very difficult time debugging this issue. I've modified the bootloader_secure example and have it working on the dev kit using the 330 Softdevice. It works great, and I'm able to update and run my own firmware images using the nRF Connect android app.

The issue is when moving to my own custom board. I know my custom device works fine with BlueTooth, since I've been working on a separate app that functions exactly the same as the dev kit - BlueTooth and all.

The problem is trying to run the bootloader code on the custom board - it sometimes takes several attempts to connect over BlueTooth using the android app, and then DFU hangs after about 6% completion if it even gets that far. There's no error message over RTT - just a hang and a GATT CONN TIMEOUT error on the android log, as if there was a hard fault somewhere in the CPU. The one difference I should highlight between my device and the dev kit is that my board does not utilize an external low frequency crystal, so I modified the code to use the RC oscillator - again, this code works fine on the dev kit.

I suspect there may be some CPU thrashing going on or some clock instability maybe, as sometimes I can't even get the RTT console logs to display, suggesting a pretty low level issue. Here's what I've tried:

  • Adjusting MIN_CONN_INTERVAL and MAX_CONN_INTERVAL

  • Using NRF_CLOCK_LF_SRC_SYNTH instead of NRF_CLOCK_LF_SRC_RC

  • Reducing the number of packets sent by nRF Connect from 10 to 5 and 1

  • Adjusting HCI_RX_BUF_QUEUE_SIZE from 4 to 16

What's strange is the identical code - s330 softdevice and all - runs fine on the dev board. I can step through the code using Eclipse just fine, but I'd be grateful for some suggestions as to how to debug this more effectively.

Parents
  • I haven't taken the time to get ble_app_hrs working, but I confirmed that ble_app_bps works on both the dev kit and my custom board with the following change in ble_stack_init to make it use the internal RC oscillator:

    nrf_clock_lf_cfg_t clock_lf_cfg = {.source 			= NRF_CLOCK_LF_SRC_RC, \
        				            .rc_ctiv       	        = 16, \
    						   .rc_temp_ctiv  	        = 2, \
    						   .xtal_accuracy 	        = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM};
    

    I also made the same change as above to the bootloader_secure example, which runs s132. The code worked fine on the dev kit but I saw identical failures as I described above using my custom board (I used the dfu_test_app_hrm_s132 image). Specifically, it takes several tries to get a successful BlueTooth connection on my board, and then the DFU transfer fails with a GATT CONN TIMEOUT right after the app starts uploading the firmware package.

    It seems like there is something about the bootloader_secure code that does not work well with my board. Again, I suspect this may be an issue with processor thrashing...

Reply
  • I haven't taken the time to get ble_app_hrs working, but I confirmed that ble_app_bps works on both the dev kit and my custom board with the following change in ble_stack_init to make it use the internal RC oscillator:

    nrf_clock_lf_cfg_t clock_lf_cfg = {.source 			= NRF_CLOCK_LF_SRC_RC, \
        				            .rc_ctiv       	        = 16, \
    						   .rc_temp_ctiv  	        = 2, \
    						   .xtal_accuracy 	        = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM};
    

    I also made the same change as above to the bootloader_secure example, which runs s132. The code worked fine on the dev kit but I saw identical failures as I described above using my custom board (I used the dfu_test_app_hrm_s132 image). Specifically, it takes several tries to get a successful BlueTooth connection on my board, and then the DFU transfer fails with a GATT CONN TIMEOUT right after the app starts uploading the firmware package.

    It seems like there is something about the bootloader_secure code that does not work well with my board. Again, I suspect this may be an issue with processor thrashing...

Children
No Data
Related