[Bug]: HAL_CRYP_Decrypt_DMA fails when transfer size is > 65535 bytes

[timkostka]

Bug Summary

HAL_CRYP_Decrypt_DMA fails when transfer size is > 65535 bytes

Detailed Description

With CRYP set up with word-sized transfers (CRYP_DATAWIDTHUNIT_WORD), it should be able to process 65535 words, or up to 262140 bytes. Internal to HAL, the Size field is set to the number of bytes in the operation, not the number of words, which causes an overflow in the uint16_t value.
https://github.com/STMicroelectronics/stm32h7xx-hal-driver/blob/a1996eed9172b59887bafaaa0ea1816ea14d48b5/Src/stm32h7xx_hal_cryp.c#L1587

    /*  Calculate Size parameter in Byte*/
    if (hcryp->Init.DataWidthUnit == CRYP_DATAWIDTHUNIT_WORD)
    {
      hcryp->Size = Size * 4U;
    }
    else
    {
      hcryp->Size = Size;
    }

The comments say that Size is the number of bytes or the number of words, depending on DataWidthUnit. However, the code sets it to the number of bytes regardless of the DataWidthUnit setting.
https://github.com/STMicroelectronics/stm32h7xx-hal-driver/blob/a1996eed9172b59887bafaaa0ea1816ea14d48b5/Inc/stm32h7xx_hal_cryp.h#L111

  uint16_t                          Size;           /*!< length of input data in word or in byte, according to DataWidthUnit */

It looks like many of the DMA functions are passed Size / 4.

The same issue is present within HAL_CRYP_Encrypt_DMA and possibly others.

Community post:
https://community.st.com/t5/stm32-mcus-security/unexpected-behavior-of-the-stm32-cryp-module/m-p/891638#M9633

Expected Behavior

HAL_CRYP_Decrypt_DMA functions correctly for operations on <= 65535 words when set to CRYP_DATAWIDTHUNIT_WORD

Actual Behavior

The transfer size is truncated due to the number of bytes being stored as a uint16_t

Environment

No response

Severity

Normal

[MKISTM]

Hello @timkostka,

Thank you for your report, it seems that point makes sense and will be tracked internally.
I'll keep you informed about last update and our decision about this point.

BR,
Mohamed Chaker.

[MKISTM]

ST Internal Reference: e6bf58f49fd48310767372aaa624ab4e

[MKISTM]

Hello @timkostka,

After investigation and forwarding the issue to our specialized team,

According to the STM32H7 reference manual, DMA has a hardware per-transaction limit:
The transfer counter is 16-bit.
A single transaction is therefore limited to 65535 items (depending on the configured data width).

Practical consequence:
Any transfer larger than 65535 items cannot be handled in a single DMA1/DMA2 transaction.

Recommended approach for sizes > 65535:

• Split the transfer into segments (chunking).
• Chain multiple DMA transactions, each <= 65535 items.
• Update source/destination pointers and remaining length after each segment.

Therefore, this point does not make sense, so please allow us to close this issue.
Thank you for your understanding.

Best Regards,
KIWA Mohamed Chaker.