nRF52840 dongle UART application only works on "older" batch of dongles.

[marcv]

Dear Nordic Team,

I recently ported the BLE UART example project for the PCA10056 to the PCA10059 dongle (SoftDevice 113). I added some minor changes like RX/TX pins, GPIO config for an additional button and some special character escaping to trigger LEDs.

Everything works as expected with my "old" dongle:

• Revision: 1.2.0
• Date: 2020.7

I flashed the exact same binary to the "new" dongle I recently ordered.

• Revision1.2.0
• Date: 2020.19

Here the application shows an erratic behavior: Data received via BLE RX is not forwarded to UART TX, and data received by UART RX is not forwared to BLE TX.
Instead, everything received by UART RX is directly "looped back" to UART TX.

I'm really lost here, since I cannot debug the application on the dongle. Plus I would expect the same binary to behave the same on a device with the same Revision.

Many thanks for your help!

Marc

[Simonr]

Hi Marc

That sounds very strange indeed. Have you done any extra soldering (added extra buttons/LEDs or cut/shorted any solder bridges) on either of the Dongles? Seeing as the UART RX and TX seem to go in a loop, could there be a short between your UART pins on this new Dongle perhaps? There should indeed be no differences between any revision 1.2.0 Dongles so I'm somewhat lost as well.

Can you try reverting the Dongles to their production bootloaders before trying to program them with the same file again? You can follow the Dongle Programming tutorial for guidance. You can also try to build the application to run on the internal RC oscillator instead of the external LF clock to see if that could be the issue by editing these defines to the below values in your sdk_config.h file (if youre using the nRF5 SDK that is).

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.

// <0=> NRF_CLOCK_LF_SRC_RC
// <1=> NRF_CLOCK_LF_SRC_XTAL
// <2=> NRF_CLOCK_LF_SRC_SYNTH

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature.
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.

// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#endif

Best regards,

Simon

[marcv]

Hi Simon,

Thanks for your Answer! Yes I'm Using Nordic SDK (nRF5_SDK_17.0.0_9d13099, I didn't yet update because that's the version I had when starting the project).

I tried with your suggested modifications of the LF clock, but so far no change at all. I tried to re-flash the bootloader with the specific file linked in the dongle programming tutorial:

'graviton_bootloader_mbr_v1.0.1-[nRF5_SDK_15.0.1-1.alpha_f76d012].hex'

But Apparently this is not possible via DFU, I received an error stating the bootloader is unsigned.
Do I need a debug probe for this?

I didn't solder on anything yet besides the RX/TX pins for the UART, RX being P0.10 and TX being P0.09, and I checked for short circuits.

Best Regards

Marc

[Simonr]

Yes, to re-flash the bootloader on the Dongle you will need a debugger I'm afraid. I'll try to track down a 2020.19 dated Dongle myself to see if I can reproduce it or if this looks like an issue with the one specific Dongle.

Best regards,

Simon

[marcv]

Hi Simon,

Thanks again, the thing is I have multiple of the "new" dongles which all behave the same, therefore I suspect it to be a systematic error.
Appreciate your effort!

Best Regards

Marc

[Simonr]

Hi again

Still haven't been able to find a Dongle where this is reproducible in our offices, but it could be that SDK v17.0.0 is the culprit here, as it's not handling some errata correctly in the newest devices with unknown HW ID. Check out the nRF5 SDK v17.0.2 release notes for details. It's strongly recommended to move to v17.0.2. The necessary updates to make older projects compatible with SDK v17.0.2 are described there as well.

Best regards,

Simon