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

Question

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.

ThierryQ · Accepted Answer

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