RF transmission problem with nRF52840 QFAA

[GabrieleParoli]

Hi, I am developing a board with an nRF52840 QFAA, which needs to communicate via BLE. I tried loading the test code 'ble_app_hrs' from the 'nRF5_SDK_17.1.0_ddde560' folder, but when using a spectrum analyzer, I can’t detect the Bluetooth signal, which I can detect when using the nRF52840-DK evaluation board with the nRF52840 QIAA microcontroller.

When using an oscilloscope, I can see RF power consumption from the chip on the evaluation board, but there’s no RF power consumption on the custom board.

What could be causing this?

I’m using SEGGER Embedded Studio to program the microcontroller. Is there anything I need to configure differently since I’m using a QFAA instead of a QIAA, or should Bluetooth communication work the same way?

Let me know, thanks!

[Einar Thorsrud]

Hi,

What could be causing this?

Have you done any debuggging to see what happens on your devices? A typical reason for example projects not running out of the box on custom boards is that they enable the optional 32.768 kHz ocillator. That needs to be disabled as explained in this post if the the crystal is not used on the board.

Is there anything I need to configure differently since I’m using a QFAA instead of a QIAA, or should Bluetooth communication work the same way?

The package variant should not matter when it comes to this.

[GabrieleParoli]

Hi, let me explain the situation better. On our board, the QFAA microprocessor is connected to an external LF clock of 32kHz and an external HF clock of 32MHz. In order to get BLE working, is it necessary to activate the external 32MHz clock using SEGGER Embedded? I’m attaching a photo of the settings I have in the sdh_config.h file, and they are the same ones that work on the evaluation board. Setting NRF_SDH_CLOCK_LF_SRC to 0 as suggested by the link you shared made the situation worse. If I want to select the external clocks, which lines of code should I change? Thanks!

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <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 1
#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 0
#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 0
#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 7
#endif

[Einar Thorsrud]

Hi,

GabrieleParoli said:

On our board, the QFAA microprocessor is connected to an external LF clock of 32kHz

I see. Then you can ignore my comment about configuring for using LFRC.

GabrieleParoli said:

In order to get BLE working, is it necessary to activate the external 32MHz clock using SEGGER Embedded?

No, the BLE stack will automatically start the HFXO when it needs an accurate clock.

GabrieleParoli said:

Setting NRF_SDH_CLOCK_LF_SRC to 0 as suggested by the link you shared made the situation worse

How did it make the situation worse? Can you elaborate? Also, can you explain about what you have found during debugging? Does the application start? If it does, does it run without issues, or do you see any errors?

[GabrieleParoli]

As mentioned earlier, I am using the example code 'ble_app_hrs'. I added a pin toggle in the heart_rate_meas_timeout_handler function to see if the firmware runs correctly on the microprocessor. Once the code is loaded (no errors), we see the debug pin I just described continuing to toggle high and low, but the Bluetooth is not detected. Using a spectrum analyzer, we are not seeing any spikes around 2.4GHz, which we do see when using the evaluation board.

When looking at the microprocessor pins with an oscilloscope, we see that DEC3 behaves differently on our board, staying fixed at 3.3V, while on the evaluation board, it is around 3V with small spikes downwards at 5Hz (we use a dedicated DC/DC power supply on our board; it is possible that this is the reason?).

Do you know what the DEC3 pin is connected to? The internet mentions it is something related to RF, but it doesn’t specify what exactly. Also, what is DEC1 connected to?

Another thing I wanted to ask is if it is possible to generate a fixed carrier frequency, which would help make debugging easier.

Let me know, thanks!

[ketiljo]

Can you open a new private case, upload the schematic and gerber files and refer to this case please?