Skip to main content
Explorer
August 25, 2025
Question

I3C Master RX length > Slave TX length

  • August 25, 2025
  • 2 replies
  • 546 views

I am using two  NUCLEO-U385RG-Q boards for I3C communication—one as the Controller (Master) and the other as the Target (Slave). When the Controller’s RX length exceeds the Target’s TX length, after the first call to HAL_I3C_Ctrl_Receive_IT the Controller appears to enter an abnormal state; on the second call to HAL_I3C_Ctrl_Receive_IT, it hangs and an abnormal waveform is observed.

 

After the first call, is there a way to restore the Controller to a normal state?

 

Regarding Target-controlled TX length, please refer to I3C Specification, Section 5.1.2.3.4, which states:

In I2C, Read from Target has the issue that only the Controller ends the Read, so the Target has no ability to control the amount of data it returns. In I3C SDR, by contrast, the Target controls the number of data Words it returns; but it also allows the I3C Controller to abort the Read prematurely when necessary.

 

Master Rx = 3, Slave Tx = 2 (First & second calls)

bell_huang_0-1756106814010.png

bell_huang_1-1756106824360.png

 

Master Rx = 2, Slave Tx = 2 (First & second calls)

bell_huang_2-1756106862218.png

bell_huang_3-1756106871530.png

    This topic has been closed for replies.

    2 replies

    Technical Moderator
    August 25, 2025

    Hello @bell_huang ,

     

    Are you using I3C example from STM32CubeU3?

    Do you get the same issue with I3 examples?

    Are you need to reset the I3C handle state? If, yes you can use __HAL_I3C_RESET_HANDLE_STATE.

     

    Thank you.

    Kaouthar

     

    Explorer
    August 26, 2025

    Hi @KDJEM.1 ,

    Yes, I am using the stm32u3xx_hal_i3c APIs, and in my first post I attached minimal sample code: i3c_master.zip and i3c_slave2.zip. I haven't used the stm32u3xx_ll_i3c APIs yet, since their low-level complexity makes it easy to misconfigure or misuse them.

    I tried calling __HAL_I3C_RESET_HANDLE_STATE(&hi3c1) after the first call; on the second call to HAL_I3C_AddDescToFrame, it immediately returns HAL_ERROR. Looking at the definition of __HAL_I3C_RESET_HANDLE_STATE, it appears to only assign hi3c1.State to HAL_I3C_STATE_RESET and does not cause any change on the board (i.e., no hardware-side reset).

     

    #define __HAL_I3C_RESET_HANDLE_STATE(__HANDLE__) ((__HANDLE__)->State = HAL_I3C_STATE_RESET)

     

    Technical Moderator
    August 27, 2025

    Hello @bell_huang;

     

    First of all, I recommend you take a look at Description of STM32U3 HAL and low-layer drivers User manual and precisely section 31.2 I3C Firmware driver API description. I think this user manual can help you to start with  stm32u3xx_hal_i3c APIs.

    Also, I advise you referring to STM32CubeU3/Projects/NUCLEO-U385RG-Q/Examples/I3C/I3C_Controller_Private_Command_IT at main · STMicroelectronics/STM32CubeU3 · GitHub example to check your code.

     

    Thank you.

    Kaouthar

    Explorer
    August 28, 2025

    Hi @KDJEM.1 ,

     

    Thanks. This is not about getting started. I already based my code on the STM32CubeU3 I3C example you mentioned. If there is any misuse in my code, please kindly point out the exact place.

    The actual issue is a repeatable case when the Target ends a read early (Target TX < Controller RX; spec §5.1.2.3.4):

    • First call HAL_I3C_Ctrl_Receive_IT() with RX=3, Target TX=2 → completes but leaves Controller in abnormal state.
    • Second call → hangs with abnormal waveform.
    • Control case (RX=TX) works fine.

    Could you please clarify:

    • What sequence should the Controller follow after a Target-short read (abort, flush, clear flags/FIFO, reset…)?
    • Is this a known issue in STM32U3 I3C HAL?
    • Are there any examples showing correct handling of this spec-compliant case?

    Minimal projects and scope captures are attached in my first post. Thanks.