Radio test doesn't work when we use NFC (Base freq is not 2.4GHZ)

[ThierryQ]

Hi,

We need to pass the radio certification and in order to simplify the setup we created an application to setup BLE TX/RX/CC/MC from an NFC command but we meet a strange issue.

When we use the NFC to call radio_tx_carrier(channel 0), the labs claim that the base frequency is not 2.4 GHZ but 2.3 something ....

When we invoke radio_tx_carrier directly from the main() (Without NFC communication) everything is working properly.

So the NFC seems having an impact on the radio test but we currently have no way to debug it without specific equipments.

So, I wondoring if you already met this issue or if you are aware about this symptom. If you need I can provide the source code to reproduce this issue but you can easily reproduce it with below behavior:

In NFC callback, when I receive event "HAL_NFC_EVENT_DATA_RECEIVED", I post a message in the scheduler. Then, from the main context I invoke:

radio_tx_carrier(RADIO_TXPOWER_TXPOWER_0dBm, RADIO_MODE_MODE_Nrf_1Mbit, 0);

(radio_test.c is the original file provided by nordic).

Thank you for your support,

Regards,

Thierry.

[AmbystomaLabs]

Based on the info you have provided, the only way for this to happen is that you have inadvertently turned off or not started the external hfxo in your code modifications to provide NFC communications for the radio test app.

The internal HFXO cannot be used as the frequency reference during radio operations.

Also I should point out that since you specify your intent is BLE communications you should be running in BLE mode not Nordic proprietary as noted in your call on radio_tx_carrier. And, the first BLE channel is 02 not 00.

[ThierryQ]

Hello,

Thank you for your reply.

I got your point and I maybe found the problem according to your hint.

In fact I merged the radio_test application with nfc part and I think the problem come from the way hfxo is initialized and used.

According to radio test, the HFXO is initialized like this:

NRF_CLOCK->EVENTS_HFCLKSTARTED  = 0;
NRF_CLOCK->TASKS_HFCLKSTART     = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
{
    // Do nothing.
} 

In the hal_nfc_t2t I can find such kind of code:

nrf_drv_clock_hfclk_request(&m_clock_handler_item);
...
nrf_drv_clock_hfclk_release();

I'm wondering if mixing both approach in my code is a good idea. I means, If I replace this:

NRF_CLOCK->EVENTS_HFCLKSTARTED  = 0;
NRF_CLOCK->TASKS_HFCLKSTART     = 1;

By this:

err_code = nrf_drv_clock_init();
if (err_code != NRF_SUCCESS)
	return err_code;

nrf_drv_clock_lfclk_request(NULL);

Do you think it will fix the problem ?

I have no way to test this fix now, since as explained, I don't have any equipment to do it.

Thank you,

Best regards,

Thierry

[AmbystomaLabs]

Without knowing detail on how nrf_drv_clock... routines are implemented it's hard to say that is a good approach. I really don't see any reason to use the clock driver for this type of app. The radio test approach of just writing to the clock registers and waiting for the clock start event to happen is a nice solid way to handle this. I would suggest you use that approach instead.

[ThierryQ]

OK, the fix provided seems working. I checked before the fix: the HFCLCK status was stopped, after the fix the HFCLCK stay running. So, I think everything is properly working now. Thank you for your help.