nRF52 DFU working on dev kit, not on custom board

RE: nRF52 DFU working on dev kit, not on custom board

bjorn-spockeli — Fri, 10 Feb 2017 09:04:07 GMT

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.

RE: nRF52 DFU working on dev kit, not on custom board

ejb10293 — Thu, 09 Feb 2017 23:11:32 GMT

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.

RE: nRF52 DFU working on dev kit, not on custom board

ejb10293 — Thu, 09 Feb 2017 23:11:04 GMT

RE: nRF52 DFU working on dev kit, not on custom board

ejb10293 — Wed, 08 Feb 2017 17:54:01 GMT

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

RE: nRF52 DFU working on dev kit, not on custom board

bjorn-spockeli — Wed, 08 Feb 2017 15:03:59 GMT

I find it wierd that you have any connection issues with the secure dfu example and not the bps. Can you try to use the LFCLK that is synthesized from the HFCLK, i.e. .source = NRF_CLOCK_LF_SRC_SYNTH, and see if that improves the issue?

RE: nRF52 DFU working on dev kit, not on custom board

ejb10293 — Tue, 07 Feb 2017 21:37:18 GMT

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...

RE: nRF52 DFU working on dev kit, not on custom board

bjorn-spockeli — Tue, 07 Feb 2017 13:51:04 GMT

Are you able to run other examples from the SDK without any issues on the custom board, e.g. ble_app_hrs?

RE: nRF52 DFU working on dev kit, not on custom board

ejb10293 — Tue, 07 Feb 2017 02:38:23 GMT

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...

RE: nRF52 DFU working on dev kit, not on custom board

bjorn-spockeli — Mon, 06 Feb 2017 15:34:39 GMT

Do you have several identical custom PCBs? If so, do you see the same issue on the other boards as well?