Is it possible to record HCI logs using nRF52840?

[Michael-1965]

Hi all.

I have written an application using a softdevice and I want to analyse an interesing behavior I don't understand at the moment.
So I want to record a trace/log of the used HCI commands to see what's going on on deeper levels.

Is this possible?

Thanks in advance
Cheers Michael

[Vidar Berg]

Hi,

The Softdevice does not expose a HCI interface to the app. But if you have an extra Nordic DK laying around I would instead recommend you try capturing a sniffer trace with our nRF Sniffer.

Cheers,

Vidar

[Michael-1965]

Hi Vidar.

Thanks for the feedback. I already have a bluetooth sniffer, but this does not help in my case.

My problem is, I wonder if the Nordic chip is able to resolve a received random resolvable address fast enough (pairing has previously done) just after reception of the advertisement to fire the connection-request just after this advertisement.

I have seen some inconsistent results on my system.

Cheers Michael

[Vidar Berg]

Ok, so I assume the symptom is that connect requests are being ignored then. But maybe monitoring of the AAR events could help give a better picture of what's happening. Here's some code I wrote a while back  for this exact purpose:

void SWI0_EGU0_IRQHandler(void)
{
    uint8_t * p_irk = (uint8_t *) NRF_AAR->IRKPTR;
    uint8_t * p_addr = (uint8_t *) (NRF_AAR->ADDRPTR + 3); /* ignore the S0, L, and S1 field */
    
    /* Clear event register */
    NRF_EGU0->EVENTS_TRIGGERED[0] = 0;

    NRF_LOG_INFO("AAR not resolved event triggered"); 

    /* Print the current IRK list used by the AAR */
    for(int i=0; i < NRF_AAR->NIRK; i++)
    {
        NRF_LOG_INFO("IRK # %d", i);
        NRF_LOG_HEXDUMP_INFO(p_irk, BLE_GAP_SEC_KEY_LEN);
        p_irk += BLE_GAP_SEC_KEY_LEN;
       
    }
    NRF_LOG_INFO("Input address:")
    NRF_LOG_HEXDUMP_INFO(p_addr, BLE_GAP_ADDR_LEN);
}

/* Trigger SW interrupt when AAR not resolved event is raised */
void aar_event_init()
{
    NVIC_SetPriority(SWI0_EGU0_IRQn, 6);
    NVIC_EnableIRQ(SWI0_EGU0_IRQn);

    NRF_EGU0->INTENSET = EGU_INTEN_TRIGGERED0_Msk;

    NRF_PPI->CH[0].EEP = (uint32_t) &NRF_AAR->EVENTS_NOTRESOLVED;
    NRF_PPI->CH[0].TEP = (uint32_t) &NRF_EGU0->TASKS_TRIGGER[0];
    
    NRF_PPI->CHENSET = PPI_CHENSET_CH0_Msk;
}

[Michael-1965]

Thanks, I will have a look on this.

[Michael-1965]

HI Vidar.

I have used your code to monitor the not resolved advertised addresses.
My address to resolve is not listed in this list.
This means the address has been resolved immediately after the first appearance? Right?

But it is still possible that the connection-request it not sent immediately after resolving the address after the same advertisement.
How long does it take to resolve a random address? Maybe it takes too long, so the next advertisement has to be used for the connection request or the connect request can't be sent just after resolving the address due to other limitations.

Cheers Michael