Unexpected address match on nRF5340

[Andrzej Kaczmarek]

Hi,

I use nRF5340DK (0.11.0) as HCI controller and noticed it can randomly (?) accept PDUs with access address other than configured. This basically makes it impossible to qualify since there are test cases that test behavior with invalid access address (e.g. LL/ENC/INI/BI-01-C) and there's apparently no way to check the received access address and verify it in sw. I checked known erratas and cannot see anything related. Also the same issue can be reproduced on both Apache NimBLE and Zephyr controllers. Any ideas whether this is just a configuration issue or hardware problem?

[Edvin]

Hello,

What sort of PDUs are you seeing? 

And when you see this PDUs from random devices, what are you doing? Advertising? Scanning? In a connection?

Also the same issue can be reproduced on both Apache NimBLE and Zephyr controllers.

This makes me suspect that it is not actually a bug, but something that should be expected. 

Best regards,

Edvin

[Andrzej Kaczmarek]

Hi,

Edvin said:

And when you see this PDUs from random devices, what are you doing? Advertising? Scanning? In a connection?

Basically the scenario I was testing (see test case I mentioned in original post) was like this:
- connection established from nRF5340 to peripheral
- on each connection event peripheral replies with a PDUs that have single bit corrupted in access address

In such case nRF5340 shall not receive any PDU during connection due to access address mismatch, yet sometimes there's address match and PDU is received, see below:

/resized-image/__size/940x615/__key/communityserver-discussions-components-files/4/Screenshot-from-2022_2D00_01_2D00_24-16_2D00_21_2D00_32.png

You can see that proper aa is 0x894A08E6 and the one used by peripheral is 0x894A48E6, and for some reason there's EVENT_ADDRESS generated on 2nd PDU and that PDU is received (addr2end is EVENT_ADDRESS to EVENT_END controlled by DPPI). It does only happen sometimes, see below:

/resized-image/__size/1040x242/__key/communityserver-discussions-components-files/4/Screenshot-from-2022_2D00_01_2D00_24-16_2D00_28_2D00_01.png

Tick on rx line means there was EVENT_ADDRESS for rx, the configuration and aa is the same on every single connection event.

Edvin said:

This makes me suspect that it is not actually a bug, but something that should be expected. 

That would be weird since Bluetooth spec is quite clear about aa matching:
"At packet reception, the Access Address shall be checked first. If the Access Address is incorrect, the packet shall be rejected, otherwise the packet shall be considered received."

[Edvin]

Can you please send me the sniffer trace where these screenshots are coming from?

Just out of curiousity: How did you replicate this? Did you write the source code for the device with the mismatching access address? (not important if you can't share. Just curious). 

Best regards,

Edvin

[Andrzej Kaczmarek]

I uploaded traces to Ellisys cloud, you can retrieve them directly from app: {05d5f792-919c-4e15-884f-76682f13ea31}. I also included trace for nRF52 which does not have described issue.

The device with the mismatching address is Harmony LE Tester executing LL/ENC/INI/BV-01-C test case.

Best regards,
Andrzej

[Edvin]

Thank you Andrzej,

I downloaded the traces, but I struggle to find an example where this happens in the nRF53_LL_ENC_INI_BI_01.btt. Can you please point to a timestamp where this occurs?

Also, I struggle to find the "Received Access Address" field. I only find the "Access address", which seems to always match, as far as I can tell.

Best regards,

Edvin

[Andrzej Kaczmarek]

You can find all occurrences on in "Timing" view, they are marked by pulse on "rx" line (except for 1st one in each connection since that is for received advertising packet). Few timestamps:

62.221 480 625
71.517 923 625
75.416 533 625
75.616 387 500

But there are many more there and starting from 231.963 199 000 nRF53 kept receiving every single PDU with invalid aa.

The "Received Access Address" field is visible once you select "All fields" in "Details" view.

Best regards,
Andrzej

[Edvin]

Thank you for the detailed description, Andrzej.

Looking at the instance around 62 seconds:

I assume the nRF is the master/central in this case, right?

I see that in the packet with timestamp 62.021278875 (highlighted in above screenshot), the master/central sends a packet, and the slave/peripheral replies with an incorrect  Access Address (AA) ending in 0x14 instead of 0x54.

However, this packet is not accepted as a valid packet by the central, as you can see by the SN and NESN (Serial Number and Next Expected Serial Number added as separate columns), which are both 0, since this doesn't change in the next packet from the central, it means that it didn't pick up the previous packet. This is the central telling the peripheral to retransmit the previous packet. Do you agree with this?

I am not saying you are wrong, but if this in fact is a bug, I need to understand what erronous behavior the nRF is doing  

Best regards,

Edvin