nRF52840 HFXO and HFCLKSTARTED event

[mrjiffy6]

Hello everyone,

I am having some trouble starting the HFXO crystal manually before using the RADIO to send raw advertisements: the HFCLKSTARTED event never raises. The code used to start the HFXO is:

NRF_CLOCK->TASKS_HFCLKSTART = 1;

while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) {}
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;

But the execution stalls in the while loop because the event HFCLKSTARTED is never raised. After reading a few posts with people who had similar issues, here are the things I tried so far:

- Tried to remove the while loop to see if the radio would work: it does not

- Changed crystal and its capacitors. The crystal used is 8Y-32.000MAAV-T and the capacitors are 12pF NP0 2%. We followed the Nordic layout guidelines.

- Probed the crystal pins: the scope gives correct waveforms so it is defenetly not a soldering problem of the nRF52840.

- Ensured that the 1uF capacitor at DEC4 pin is soldered properly

- Tried our code on a different board: the code works flawlessly (with the while loop)

- Tried a Nordic example (ble_app_beacon for instance) with SoftDevice: the advertisements are sent correctly.

The last point is what baffles me the most. According to this post, it is mentionned that the Softdevice will always start the HFXO before a RADIO event, which totally makes sense since it is mandatory for the RADIO to work. However, if the softdevice is actually able to start the HFXO to send advertisements, why it doesn't work when using our code (without softdevice)?

Our code is not the cause of the problem because it was tested successfully on a different board. I am tempted to say that the board is not the problem also because it works when using a Nordic example.

I must be missing something. Any help would be greatly appreciated.

[Simonr]

Hi

In our examples, the HFXO is started manually by writing the function like this. Please give it a go like this:

/* Start 16 MHz crystal oscillator */
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART    = 1;

    /* Wait for the external oscillator to start up */
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
    {
        // Do nothing.
    }

You could also try debugging, and stepping through the code to see what happens in TASKS_HFCLKSTART.

- Tried our code on a different board: the code works flawlessly (with the while loop)

 What board were you initially testing on? Was this a custom board? And is the different board a dev. kit or another custom one? I'd like to take a look at your schematics, just to make sure there are no hardware issues we're missing here. If you don't want to share the schematics publicly, just say the word, and I'll set this case to Private mode so that no one except yourself and Nordic engineers will be able to see this case.

Best regards,

Simon

[mrjiffy6]

Sorry I forgot to give that information. The boards I am referring to are indeed custom boards. The two boards mentionned in my original posts are the same design (let's call them board A and B). Our code that does not use the softdevice works on board A but not on board B. However, if I use an example from nordic that uses softdevice (ble_app_beacon for instance) and flash it on board B, the advertisement works. That tells me it is probably not an hardware issue (unless I am missing something) because the nordic example is actually able to start HFXO to perform the advertisements. Both boards are populated with exact same components and i've verified the soldering and the values of the critical components (C3, Y1, C4 and C5 for instance).

I don't mind to post the schematic because it is pretty much the reference design provided by Nordic, here it is:

The source code you provided in your answer is pretty much the same thing we are using in ours. What do you mean exactly by "stepping through the code to see what happens in TASKS_HFCLKSTART"? The code starting HFCLK is pretty much writing to a register and I can't really step deeper into that. Looking at the CLOCK register values while stuck in the while loop does not reveal much as well: HFCLK is running on RC and HFCLKSTART task has been triggered.

[Simonr]

Hi

Looking at your schematics I can see that you're missing a capacitor in the DEC4_6 net. There should be an additional 47nF capacitor here. It should be fine soldering it to C9's footprint. Are you using the same HFCLK as our reference layout BOM describes on both boards A and B? If not, please upload the datasheet of the HFCLK you're using so I can take a look at it. I don't see why two identical boards work differently with the same code flashed to them if there are no hardware issues in one of them. It seems very strange that board B will only work with SoftDevice, while board A has no issues what so ever... You're not able to output any error codes what so ever, correct?

Have you configured the LFCLK to use the internal RC oscillator instead of the external LFCLK as well? Please check that the following defines in your sdk_config.h file are set correctly:

• NRFX_CLOCK_CONFIG_LF_SRC 0

• CLOCK_CONFIG_LF_SRC 0

• CLOCK_CONFIG_LF_CAL_ENABLED to 1

Best regards,

Simon

[mrjiffy6]

Simonr said:

Looking at your schematics I can see that you're missing a capacitor in the DEC4_6 net. There should be an additional 47nF capacitor here. It should be fine soldering it to C9's footprint.

C9 is marked as "not mounted" since according to the nRF52840 datasheet v1.0, the capacitor at net DEC4_6 in reference layout is marked as "not mounted" as well.

Simonr said:

Are you using the same HFCLK as our reference layout BOM describes on both boards A and B? If not, please upload the datasheet of the HFCLK you're using so I can take a look at it.

The crystal used has the same specifications than those stated in the reference circuitry in the datasheet (32MHz, ±30ppm tolerance, 8 pF). The brand/model is TXC 8Y-32.000MAAV-T and its datasheet can be found here.

Simonr said:

I don't see why two identical boards work differently with the same code flashed to them if there are no hardware issues in one of them. It seems very strange that board B will only work with SoftDevice, while board A has no issues what so ever...

I know since it goes against common sense... hence my post here in devzone. The SoftDevice must be doing something that makes it works, but I just can't imagine what. Would it be possible that the SoftDevice sends the advertisement anyway using only the RC HFCLK instead of the crystal due to start timeout perhaps? That seems unlikely to me since according to BLE Core Specifications timing are really important... I'd be curious to try to remove the HF crystal from board B and test the ble_app_beacon example again to see if would still work. Nevertheless, that would not explain why running the crystal works with board A but not for board B.

Simonr said:

You're not able to output any error codes what so ever, correct?

Correct. Debugging the code does not produce any error code / execute error handlers whatsoever. It just stalls in the while loop forever waiting for EVENTS_HFCLKSTARTED which never comes.

Simonr said:

Have you configured the LFCLK to use the internal RC oscillator instead of the external LFCLK as well?

Yes. The defines in the sdk_config.h are the same as yours expect for CLOCK_CONFIG_LF_CAL_ENABLED which is not even present at all in the sdk_config.h. We are using SDK version 15.2.0_9412b96.

[Simonr]

mrjiffy6 said:

C9 is marked as "not mounted" since according to the nRF52840 datasheet v1.0, the capacitor at net DEC4_6 in reference layout is marked as "not mounted" as well.

 Yes, but you're missing one in the DEC4_6 net that should be mounted (C16 in the ref. design), and instead of redesigning your entire board layout it should be fine placing it on the footprint of C9. (This should not be enough to make the board malfunction, but you could try including it for good measure.

I've talked to my colleagues about this issue, and it's most likely that a component is not mounted correctly, or that a pin is shorted/N.C. (The nRF52840 can be difficult to solder properly, so I'd check for this first). If you're uploading two identical boards with the same code, there shouldn't be anything in the software that should make them behave differently. Does the application with and without the SoftDevice do the same thing, or do one activate a peripheral or set a pin high, that the other doesn't?

Best regards,

Simon