This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 HFXO and HFCLKSTARTED event

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.

  • Sorry for the late response, the project was set aside for a couple days.

    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.

    In fact I was referring to the reference circuitry that can be found in the nRF52840 official datasheet, not the development kit schematics. I note your suggestion however.

    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?

    Your question got me thinking, so I checked back the code and flashed it. The custom code does nothing fancy. The only thing it does to GPIOs is set them as inputs to reduce leakage current.

    However, I did notice a new behavior I did not experienced before. During my initial tests, I was debugging our custom code with always more than one breakpoint in the code: hitting the breakpoint and then resuming would not make the code work. Now this time, it worked with no breakpoint enabled at all!

    In fact, as soon as I attach the debugger in Segger Embedded Studio, the advertising starts to work! When I detach the debugger, it stops to work. Note than I am not referring to connecting the SWD ribbon cable, but attaching/detaching the debugger from Segger. I would like to have your thoughts about this.

    EDIT: I am using the nRF52840-DK development kit to flash our custom boards through the 10-pin connector P19. SB47 is untouched (open). We power our boards with a 3V bench power supply. I confirm that when "the advertisement works", it comes from our boards and not the nRF52840 SoC on the development kit itself (matching MAC addresses).

    Thanks,

    Nicolas

  • Hi Nicolas

    mrjiffy6 said:
    In fact I was referring to the reference circuitry that can be found in the nRF52840 official datasheet, not the development kit schematics. I note your suggestion however.

     What official datasheet did you look at? I've checked our hardware files as well as the product specification, but they all include C16 (47nF) in the DEC4_6 net of the schematics.

    Did you get a chance to check for any deviances in the hardware? Our leading suspicion is still that there is a shorted or Not Connected pin somewhere that causes this issue in the faulty board.

    The fact that it works in debug mode, but not in "release" mode could point towards the reset pin being shorted (The reset pin won't reset the board in debug mode). Your test setup seems fine. Could you also upload your sdk_config.h file, so I could check that your clock configurations, etc. are correct as well?

    Best regards,

    Simon

  • What official datasheet did you look at?

    I was looking at the v1.0 datasheet of the nRF52840. I just noticed that there is a v1.1 version available from your website, i'll update it.

    The reset pin won't reset the board in debug mode

    That's something I was not aware of! Unfortunately, I probed the reset pin (through the programming connector) without any programmer connected and the reset pin is high, so the reset pin is not shorted and therefore the chip is not stuck in reset state.

    I attached the sdk_config.h file as you requested.

    5618.sdk_config.h

    At this point I guess the only thing left to do is reflow the chip and look for potential solder bridges. I'll do that and keep this thread updated about the results.

  • I reflowed the chip and it now works. When reworking, I noticed that the surface tension was really strong, so strong that the chip could not be removed with tweezers. I had to use a vacuum pickup to remove it. I noticed there was too much of solder to my liking on the exposed pad, so I removed the excess solder, reflowed the chip and it fixed the problem. I confirm HFXO crystal now works and advertisements works as well with our custom code.

    Even though we took care when designing the solder paste opening to limit the quantity of paste application, our assembly line is still done by hand and I guess too much paste was applied on the exposed pad of this board. I suppose the excess paste created voids that made bad contacts with some of the other pins. I cannot confirm this though and it is only a hypothesis.

    Anyway, thank you Simon for your support. Cheers!

    Nicolas

  • Glad you were able to figure it out Nicolas. Nice work!

Related