BT_HCI_LE_ADV_EVT_TYPE_DATA_STATUS_RX_FAILED

[Hayden Ball]

While using PAWR, we see the above HCI event.

The subevent data is then empty.

Do you have any advice for debugging this?

There doesn't appear to be any helpful logging leading up to this event.

[Hung Bui]

Hi Hayden, 
To make it easier to reproduce and report here could you please clarify: 

- The problem is only observed on nRF Connect SDK v3.0.0 and not on v2.9.0 with the same firmware. 

- The problem can be reproduced with the default periodic_adv_rsp/periodic_adv sample. If it does, please let us know how to test and what wrong. 

- Could you please point me to where in the sniffer trace I should look at. 

[Hayden Ball]

> The problem is only observed on nRF Connect SDK v3.0.0 and not on v2.9.0 with the same firmware

Correct

 

> The problem can be reproduced with the default periodic_adv_rsp/periodic_adv sample

The problem can be reproduced with the default periodic_adv_rsp sample when programmed to the 5340 net core on our hardware, and also on 5340dk hardware when supplied 1.8v.

The app core in both instances was erased.

> Could you please point me to where in the sniffer trace I should look at

The trace should show periodic adverts with 5 IND events and 0 responses.

You will note that this is not the case for either the "pd_hardware.pcapng" capture above, or the "5340dk-1800mv.pcapng" capture above.

I include screenshots below with the "good" (regular 3.3v) 5340dk on the left, and the "bad" pd_hardware on the right:

 

[Hung Bui]

Hi Hayden, 

Did you do any modification to the periodic_adv_rsp sample ? In my test here when I build for nrf5340dk/nrf5340/cpunet , I couldn't make it work. There were no log nor the advertising. Could you send me your project for testing ? 

I tried to modify the example so that it will build the controller on the netcore (ipc_radio) and the main application (host) on the app core and it seems to work. 

I tried with 1.8V and it seems also work. 
Could you please try to test with the attached project ? I don't think the sample is not tested to run on the netcore of nRF53. 

0743.periodic_adv_rsp.zip

[Hayden Ball]

Hi Hung,

No, I made no changes to the `periodic_adv_rsp` - it ran fine when I built for `nrf5340dk/nrf5340/cpunet`.

Like you, I found there was no easy way to run the sample from the app core.

I am away from my desk at the moment, but will run the attached project when I am able. However, this doesn't help me particularly as I need to run periodic advertising from the net core.

[Hayden Ball]

Hung Bui were you able to reproduce this using the devkit netcore?

[Hung Bui]

Hi Hayden, 
I haven't tried to continue the test with running it on the netcore as I mentioned (with a typo) that the sample was not made to run on the netcore, even though I can't find a reason why it shouldn't run on a netcore. 
Please try testing with the sample I sent and try to check why it doesn't run the same way on the netcore. 

[Hayden Ball]

The sample you provided will not run on the net core alone as it requires both cores.

Could you provide a sample that runs only on the net core, like the one I provided, so we can debug this further?

[Hung Bui]

Hi Hayden, 
I now can run the sample on the netcore but I don't see a problem when running the board at 1.8V.

I haven't tried to verify with the sniffer but should I see anything in the log both on the advertiser and scanner ? 

Could you show the log ? 

Which firmware did you flash on the app core ? I had to flash the empty_app _core to be able to make it work. 

[Hayden Ball]

Thank you Hung Bui 

There were no log messages on either side, no.

On the scanner side, you should see `response_cb` called with a NULL buffer. If you step higher up the call stack in this case, you'll find the response data_status field is set to BT_HCI_LE_ADV_EVT_TYPE_DATA_STATUS_RX_FAILED

(see https://github.com/nrfconnect/sdk-zephyr/blob/77f865b8f8d0cb3d19002bfe713e9dd46e6f71b7/subsys/bluetooth/host/adv.c#L2187)

This is much easier to see with a sniffer, though, noting that the nRF52DK sniffer isn't suitable.

Edit to add:

The scanner should print "Response: subevent %d, slot %d" at a regular interval if everything is working properly.

If it isn't doing that, this is evidence of the failure.

[Hung Bui]

Hi Hayden, 
I have them running for a few hours but I don't see any strange in the log. The Scanner keep continue showing the normal log. 

Subevent data set 141
                                                         
Subevent data set 144
                                                         
Response: subevent 0, slot 0
                                                  
    0xFF: 59008C
                                                              
Subevent data set 146
                                                         
Subevent data set 149
                                                         
Response: subevent 0, slot 0
                                                  
    0xFF: 590091

The question is how often do you observe this and I assume it would continue to run normally after the issue, correct ? 
Can interference cause the problem ? For example if the scanner trying to send a response but the packet get corrupted ? 

[Hayden Ball]

Interference is possible, but I did not observe this issue on the previous nRF Connect SDK (version v2.9.1).

Please could you confirm that you also do not see missing responses on v2.9.1, while you are observing missing responses on v3.0.0?

[Hung Bui]

Hi Hayden, 
I am still struggling to observe the missing response on v3.0.0. 
Could you let me now how often do you see it when testing ? 

Please make sure the supply current is lowest 1.8V and not lower. If you move the supply slightly higher, for example at 1.9V do you see the problem ?