Bug with Hashcrypt on LPC55S06

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bug with Hashcrypt on LPC55S06

439 Views
s_hdl
Contributor I

Hello, 
I encounter an infinite loop in my attempt to use Hashcrypt HW acceleration. 
The Hashcrypt driver version is 2.2.17. The microcontroller get stuck at the line 679 in hashcrypt_sha_one_block() : 

while (0U == (base->STATUS & HASHCRYPT_STATUS_WAITING_MASK))

    {

//stuck here

    }

Surprisingly, it appears to be stuck after 90 executions (our microcontroller manages to perform 89 times hashcrypt_sha_one_block without being stuck).

The main call is done by embedTLS ssl_tls.c file (see err.png).

 

Here is my current implementation of mbedtls_sha256_finish() (that I needed to implement by defining the SHA256_ALT when building mbedTLS v3.6.7

int mbedtls_sha256_finish(mbedtls_sha256_context *ctx,unsigned char *output)

{

status_t status;

status = HASHCRYPT_SHA_Finish(

HASHCRYPT,

(hashcrypt_hash_ctx_t *)ctx->hash,

output,

NULL);

return status;

}



Our code is bare metal, we don't have different processes. 

Thank you very much for your help.

 

Regards,

Harold

0 Kudos
Reply
1 Reply

311 Views
ronald59pepper
Contributor I

This behavior typically stems from a state desynchronization or context corruption across repeated mbedTLS sessions, where an internal buffer offset, total length counter, or driver context field (ctx->hash) fails to fully reset between sequential TLS handshakes. Because the hardware expects a specific block length or padding sequence to trigger the HASHCRYPT_STATUS_WAITING_MASK flag, a minor residual tracking error accumulates or triggers on a specific payload size, causing the polling loop to hang indefinitely. Ensure that HASHCRYPT_SHA_Init() is cleanly invoked and all context structures are completely reinitialized at the start of every new hashing operation rather than relying on residual state.