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.

Parents
  • 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

Reply
  • 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

Children
  • 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.

    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.

    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.

    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.

    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.

  • 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

  • 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.

Related