Hi ST team,
I’ve been testing I3C Target mode on STM32H563 using CubeH5 HAL.
In mixed write/read transactions such as:
START + DEV_W + DATA1 + RESTART + DEV_R + … + STOP
the Target cannot know in advance how many bytes the controller will write before RESTART.
However, HAL requires me to specify a fixed length when calling:
HAL_I3C_Tgt_Receive_IT(&hi3c1, rx_buf, RxBufSize);
and later, at frame completion (FCF), the driver checks:
if (LL_I3C_GetXferDataCount(hi3c->Instance) == hi3c->pXferData->RxBuf.Size) HAL_I3C_TgtRxCpltCallback(); else hi3c->ErrorCode = HAL_I3C_ERROR_SIZE;
In real usage, the controller might send only one byte (e.g. a register offset) before RESTART.
This causes HAL_I3C_ERROR_SIZE even though the transfer is perfectly valid.
Questions / suggestions
Is this strict == Size check intentional?
It seems unrealistic for Target side to know the controller’s write length.
Can HAL provide a “short frame allowed” option,
where the driver still calls TgtRxCpltCallback() and reports actual bytes received (e.g. through LL_I3C_GetXferDataCount()),
instead of treating it as an error?
If this is not supported, what is the recommended method for handling variable-length or “write-then-read” transactions in Target mode?
This limitation currently forces developers to:
either modify HAL to remove that equality check,
or catch HAL_I3C_ERROR_SIZE in ErrorCallback and treat it as a “normal short write”,
both of which are quite awkward.
Environment
MCU: STM32H563ZI
CubeH5 version: [your CubeIDE version, e.g. v1.5.0 / HAL v1.2.0]
HAL function: HAL_I3C_Tgt_Receive_IT
Firmware mode: Target
Error code observed: HAL_I3C_ERROR_SIZE
Expected improvement
Allow HAL_I3C_Tgt_Receive_IT() to handle shorter-than-expected writes gracefully,
e.g. by adding a configurable flag such as:
HAL_I3C_Tgt_Receive_IT_AllowShortFrame(&hi3c, rx_buf, buf_size);
or by reporting actual count via a callback parameter.
Thanks in advance!
This would make the HAL usable in real-world variable-length I3C Target designs.
