How should the nRF 5340 CCM peripheral's MODE.DATARATE field be set when using the peripheral in asynchronous mode (i.e. not encrypt/decrypt-on-the-fly)?

Hello,

I a working on a project that uses the nRF5340 CCM peripheral (Network core) in an asynchronous mode. That is, I encrypt PDUs prior to scheduling them for transmission on the radio and I decrypt PDUs after having successfully received them from the radio. I'm not using the on-the-fly mechanism that operates synchronously with the radio because I don't have enough space in my proprietary protocol to allow the CCM to get configured between radio TX/RX operations.

I use the radio at 2 different data rates (1 Mbps and 2Mbps) depending on the state of the link. My question is what is the effect of the CCM's MODE.DATARATE field when using the CCM in an asynchronous mode? I was initially just leaving the DATARATE field at the default of 1 Mbps because I'm not using the synchronous on-the-fly method and I assumed it would have no effect. What I discovered though is that the time it takes to decrypt a PDU when DATARATE = 1Mbps is approximately twice as long as it takes the radios to TX/RX that PDU. As a result the CCM decrypt operations were unable to keep up with the receiving radio when the link is busy. So I tried to change the MODE.DATARATE setting to 2Mbps when I was using the radios in 2Mbps mode. This cut the decryption time roughly in half, but now there is ALWAYS a MIC mismatch on the receiving side when I attempt to decrypt the PDUs.

Am I missing something? Is there a way to configure and use the CCM asynchronously but have it operate at the 2Mbps rate?

Thanks,

Kevin

  • A couple of other observations in case they may shed light on the issue:

    - When I perform an encryption operation with MODE.DATARATE = 2Mbps the duration of the encrypt operation take significantly less time than the 1Mbps case. For example, when I encrypt a 58-byte PDU with MODE.DATARATE = 1Mbps the keystream generation takes 19.5 usec (MAXPKTSIZE = 80) and the encrypt takes 37 usec. When I encrypt the same 58-byte packet with MODE.DATARATE = 2Mbps the keystream generation takes 13 usec and the encrypt takes 232.5 usec.

    - When I encrypt on the sending side with MODE.DATARATE = 1Mbps but attempt to decrypt on the receiving side with MODE.DATARATE = 2Mbps some decrypts are successful and some fail. For example, I encrypt and send a 64-byte PDU followed by a 9-byte PDU (MODE.DATARATE = 1Mbps). On the receiving side I decrypt using MODE.DATARATE = 2Mbps and the 64-byte PDU fails due to a MIC mismatch but the 9-byte PDU is successful. The failed 64-byte decrypt takes 13 usec for keystream generation and 22 usec for the decrypt operation. The successful 9-byte PDU takes 13.5 usec for keystream generation and 128.5 usec for the decrypt operation.

    - Code snippet for initialization of the CCM peripheral:

       NRF_CCM_NS->MAXPACKETSIZE = SHU_MAX_PAYLOAD;   // 80 bytes
       NRF_CCM_NS->HEADERMASK = 0xFF;
       NRF_CCM_NS->SCRATCHPTR = (uint32_t)&ccmScratchArea[0];
       NRF_CCM_NS->SHORTS = CCM_SHORTS_ENDKSGEN_CRYPT_Msk;
       NRF_CCM_NS->INTENSET = CCM_INTENSET_ENDCRYPT_Msk | CCM_INTENSET_ERROR_Msk;
       NRF_CCM_NS->ENABLE = CCM_ENABLE_ENABLE_Enabled;
  • Hi!

    Kevin Doss said:
    For example, when I encrypt a 58-byte PDU with MODE.DATARATE = 1Mbps the keystream generation takes 19.5 usec (MAXPKTSIZE = 80) and the encrypt takes 37 usec. When I encrypt the same 58-byte packet with MODE.DATARATE = 2Mbps the keystream generation takes 13 usec and the encrypt takes 232.5 usec.

    1) Is this a typo, or does encrypt actually take longer time with MODE.DATARATE = 2Mbps ?

    2) How big is your scratch area?

    3) Are you using MODE.LENGTH = Default or MODE.LENGTH = Extended ?

  • 1) Sorry the typo is that I should have said "the encrypt operation takes significantly MORE time" not less time.

    2) The scratch area is 96 bytes (16 + MAXPACKETSIZE)

    3) MODE.LENGTH = Extended

Related