Place nRF52840-QIAA-D0 in custom board

[Doroana]

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

[Doroana]

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?

[Håkon Alseth]

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

[Doroana]

Hi,

We had already cut the trace from VBUS to +3.3V. Yet, the radio did not work, or at the least no advertisement was sensed.

I refer to the datasheet that the configuration 6 (which has no USB) grounds VUSB.

Should I ground it or leave it floating?

Rejecting USB, I have followed configuration 6 very closely for a board revision.

The firmware code we have made does run on the development kit, and the advertisement is sensed with NRF Connect. That makes me think that we are dealing with RF power supply, probably through misconfiguration, since there is VUSB on the development kit.

We just want to make sure that the hardware issues are over before concentrating on software, and that there is a way to make the radio work without the need to supply 5V.

Thanks for your help.

[Håkon Alseth]

Hi,

 

Did you run the snippet wrt. the clock sources successfully on your board?

The softdevice does not block if the external HFCLK cannot be started properly, so then all your logs and so-forth will still run and be printed, but the radio will not work, as its not clocked from a accurate enough source.

 

Kind regards,

Håkon

[Doroana]

Hi,

At the start of main() we run the following snippet:

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

/* Use external LF CLK */
NRF_CLOCK->LFCLKSRC = 0;
NRF_CLOCK->TASKS_LFCLKSTART=1;

while(NRF_CLOCK->EVENTS_LFCLKSTARTED == 0); NRF_POWER->DCDCEN0 = 0x00;
 

NRF_POWER->DCDCEN = 0x00;

//NRF_UICR->EXTSUPPLY = 0x00;

The clock inits are passed both on the Devkit and on our board.

We have tried also to make sure DCDEN and DCDEN0 were disabled, but the result is the same. GPIO and PWM and SAADC work on both boards as expected.

The only difference is that the radio only works on the devkit, with the same firmware (the same .hex file).

King Regards

[Håkon Alseth]

Hi,

 

Could you try another bluetooth example, to see if that works?

If not, can you check there's nothing shorted in the antenna path?

Do you have more than one prototype that exhibits this behavior?

 

Kind regards,

Håkon

 

[francisco.colaco]

Two prototypes exhibit identical behaviour.  Nothing is shorted at the antenna path.

[Håkon Alseth]

francisco.colaco said:

Two prototypes exhibit identical behaviour.  Nothing is shorted at the antenna path.

Q1: How about other bluetooth examples? Do they also behave like this?

Q2: Do you have access to a spectrum analyzer? If yes; You can check if the device outputs on the correct frequency.

It might be that the crystal is loaded incorrectly, which will drag the frequency, resulting in the radio not operating on the exact frequency that you want it to.

Q3: Do you have the details of the crystal that you have mounted? I'm particularly interested in the "CL" value of your mounted HF crystal.

 

Kind regards,

Håkon