nRF52 DFU working on dev kit, not on custom board

[ejb10293]

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.

[ejb10293]

I'll be able to test on duplicate boards in a few days. In the meantime, I tried cutting the traces SB1 and SB2 on the dev board to prevent it from using the external LF crystal - it still worked fine using the internal RC oscillator, so that doesn't seem to be the issue.

I was able to get better results (ie - very slow but successful transfer of the firmware package) on my own board by disabling the scheduler module in the firmware - of course, this isn't really a workable solution, but it suggests to me that the processor may be thrashing for some reason (continuous interrupts?) that cause BlueTooth timeouts... With the scheduler disabled, I was able to more consistently connect to the device over nRF Connect and was able to get the RTT logs through the console (with the scheduler enabled, usually I can't get any RTT messages at all).

Is there a good way to debug this issue? When this failure occurs, there's no error message over the RTT log - it just hangs...