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?

[GabrieleParoli]

Ok, done! 
Regarding the possibility of generating a fixed carrier frequency, is that possible?
I'm connecting the antenna connector directly to the spectrum analyzer, so no RF is being generated at all from the microcontroller.

Thanks!

[Einar Thorsrud]

Hi,

We will review your hardware files and reply back on that in the private ticked after the weekend, but I am also interested in basic debugging as there could be non-RF related issues here as well (for instance indicated by your measurement of DEC3, I would expect you see somethign there when the radio is active), and basic debugging may tell us things about that. Essentially verifying that the application runs without error.

GabrieleParoli said:

Regarding the possibility of generating a fixed carrier frequency, is that possible?

Yes. You can use the radio test example for that. You only need to modify the UART pins to match your hardware (some pins you can access and hook up to a UART-USB bridge or similar), and then controll it via UART. This is the exampe that we normally recomend for basic radio testing.

GabrieleParoli said:

I added a pin toggle in the heart_rate_meas_timeout_handler function to see if the firmware runs correctly on the microprocessor.

That is a good indication. However, can you also check with a debugger? If you have not checked, it coudl for instance be that the device is in a reset loop where the pin is toggeled before resetting (though in that case it would be unlikely that the frequency of the toggling would match the correct frequency which is 1 Hz here unless you have modified it (the HEART_RATE_MEAS_INTERVAL is 1000 ms). If you have problems debugging or observing logging, a simple way to check this is to also add pin toggling in the start of main that would toggle on every reset. If yo see the pin in heart_rate_meas_timeout_handler toggle continiously and the one in the start of main only once, that would indicate that the application is working (and that we need to focus on your hardware design).

GabrieleParoli said:

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?

We have not documented this publicaly so I cannot share details.

[GabrieleParoli]

Thank you very much, Einar, for the information. The problem with using the radio test example code is that on the board I need to test, I don't have any accessible microcontroller pins that I can connect to a UART-USB converter to control it from a terminal. Is there a way in the test code that uses BLE to utilize a single channel and thus a single frequency, or is frequency hopping between channels mandatory? From what I've read online, they suggested using masks in the 'ble_advertising_start' function to transmit only on one channel, but I tried that and didn’t notice any difference. Let me know if this option exists so that we can know exactly what to expect on the spectrum analyzer.

Regarding the debug pin toggle inside the 'heart_rate_meas_timeout_handler' function, I tried changing the HEART_RATE_MEAS_INTERVAL several times, and each time I reprogrammed the microcontroller, I saw the toggle frequency of the pin change as well (I tried 500ms and 50ms). If necessary, I can run more tests next week.

Let me know, and thanks again for your help!

Gabriele