Internal LF crystal causes buttonless DFU failed

[LHZ]

Hello there, 

The same code works reliably on dev kit but not on my customized hardware.  By cutting the 32k external crystal jumper on the dev kit, the same failure can be preproduced repeatly.  After searching this forum, this seems an old issue and tried all other person's recommendation/combinations, but no luck.

Just wonder if there is a standard solution/fix for this issue. Our product is too small to add an extra 32k crystal part, especially with the mass production coming.

Much appreciation!

Haizhou 

[Edvin]

Hello,

If you don't have an external LFXTAL, then you need to make sure that your application is aware of this (and the bootloader, probably. At least if you are using a BLE bootloader).

Please open sdk_config.h and look for the following definitions, and set them accordingly:

NRFX_CLOCK_CONFIG_LF_SRC 0 // if this one is not present, that is fine. Just ignore it.

NRF_SDH_CLOCK_LF_SRC 0

NRF_SDH_CLOCK_LF_RC_CTIV 16

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2

NRF_SDH_CLOCK_LF_ACCURACY 1

Try that and let me know if that doesn't work.

Best regards,

Edvin

[LHZ]

Hello Edvin,

Thank you so much for the reply!

The setting you recommend is exactly what I am using in my code since this project began. This code works very reliably on my customized board for general features, but NOT for DFU.

Here is my situation:

The customized board was designed without 32k LF crystal. This code works very well on both my customized board and the PCA10040 dev kit.  The code used the same setting your mentioned. 

But when I tried to implement the DFU feature, it still worked reliably on the PCA 10040 kit, but it failed on my customized board.  

Then, I cut the Jumper SB1 and SB2 on the PCA10040 kit, the DFU immediately stopped working. It proved the 32K LF crystal is very likely the reason. 

All above was run with the same setting you recommend. 

I searched this forum and followed others' recommendation. I tried to change the setting to Synth (2); I also changed the NRF_SDH_CLOCK_LF_ACCURACY to other PPM setting.  I tried all combination over these parameters. But no combination worked. 

If we just ignore my customized board and stick with the PCA10040, is there a reliable way to have the DFU working when the SB1 and SB2 were cut?  Could you please verify or confirm the setting on the PCA10040 in your end?

Thank you so much!

Haizhou

[Edvin]

What SDK version and bootloader project are you using?

I'll assume it is SDK17.1.0 and the pca10040_s132_ble until you tell otherwise.

Can you please describe a bit more with what you mean by "but it failed"? Does the bootloader start? Do you see the LEDs indicating DFU mode on the DK? Does it advertise? Assuming you are using BLE? Are you able to connect to it? Can you transfer the image? Where does it fail?

If you are not sure where it is failing, perhaps you can test the pca10040_s132_ble_debug bootloader example. It will have RTT logging turned on, so perhaps it gives some pointers to where it fails.

Best regards,

Edvin

[LHZ]

Hello Edvin,

The problem was solved and thanks for your guide.

This full BLE code was locked over a year ago as a sub project in the main product development.  So, I have forgotten the DFU bootloader image was compiled separately and linked into.  What I kept changing was the BLE general config file, not the bootloader config file.  Your questions led me to check the full code structure and figured out my error.

Thank you again, 

Haizhou