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

[will]

Hello:

It appears (although I am not 100% certain) that there is a small delay (< 10 usecs) between EVENTS_END in the radio and MICSTATUS in the CCM. I believe I have read the MICSTATUS as 0 but then noticed shortly after that the bit was set to 1.

Is there any delay between radio EVENTS_END and the setting of the MICSTATUS register in the CCM peripheral? Does Tecb (6 usecs) from the ECB spec apply here?

Thanks!

[will]

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.