After STM32H5 I3C initialized as a controller, without any IBI, HotJoin Enabled, pull low SDA line will case SCL unstopped-toggle, as figure
I had searched STM32H563 Errata 2.5.13, and got something likes this behavior :
I3C controller: unexpected first frame with a 0x7F address when the I3C peripheral is enabled
Description
After I3C has been initialized as controller, an unexpected frame is generated when the I3C peripheral is enabled.
The issue occurs after the following sequence:
1. I3C is initialized as I3C controller (CRINIT bit is set in I3C_CFGR whereas EN bit is kept cleared in
I3C_CFGR).
2. I3C is enabled (EN bit set in I3C_CFGR).
As a result, the I3C controller can incorrectly detect that the SDA line has been driven low by a target, interpret it
as a start request, activate the SCL clock, and generate a 0x7F address followed by RNW bit = 1 that is not
acknowledged.
This first frame completes without any other impact than this unexpected I3C bus activity.
Workaround
Respect the sequence below during I3C controller initialization:
1. Instead of configuring the alternate GPIO of the SDA line without any pull-up, temporary enable the GPIO pullup.
2. After a delay of 1 ms, disable GPIO pull-up.
3. Initialize I3C as I3C controller by setting CRINIT in I3C_CFGR whereas EN bit is kept cleared in I3C_CFGR.
4. Enable I3C by setting EN bit in I3C_CFGR.
As a result the I3C controller does not detect SDA low when it is enabled, and no unexpected frame is generated
**Question**
I had followed the errata solution, but the problem is still not solved,
Do you have any idea?
Here is my code :
I3C1->CFGR &= ~(I3C_CFGR_EN | I3C_CFGR_CRINIT);
LL_GPIO_SetPinPull(GPIOB, LL_GPIO_PIN_9, LL_GPIO_PULL_UP);
HAL_Delay(1);
LL_GPIO_SetPinPull(GPIOB, LL_GPIO_PIN_9, LL_GPIO_PULL_NO);
I3C1->CFGR |= I3C_CFGR_CRINIT;
I3C1->CFGR |= I3C_CFGR_EN ;
