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!

[bjorn-spockeli]

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?

[will]

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.

[bjorn-spockeli]

@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).