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]

Something is very wrong here... Making just the single change you suggest causes bootloader_secure to fail completely on the dev kit. I'm not able to connect to it at all over nRF Connect, and I get a very strange looping output over RTT. Again, this looks to me like a thrashing issue - even the RTT log messages are being cut off here...

Here is a copy of the output...

:IN:INFO:Inside main
:INFOf_dfu_transp:INFO:Inside main
:INFO:In nrf_bootloader_init
:IN:Single: Invalid bank
:INFO:Enter nrf_dfu_app_is_v:INFO:Inside main
:INFO:In nrf_bootloader_init
:INFO:In real nf_dfu_transports_initinue
:INFO:Single: Invalid bank
tinue
:INFO:Single: Invalid bank
:INFO:Enter nrf_:INFO:Inside main
:INFOf_dfu_transports_ini:INFO:Inside main
:INFO:In nrf_bootloader_init
:INFO:In real nrf_dfu_init
:INf_dfu_transports_init
:INFO:num tra:INFO:Inside main
:INFO:In nrf_bootloader_i:INFO:Enter nrf_dfu_continue
:INFO:SingleIn nrf_dfu_transportsu_continue
:INFg nrf_dfu_settings_init
:INFO:Enter nrf_dfu_continue
:INFO:Singleceived an error: 0x0000n valid app check
:INFO:In nrf_dfnside main
:INFO:In nrf_bootloader_init
ransports_initnrf_dfu_init
:INFO:numransports_init
:INFO:num transports::INFO:Inside main
:INFO:In nrf_bootloader_itinue
:INF:INFO:Insidetinue
:INFO:Single: Invalid bank
:INFO:Inside main
f_dftinuenrf_bootloader_init
:INFO:Si:INFO:Insidef_dfu_tr:INFO:Inside main
:INFO:In nrf_bootloader_init
:INf_dftinue
:INFO:Si:INFO:Inside maitinue
:INFO:Single: In:INFO:Inside main
:INFOf_dfu_trtinue
:INFO:Singlef_dfu_transports_init
:INFO:num transpo:INFO:Inside main
:INFO:In nrf_bootloader_init
:INFO:In real nf_dfu_transports_ini:INFO:Inside main
:INFO:In nrf_bootloader_init
:INFO:If_dfu_trtinue
:INFO:Single: In:INFO:Inside main
:INFOf_dfu_trtinue
:INFO:Single: Invalid bank
:INFf_dfu_transports_init
:INFO:num transports: 1
:INFO:Inside main
:f_dftinue
:INFO:Si:INFO:Insidetinue
:INFO:Single: Invalid bank
f_dfu_transports_init
:INFO:num transports: 1
:INFO:Inside main
:f_dftinue

[ejb10293]

OK I tried DFU on another of my custom boards that I assembled today and it worked fine - I think this was an issue with the board itself, maybe a solder bridge or something that caused this problem. Thanks again for your help.

That being said, I still think there is something strange going on with the above - the bootloader_secure app might not be able to run on the NRF_CLOCK_LF_SRC_SYNTH setting...it might be worth tracking down this particular issue.

[ejb10293]

OK I tried DFU on another of my custom boards that I assembled today and it worked fine - I think this was an issue with the board itself, maybe a solder bridge or something that caused this problem. Thanks again for your help.

That being said, I still think there is something strange going on with the above - the bootloader_secure app might not be able to run on the NRF_CLOCK_LF_SRC_SYNTH setting...it might be worth tracking down this particular issue.

[bjorn-spockeli]

Ok, let me know if you see the issue on any additional custom boards. I will test running the bootloader with the synthesized LFCLK on the PCA10040 and see if I see the same behaviour.