Tool/software:
Device: CC1352P1F3
SDK: simplelink_cc13x2_26x2_sdk_3_40_00_02
We saw that sometimes when the MCU calls AESGCM_oneStepDecrypt or AESGCM_oneStepEncrypt, the CPU enters an endless loop until the HW WDG rests the mcu.
In the good flow, we saw the following:
1. MCU calls AESGCM_oneStepDecrypt or AESGCM_oneStepEncrypt
2. Ti Driver calls AESGCM_startOperation
3. This function arrived at the last line which is AESGCM_waitForResult
4. AESGCM_hwiFxn is called (object->operationInProgress was true when this Hwi called)
5. AESGCM_hwiFxn posts the semaphore so the task which called the crypto API exit blocking mode and running
In the bad scenario, we saw the following:
1. MCU calls AESGCM_oneStepDecrypt or AESGCM_oneStepEncrypt
2. Ti Driver calls AESGCM_startOperation
3. This function arrived at this line AESStartDMAOperation(operation->aad, operation->aadLength, NULL, 0);
4. AESGCM_hwiFxn is called (object->operationInProgress was false when this Hwi called)
5. AESGCM_startOperation continues after AESGCM_hwiFxn is finished, and it arrives at line AESGCM_waitForResult and enters an endless loop and doesn't release the CPU. this function is defined as ROM_AESWaitForIRQFlags.
see in the assembly we can see this is an endless loop to the same address 0x1002'fa10
we think the reason is that the AESGCM_hwiFxn clears IRQ flags
AESIntClear(AES_RESULT_RDY | AES_DMA_IN_DONE | AES_DMA_BUS_ERR);
while AESWaitForIRQFlags is waiting for the IRQ flags
AESWaitForIRQFlags(AES_DMA_IN_DONE | AES_DMA_BUS_ERR);
We don't know what caused this bad flow.
We need help to understand if there is something wrong that we do that causes this bad flow in the Ti driver.
or if this is a fixed bug on ti new SDKs?
or something else?
Thanks in advance.