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

Place nRF52840-QIAA-D0 in custom board

Hi,

We have developed a custom board. We can upload code using nrf52840 sdk-ble stack. We can read NRF_LOGS. However when we test with the ble_app_blinky that works fine with the dev kit, it doesn't do anything in our custom board. We have placed NRF_LOGS in all the functions and we read all the messages. So the code is not blocked in any part. But in the nordic app we can not see the advertising of our custom board.  

We think that we probably did some obvious error but don't know where.

The pdf has our schematic

Series-8-main.pdf

  • Hi,

     

    I would recommend that you start by checking your clock sources, mainly the HF and LF clk.

    You can start them manually like this:

    NRF_CLOCK->TASKS_HFCLKSTART=1;
    while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
    
    /* Use external LF CLK */
    NRF_CLOCK->LFCLKSRC = 1;
    
    NRF_CLOCK->TASKS_LFCLKSTART=1;
    while(NRF_CLOCK->EVENTS_LFCLKSTARTED == 0);

     

    If you hang in one of the above while-loops, it indicates issues starting up the respective clock. You should then check the soldering and see if there's anything out-of-the-ordinary.

     

    Kind regards,

    Håkon

  • Hi,
    We thank your prompt response. We are using the internal RC oscillator, with the normal code. The same block of code (executable) runs and advertises on the Development Kit. As we have enclosed the schematic, are all supply lines and GND lines OK?
    Is there a way to check internally the state of the RF line (diagnostics, for instance)?
    Best regards,
  • Hi,

     

    The configuration that seems to fit your design is this one:

    https://infocenter.nordicsemi.com/topic/ps_nrf52840/ref_circuitry.html?cp=4_0_0_6_2#unique_1634453376

    You seem to be powering VBUS pin with 3.3V, which is too low according to the specifications:

    https://infocenter.nordicsemi.com/topic/ps_nrf52840/recommended_op_conditions.html?cp=4_0_0_7

     

    VBUS should be connected to the USB connector supply voltage.

     

    The values of the matching network is also a bit off (range will suffer), but you should be able to connect to the device over BLE, provided that clock sources and so forth are connected properly.

     

    Doroana said:
    We thank your prompt response. We are using the internal RC oscillator, with the normal code. The same block of code (executable) runs and advertises on the Development Kit.

     Were you able to run the below mentioned code in the start of main, without any issues?

     

    Doroana said:

    As we have enclosed the schematic, are all supply lines and GND lines OK?
    Is there a way to check internally the state of the RF line (diagnostics, for instance)?

    Please create a private ticket if you want the layout to be checked by nordic.

     

    Kind regards,

    Håkon

  • Hi,
    We have noticed that we have not connected the VUSB to +5V.
    So in case VUSB is not connected to +5V, must it be grounded? Is the radio supply dependent on VUSB?
    Can the USB regulator be shut off by software only?
  • Hi,

     

    Doroana said:
    So in case VUSB is not connected to +5V, must it be grounded? Is the radio supply dependent on VUSB?

     It should be left unconnected if the correct voltage is not present. I would recommend that you cut the pcb trace to ensure you are within specification.

    The problem is that you are providing a voltage which is lower than the operating conditions for VBUS, which is not tested for, so I cannot state if this has a large impact for other parts of the system as the behavior is out-of-spec.

    Doroana said:
    Can the USB regulator be shut off by software only?

    The USB is started if you enable the USBD peripheral. How the voltage regulator behaves when starved (ie: voltage is below the specification), is unfortunately not something I can comment on, as its out-of-spec. As mentioned, I would recommend that you cut the PCB trace, so that the VBUS pin is not powered.

     

    Kind regards,

    Håkon

Related