This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: Using SHA2 module

Part Number: CC1310

Hi everyone,

I have a CC1310 Launchpad and I am currently tring to perform hashing on some data for a project i'm working on. I have looked at the documentation of the SHA2.h header file and tried copy pasting the first example into an empty project that i cloned from simplelink. However, when trying to build the porject I get undefined reference errors that point to all the functions, however all the definitions of the objects do not give a problem for the compiler.

Also, I am not sure how to implement the following, as there is no Board.c file:

In order to use the SHA2 APIs, the application is required to provide device-specific SHA2 configuration in the Board.c file. 

Thanks in advance!

Ivan Morales

  • See e2e.ti.com/.../711482 for some code.

    What do you mean by "as there is no Board.c file" ? Please take a look at: dev.ti.com/.../ as one example.
  • Hello Ivan,

    you "cloned from simplelink".
    What does it means?
    You need to import a project example into CCS.
    Could you post your CCS Console window output and
    a view of your Project Explorer when your project is Active?
  • Hello there,

    I have the same issue as the OP. To follow up on the reply...

    Could it be that your references are outdated? The APIs you are referring to seem to have been changed completely.

    I looked in both last 2 releases of SimpleLink CC1310 (v2_10_00_36 & v2_20_00_38) and there is no SHA2 support in driverlib for this device. Furthermore, there is a SHA2 driver implementation but it seems to be a stub for CC1310, with only real support for CC13x2 family cycling back to its version of SHA2 driverlib, see

    #include DeviceFamily_constructPath(driverlib/sha2.h)

    in SHA2CC26X2.c.

    Here is a snippet of SHA2 driver support CC1310 and what I mean by stub as taken from v2_10_00_36 (v2_20_00_38 is identical)

    /*
     *  ======== SHA2_OperationOneStepHash_init ========
     */
    void SHA2_OperationOneStepHash_init(SHA2_OperationOneStepHash *operation){
        memset(operation, 0x00, sizeof(SHA2_OperationOneStepHash));
    }
    
    /*
     *  ======== SHA2_OperationStartHash_init ========
     */
    void SHA2_OperationStartHash_init(SHA2_OperationStartHash *operation){
        memset(operation, 0x00, sizeof(SHA2_OperationStartHash));
    }
    
    /*
     *  ======== SHA2_OperationProcessHash_init ========
     */
    void SHA2_OperationProcessHash_init(SHA2_OperationProcessHash *operation){
        memset(operation, 0x00, sizeof(SHA2_OperationProcessHash));
    }
    
    /*
     *  ======== SHA2_OperationFinishHash_init ========
     */
    void SHA2_OperationFinishHash_init(SHA2_OperationFinishHash *operation){
        memset(operation, 0x00, sizeof(SHA2_OperationFinishHash));
    }

    Based on this document http://www.tij.co.jp/jp/lit/ml/swpb017a/swpb017a.pdf CC1310 is advertised to support SHA256. Is there something I am missing ? or this feature was lost in the process of refactoring SimpleLink as a modular framework across TI transceivers?

    Any more recent CC1310 SHA2 examples are of course appreciated!

    Best,

    Andrei

  • For CC1310 the crypto is in rom and the APIs are documented here: dev.ti.com/.../ including SHA256.

    Due to how the SDKs are build the CC13x0 SDK contains files that only runs on CC13x2 (confusing, I know). This is typically try for some of the crypto drivers that are written for CC13x2 as you have pointed out.
  • I see now. I got it now what you meant with driverlib.

    In case other people stumble upon this issue these features are in ROM driverlib port and accessible via rom_crypto.h, i.e.

    #include <ti/devices/cc13x0/driverlib/rom_crypto.h>

    Could you comment about the performance of AES-CCM from driverlib ROM version versus the AES-CCM driver ? I guess both of them use the HW acceleration, but the ROM version saves space at the cost of flexibility compared to the driver version. Are there any more important advantages / disadvantages to take into consideration from memory utilization or cpu time perspectives ?

    Best,

    Andrei

  • ROM consumes less power and is faster than FRAM.
  • Yes, that is my understanding too. I was aiming at some more quantitative comparisons in case TI did benchmark their implementations, but I guess there were no use cases to require that (at least I did not find too much documentation). I can then try it out for my own use case and see.

    In any case thank you both for the exchange.

    I don't think I can mark this as resolved as I am not the original OP. From my side all is good in the world of crypto and cc1310 for the moment.

    Thanks,

    Andrei