cancel
Showing results for 
Search instead for 
Did you mean: 

why fixed length for i3c private write

wenlong
Associate

 

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

  1. Is this strict == Size check intentional?
    It seems unrealistic for Target side to know the controller’s write length.

  2. 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?

  3. 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.

Edit: edited to apply code formatting in correct way

1 REPLY 1
JRAUL.1
ST Employee

Hello,

this error is an informative error, it is up to the application to known what it can do in that case.

But good point, the only way to get the final count is to use the count inside the handle minus your request.