Dear Colleagues,
I could use some help or ideas. I’m working on the link layer encryption of an open source Bluetooth stack. It starts to work! But, now I have the effect, that encryption works with my iPhone as client, but not with nRF Connect desktop.
The main differences that I see in the behavior of those two stacks is, that the iOS stack starts to send a first encrypted PDU right in the next connection even, after receiving encryption was enabled (master sends LL_START_ENC_RSP direct (in the next connection event) after the slave send LL_START_ENC_REQ). Where the nRF Connect stack send some empty PDUs first (which of cause is completely valid behavior).
I further investigated into this and it seems like the CCM peripherals ENDCRYPT event will not trigger in the case that the received PDU is empty. In the interrupt service routine, the READY, ADDRESS, PAYLOAD, END, and DISABLED events of the radio are set (which where cleared when scheduling the connection event). For the CCM peripheral, only the ENDKSGEN is set. The ENDCRYPT is not set and the CCM peripheral did not copied the empty PDU from INPTR to OUTPTR.
When scheduling the connection event the radio peripheral is configured with shortcuts READY_START, END_DISABLE and DISABLED_TXEN. The CCM peripheral is configured without the ENDKSGEN_CRYPT shorts.
Following predefined PPI channels are set (CHEN = 0xb600000):
27: RADIO->EVENTS_END -> TIMER0->TASKS_CAPTURE[2]
25: RADIO->EVENTS_ADDRESS -> CCM->TASKS_CRYPT
24: RADIO->EVENTS_READY -> CCM->TASKS_KSGEN
22: TIMER0->EVENTS_COMPARE[1] -> RADIO->TASKS_DISABLE
21: TIMER0->EVENTS_COMPARE[0] -> RADIO->TASKS_RXEN
it looks like the RADIO->EVENTS_READY triggered the CCM->TASKS_KSGEN task, but that the RADIO->EVENTS_ADDRESS did not triggered the CCM->TASKS_CRYPT.
The used hardware is a nRF52832. Any idea on how to further investigate this? Any pointers?
thanks in advance,
Torsten