Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

bjorn-spockeli — Mon, 11 Jul 2016 10:39:44 GMT

@wes3(Will): Sorry for not replying in a while. I guess you should just ignore the data pointed to by OUTPTR when you do not get the ENDCRYPT event( i.e. an empty PDU).

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

will — Tue, 10 May 2016 16:48:25 GMT

Hey Bjorn:

No worries about the reply...

Regarding EVENTS_END and MICSTATUS: there is no issue there. I was having other problems that made me think this was an issue but I was incorrect.

Regarding empty pdu's: I am not sure if "modified" is the correct term. Basically, when I look at the bytes where INPTR/PACKETPTR points and where OUTPTR points they are not the same. This only occurs for encrypted links and when I am receiving an empty PDU. It does not happen all the time; just occasionally. As I mentioned earlier, the ENDCRYPT event is not set when this occurs which seems suspicious to me (I would expect ENDCRPYT to be set even if we are receiving an empty pdu). I have not had time to delve into this much further but hopefully I will soon.

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

bjorn-spockeli — Fri, 29 Apr 2016 13:14:09 GMT

I apologize for not replying sooner. First issue: Regarding the delay between EVENTS_END and MICSTATUS: Could you describe the setup a bit more in detail, like link speed, packet payload size ?

Second issue: So if I understand correctly, you're seeing empty packets(length field set to zero) being modified by the AES CCM module?

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

will — Sat, 16 Apr 2016 00:06:27 GMT

Hey Bjorn:

Here is the update:

First off, I think the MICSTATUS not being set by the end of the frame (EVENTS_END in the radio) was indeed a red herring. It would be good to get confirmation of this from the engineers though.

So I have encryption/decryption working for the most part. There is still something I am seeing that bothers me and I cannot figure it out (yet). Every now and then I am getting "invalid" received frames. By "invalid" I mean they pass the CRC check and MIC check but they are "garbage"; the are not what the other side is sending. Note that this only seems to happen when the transmitter is sending the empty PDU. What I see on the receiver is that when this happens the ENDCRYPT event is not set. The documentation states that decrpytion/encryption does not occur for empty pdus and that this is just a pass-through. When I look in the buffer where the raw data is stored (data prior to decryption) I see something reasonable. The buffer where the decrypted data is stored does not contain the same data however; it is garbage. I am working around this now by simply dropping every received frame where I dont see the ENDCRYPT event.

If you folks have any clues/ideas on this one I would love to hear them. Again, this is the nrf52.

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

bjorn-spockeli — Thu, 14 Apr 2016 05:45:02 GMT

Ok, keep me posted :)

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

will — Wed, 13 Apr 2016 17:00:21 GMT

Thanks bjorn. This may be a false alarm actually and could have been related to this one issue I am seeing. I have the encryption/decryption working for the most part with one exception. If I cant figure it out I will post a question.

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

bjorn-spockeli — Wed, 13 Apr 2016 10:41:47 GMT

I have forwarded this to R&D and I'll come back to you with an answer as soon as possible.

RE: Is there a delay between EVENTS_END of radio and MICSTATUS in CCM?

will — Wed, 13 Apr 2016 05:54:28 GMT

This is on the nrf52 btw.