BLE runs only while debugging on custom board (probably RTT issue)

[Florian Zierer]

I have problems with my custom board.

I developed the firmware with the nrf52840-PDK and there the firmware runs standalone (with RTT connected and without) or when debugged via eclipse.

Both boards (nrf52840-PDK and my custom board) have the nrf52840 QIAAAA and I'm working with Softdevice 140 and SDK 14.2.

If I run the firmware from my own custom board, everything seems to work when debugging via eclipse or when RTT is not connected. The advertising starts and the device can be found from e.g. nrf-connect and connected.

Usually I use RTT for debugging (on nrf52840-PDK) and everything works fine. The custom board is programmed via jlink from an external nrf52 DK.

If I connect via RTT to my custom board, the advertising does not work correctly. Without RTT, it works.

The power profile (with PPK) looks the same if connected with RTT and without, the advertising seems to have started but nrf-Connect can't receive advertising packets.

Could it be some timing/crystal issue? What are the differences when connected via RTT and when not?

I changed NRF_SDH_CLOCK_LF_SRC from NRF_CLOCK_LF_SRC_XTAL to NRF_CLOCK_LF_SRC_SYNTH and the behaviour is the same. So the 32khz crystal should not be the problem.

It seems to have something to do with the hardware as I can't see this behaviour on the nrf52840-PDK.

21.03.18 Updated LF test, updated to clarify the problem. There was another connection problem but it seems they are different issues (see https://devzone.nordicsemi.com/f/nordic-q-a/32590/error-133-0x85-gatt-error-with-htc-u11-life)

[Vidar Berg]

Hi,

Could you try to enable the HF crystal after startup just to see if it makes any difference? The HF crystal is always "on" in debug interface mode. Although it does not explain why it works when RTT is disabled.

int main()

{

    NRF_CLOCK->TASKS_START  = 1;

    while ( NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

    //app initalization

 Do you have any IOs,etc on the custom board that could be used to indicate if the program goes in a reset loop? 

 

 

[Florian Zierer]

I had to use the following code snippet

    NRF_CLOCK->TASKS_HFCLKSTART  = 1;
    while ( NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

In some test apps I had issues to start and with this code, it seems to start. Does this mean there is an issue with the HF crystal?

Unfortunately it does not help with the rtt problem, as you already mentioned.

I can connect only when RTT is not used,

[Vidar Berg]

"Why did you want me to test to start the HFCLK manually?"

To get an indication whether this issue was clock related. This replicates the clock behavior when the chip is in debug interface mode.  

I think wrong load capacitance can explain the behavior you have been seeing. Please refer to Sigurd's answer in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/30204/hfxo-crystal/119935#119935. 

[Florian Zierer]

Ok, we will try with another crystal with 8pF load capacitance.

But one question. How is the load capacitance in the datasheet (12pF) meant? I thought it is the load capacitance for the crystal

The crystal we are using has 12pF load capacitance (should be in accordance with the spec). But with the formula we needed to add 21pF capacitors to get to the 12pF load capacitance. So with our 22pF we should not be too far off.

The reference circuitry does also not use exact capacitors, the formula would say you have to use 13pF (for 8pF load capaticance) and you use 12pF.

[Florian Zierer]

Hey Vidar,

we exchanged the crystal with a 8pF load crystal and use 12pF capacitors as it is done in the reference circuits.

Unfortunately this does fix the problem. Is there any other hint you could give us to figure out the root for the problem?

[Florian Zierer]

Hey Vidar,

I did some more measurements and I think the crystal is not the problem.

I implemented a test case where I measure a timer with 100KHz and toggle an output pin. The output of 100 pulses is averaged.

If I run the code without manually starting the HFCLK, the pulses from the nrf52840-DK and my Testboard differ.

If I run it when starting the HFCLK manually, they are exactly 10.000µS as they should.

Additionally I measured the startup time of the HFCLK and my board takes a little bit longer but nearly the same as the devboard.

                    Startup Time   Average 100 KHz (10.00µS)   Average 100 KHz
                                   with HFCLK                  No HFCLK
-------------------------------------------------------------------------------
Testboard:          ~345µS         10.000µS                    10.025µs
Development-Kit:    ~334µS         10.000µS                     9.875µS

The crystal seems ok, what do you think?

I'm thinking more and more that the problem (no BLE when RTT is active) lies somewhere else. Perhaps it is because I am debugging with an nrf52-DK Jlink?

Do you have any other suggestions I could have a look at?

[Vidar Berg]

Hi Florian,

Agree, it does not seem to be related to the HF clock. As an experiment, could you try disable sleep mode in your FW to see if that changes the behavior? I.e., remove the call to sd_app_evt_wait() from the main loop. 

Note that the chip enters emulated sleep mode when the debug interface is enabled (when you read RTT logs), so that's another difference with being in debug mode..  

 

 

[Florian Zierer]

Hi Vidar,

no this also does not help.

I think I found the reason. Unfortunately the SWDCLK and SWDIO traces cross the antenna matching network on the other side of the PCB on our testboard (not the final one) and this seems to be the problem. If I start JLinkExe with a slow SWD target interface speed like e.g. 10 or 20kHz, I can see some of the RTT logs and can connect via BLE. If I increase the SWD speed, the connection drops. Also if a lot of output is printed, the connection drops.

Thanks for your help.