CCM->EVENTS_ERROR ( Deprecated ) ?

[Hiihtaja]

Hello !

I can see this error event is deprecated.

What other registers can be used if any error occurs during on-fly encryption/decryption process ?

In case of RX , MIC error is available only.

Regards,

Eugene

[Einar Thorsrud]

Hi,

To check for MIC errors you have the MICSTATUS register, which holds the result of the MIC change from the previous decryption operation. Note that the EVENTS_ERROR exists even if it is marked as deprecated (and is also present even in the newer nRF5340).

[Hiihtaja]

Hi !

Basically encryption process expected to be error free always ?

To what event EVENTS_ERROR will be replaces ?

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

Hiihtaja said:

Basically encryption process expected to be error free always ?

Yes, that is the case. It should not normally fail, and if it does for some odd reason (like a bug in your firmware causing it to manipulate the source buffer while the operation is ongoing for instance), there is no way to detect that (other than the ERROR event).

Hiihtaja said:

To what event EVENTS_ERROR will be replaces ?

There is no replacement for it. If you need it, you can use it even if it is marked as deprecated.

[Hiihtaja]

Hi Einar !

Thank you !

In case of encrypt, MIC status for some reason is set to 1. Is this OK ?

Can ICACHE be enabled if on-fly operations are in use , it might effect of source buffer ?

Can NRF_CCM->INPTR and OUTPTR be mapped to the same buffer in memory, or they really should be different ? Even In buffer is no need any more.

What about RFU byte ( S1) ? Looks like  if on-fly mode is enabled, it must be present.

S1LEN and S1INC in PCFN0 should be > 0

Is this so ?

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

Hiihtaja said:

In case of encrypt, MIC status for some reason is set to 1. Is this OK ?

The MIC Status register should only be updated by a decryption operation, where the MIC is checked. Did you have a previously failed decrypt operation failed? In any case, the MIC Status has no relevance for encrypting operations so there is no reason to check it after an encryption operation.

Hiihtaja said:

Can ICACHE be enabled if on-fly operations are in use , it might effect of source buffer ?

I do not see how that can have any consequences for the CCM peripheral, so that should be no problem.

Hiihtaja said:

Can NRF_CCM->INPTR and OUTPTR be mapped to the same buffer in memory, or they really should be different ? Even In buffer is no need any more.

I do not immediately see a reason why INPTR and OUTPTR cannot be identical, and have not found any indication it should be problematic. This is not the primary use case though so it may not have been well tested. Also note that as you asked about on-the-fly encryption, note that the OUTPTR must point to the same location as the PACKETPTR register in the RADIO.

Hiihtaja said:

What about RFU byte ( S1) ? Looks like  if on-fly mode is enabled, it must be present.

S1LEN and S1INC in PCFN0 should be > 0

This depends on the configuration of the RADIO peripheral (PCNF0 is a configuration register in the RADIO) and is not directly related to the CCM (other than that it passes the data on).

[Hiihtaja]

Hi Einar !

in case of encryption MICSTATUS keep 0 value ( failed ) but it is not relevant for encryption.

Basically OUTPTR ( PACKETPTR ) should point to empty/zerroed big enought buffer becouse INPTR point to original buffer.

Is this so ?

 

So byte S1 is not mandatory for support on fly operations. In my case it is not used and I have start to think should I add it becouse it must.

Regards,

Eugene

[Einar Thorsrud]

Hiihtaja said:

Basically OUTPTR ( PACKETPTR ) should point to empty/zerroed big enought buffer becouse INPTR point to original buffer.

Is this so ?

INPTR points to the buffer holding the clear text data that is input data to the encryption operation. OUTPTR points to the output data that will hold the ciphertext. There is no need to  memset this buffer to 0, but it must be big enough to hold the output data including the MIC.

Hiihtaja said:

So byte S1 is not mandatory for support on fly operations. In my case it is not used and I have start to think should I add it becouse it must.

That is application specific. Which packet format do you need on air? You may find this short post interesting.