LAUNCHCC3220MODASF: LAUNCHCC3220MODASF

Neeraj Sallh

Intellectual 685 points

Part Number: LAUNCHCC3220MODASF

Hello,

I was trying usage of the encryption functions/APIs like:

CryptoCC32XX_init, CryptoCC32XX_open, CryptoCC32XX_encrypt, CryptoCC32XX_decrypt

for AES encryption.

At first CryptoCC32XX_encrypt/decrypt calls were failing.

On using debug it turned out that there was a loop as follows in the function "CryptoCC32XX_aesProcess" of file "CryptoCC32XX.c".

The value of "CryptoCC32XX_CONTEXT_READY_MAX_COUNTER" is 1000.

/* Wait for the context in flag, the flag will be set in the Interrupt handler. */
    while((!g_bAESReadyFlag) && (count > 0))
    {
        count --;
    }
    if (count == 0)
    {
        return CryptoCC32XX_STATUS_ERROR;
    }

The context interrupt wasn't raised within these 1000 iterations and the function therefore returned failure.

We decided to try making this loop an infinite loop (by commenting out "count --" statement).

However the Tera term had somehow become unresponsive.

We had to reboot our PC.

After this reboot, the change of loop to infinite loop gave us a success in encrypt.

Later on I wanted to see if instead of an infinite loop we could have a value of "count" that would have the interrupt getting detected and therefore make encrypt successful. I tried 100000 and 10000 loops. The things worked. Then even at the value of 1000 the context was obtained i.e. encrypt was successful.

Here are my questions:

Could the PC reboot have somehow solved the problem? That is, no change was necessary in the above mentioned loop, it was just misbehaving because CCS and/or PC needed a restart?
What is the importance of this loop? Why are we waiting for context to be available, what is this AES context?
What/who/when makes available this context? What does encrypt function need it for?
What are the pros/cons of having this loop as a limited one vs. an infinite one?
This loop is sort of introducing unpredictability if I want to use it for sending encrypted data. Because if this loop fails, the encrypt fails, and this failure can happen any time. Transmission of unencrypted data may happen. How do I tackle this unpredictability?

NOTE:

I did observe the following too about this loop:

There is a corresponding function "AESCrypt" in the CC3200 "aes" example.

This function has this loop as an infinite loop. Whereas, in CC3220 this loop has a finite number of iterations.

Regards,

Neeraj Sallh

over 7 years ago

0 Michael Reymond over 7 years ago

TI__Mastermind 40965 points

Hi Neeraj,

To answer your questions about the crypto engine:

1. No. Rebooting your PC/restarting CCS will not affect the CC3220. You most likely power cycled the CC3220 as part of the reboot, which is something that definitely will affect it.
2. The importance of the loop is that it provides a timeout for the crypto functions. This is because the crypto engine can potentially be busy. The network processor (NWP) uses the same crypto engine as the apps processor, and thus sometimes the crypto engine will be busy doing something for the NWP. During this time, it is not available for use by the apps processor.
3. The crypto engine will set an interrupt saying it's ready, which is when the NWP is not using it. Thus, you need to check whether or not the crypto engine is ready for use by the apps processor.
4. If you have an infinite loop, you can theoretically be stuck forever waiting for the crypto engine to become ready for the apps processor. Having a fixed-duration timeout loop will prevent that from occurring.
5. When the loop fails, you'll get back CryptoCC32XX_STATUS_ERROR. At that point, your application will have to try again until it gets CryptoCC32XX_STATUS_SUCCESS.

Regards,
Michael

0 Neeraj Sallh over 7 years ago in reply to Michael Reymond

Intellectual 685 points

Thanks for the detailed reply Michael.

Now I am concerned about the "stuck forever" problem captured in point 4 above.

Is "stuck forever" really possible?
One of the reasons of NWP using crypto engine can be encryption used over a secure AP/STA Wi-Fi connection.
If this is the case then the NWP should free the crypto between every two packet transmissions. No?
Which means that "stuck forever" won't happen. Just that we may need to check a couple of times for the crypto engine to become free for our use.

So is there a possibility of NWP hogging crypto engine indefinitely?
Can the NWP really hog the crypto engine indefinitely or for unpredictably (sometimes say 10,000 loops are sufficient and at other time say 1000,000 or even 10,000,000 loops are required before it becomes free)?

In case the above unpredictability is possible, then:
1. What care should I take to ensure that such a scenario does not arise in first place? I mean, some guidelines for coding APP
MCU/NWP related things such that neither the APP MCU nor the NWP hogs crypto for long unpredictable times?
2. Some guidelines to make this hogging predictable and deterministic?
Can NWP be given a reset?

0 Michael Reymond over 7 years ago in reply to Neeraj Sallh

TI__Mastermind 40965 points

Hi Neeraj,

Practically speaking, the NWP should not be using the crypto engine to the point where it blocks the apps processor forever. Just like the apps MCU, the NWP will need to use crypto functions, but for chunks of data and not for indefinite streams. Thus, you just need to write your application such that it needs to catch the CryptoCC32XX_STATUS_ERROR failure and retry.

You could tweak the loop condition within the CryptoCC32XX.c file to increase the timeout and make it less likely encounter the failure. You can't alter the behavior of the NWP to make it more predictable though. That being said, I feel that since you have to write your application code to handle the possibility of failure you might as well keep it at 1000.

Regards,
Michael

Wi-Fi

Wi-Fi forum

LAUNCHCC3220MODASF: LAUNCHCC3220MODASF