Hello,
I’m sorry for asking again, but I could need some help again. This is a followup to devzone.nordicsemi.com/.../missing-endcrypt-event.
I’ve managed to receive and send encrypted link layer PDUs now (by manually triggering the KSGEN task). I’ve configured a nrf51832s GPIOTE and PPI, such that I can see the radio’s ADDRESS, END, READY, and DISABLED events and the CCM’s ENDKSGEN and ENDCRYPT event at external IO pins with a logic analyzer. In the first connection event _after_ encryption has been acknowledged in both directions, after the slave (that’s what I’m working on) has send a correctly encrypted LL_START_ENC_RSP (confirmed by sniffing the connection), I see a situation that I do not understand.
The connection event starts by the server sending an empty PDU. I can see the event on my logic analyzer (40µs between ADDRESS and END event; 2 bytes header plus 3 bytes CRC) and with the sniffer. I set a breakpoint at this situation (in the RADIO ISR at the DISABLED event) and I see, that the CRC stored in the NRF_RADIO->RXCRC register is exactly the one, that I see in the sniffer. Both, ENDKSGEN and ENDCRYPT events are set in the NRF_CCM peripheral. Also, READY, ADDRESS, PAYLOAD, END, CRCOK, and DISABLED events are set in the radio peripheral. So far, so good.
The NRF_RADIO->PACKETPTR and NRF_CCM->INPTR are pointing to a statically allocated buffer, large enough to take the largest possible PDU. NRF_CCM->OUTPTR points to valid, dynamically allocated memory. By experimenting with the content of the buffer, NRF_CCM->INPTR is pointing to, I came to the conclusion, that the NRF_CCM is decrypting the content of the buffer, before the RADIO is writing the received data to that buffer.
From experimenting with the content of the statically allocated buffer, I came to the conclusion, that the CCM is decrypting the buffer, before the radio is storing them in the buffer (which might even cause memory overruns in the dynamically allocated memory, when the „random“ content of the statically allocated buffer contains large numbers at the second ([1]) position (which would be the size header field).
All the above pointers are set, before key stream generation is started and before the radio is turned on (delayed by TIMER0). Key stream generation is started manually, when scheduling the connection event and has been finished ways before the master sends his empty PDU. To make sure, that nothings changes the PPI configuration from the time, the connection event was scheduled up to the connection event, I’ve stored the NRF_RADIO->SHORT, the NRF_CCM->SHORTS and the PPI->CHEN registers into statically allocated variable, to be able to check them, when the debugger hits the break point.
Nothing changed the PPI configuration. Following channels are set:
NRF_PPI->CHEN = 0x20003f, which results in
Channel 0-5 used for debugging
Channel 27: RADIO->EVENTS_END -> TIMER0->TASKS_CAPTURE[2]
Channel 25: RADIO->EVENTS_ADDRESS -> CCM->TASKS_CRYPT
Channel 22: TIMER0->EVENTS_COMPARE[1] -> RADIO->TASKS_DISABLE
Channel 21: TIMER0->EVENTS_COMPARE[0] -> RADIO->TASKS_RXEN
NRF_RADIO->SHORTS = 0x7, which results in
READY -> START
END -> DISABLE
DISABLED -> TXEN
NRF_CCM->SHORTS = 0
From the PPI connection of the ENDCRYPT event to the GPIOTE, I can see that the ENDCRYPT event happens after the ADDRESS event, so I guess, the ADDREss event triggers the CRYPT task correctly, but somehow, to early. From the documentation (both, for nrf52832 and nrf52840), I read that this PPI configuration should work. Again, the radio is configured for an 8 bit length field.
Before this error situation, there is already the reception of an empty, encrypted PDU. The difference, that I can see between this situation and my error situation, is the distance from the ADDRESS event to the ENDCRYPT event. In the working case, the distance is 22.2µs, while for the not working case (see screenshot), it’s just 14.6µs.
Is there anything I’m doing wrong here? What else could cause the early decryption? Any experiments I should do, to find the mistake?
desperately,
Torsten
