LPC55S36 I3C Slave Speed Limitation

[bell_huang]

Two LPC55S36 boards were connected for I3C communication, with one configured as the I3C Master and the other as the I3C Slave.
When the Master’s push-pull baud rate is set to 1.25 Mbps, communication proceeds without issues. However, increasing the baud rate to 2.0 Mbps causes the Slave to fail in receiving data properly, resulting in a NACK response.

The question is whether there are any configuration parameters or tuning methods available that would allow the I3C Slave to reliably handle higher baud rates.

Note:

The sample code being used employs the function I3C_BusMasterDoTransferToI3CDev, which is defined in the fsl_component_i3c_adapter.h header. This function performs a write to the device address followed by a read, even during read operations.

In contrast, the SDK example lpcxpresso55s36_i3c_polling_b2b_transfer_master uses the function I3C_MasterTransferBlocking, which performs a pure read operation during reads.

Due to this behavioral difference, the latter example (I3C_MasterTransferBlocking) is able to operate correctly at 2.0 Mbps, whereas the former (I3C_BusMasterDoTransferToI3CDev) leads to reception failures at the same baud rate. At even higher baud rates, both approaches result in failed receptions on the Slave side.

[Harry_Zhang]

Hi @bell_huang 

Can you share your project? So I can reproduce this issue.

BR

Harry

[bell_huang]

Hi @Harry_Zhang ,

Test steps:

(1) Reset slave board

(2) Reset master board

Also check out the speed configuration in master code:

baudrate_config.i3cPushPullBaud = 1250000;
baudrate_config.i3cOpenDrainBaud = 625000;

If we modify i3cPushPullBaud to 2000000, then the master cannot read correct data.

[Harry_Zhang]

Hi @bell_huang 

I tested the lpc5536 SDK i3c example.

I changed the EXAMPLE_I3C_PP_BAUDRATE

#define EXAMPLE_I3C_PP_BAUDRATE 2000000

It can work.

So it  proves that it can work at this speed.

BR

Harry

[bell_huang]

As mentioned in the note of my first post:

The simple examples in the SDK (such as lpcxpresso55s36_i3c_polling_b2b_transfer_master) use a Single message format, which means:
Write: Slave Address (RnW = 0) → Data
Read: Slave Address (RnW = 1) → Data

However, almost all sensors in the industry (for example, lpcxpresso55s36_i3c_master_read_sensor_icm42688p) use a Combined format, which means:
Write: Slave Address (RnW = 0) → Register Address → Data
Read: Slave Address (RnW = 0) → Register Address → repeated START → Slave Address (RnW = 1) → Data

This explains why your Single message example can reach up to 2.0 Mbps, while my Combined format example can only achieve a maximum of 1.25 Mbps.

In lpcxpresso55s36_i3c_polling_b2b_transfer_master, if you modify masterXfer to use the Combined format by adding the following code, it will switch to the Combined format. Then you will observe that the maximum achievable speed drops to 1.25 Mbps. Please refer to the attachment in this reply.
masterXfer.subaddress = 0x34;
masterXfer.subaddressSize = 1;

Additionally, the most important point is that the I3C specification defines the baud rate to support up to 12.5 Mbps. Both Single message (Max = 2.0 Mbps) and Combined format (Max = 1.25 Mbps) are far below this limit. This is why I would like to know if there is any way to improve the Slave’s capability to accept higher baud rates.

[Harry_Zhang]

Hi @bell_huang 

I have tested it.

When the PP Baud is setted to 2M.

baudrate_config.i3cPushPullBaud = 2000000;
baudrate_config.i3cOpenDrainBaud = 625000;

You can try to improve the optimization level of the code.

It can work.

BR

Harry

[bell_huang]

Hi @Harry_Zhang ,

Thank you for the information about setting the optimization level to O3. After adjusting the Slave configuration, the Master now appears to reach 4 Mbps. (I’m not sure why, but after a Slave reset the Master’s first Read fails, while subsequent Reads succeed.)

Could you confirm whether 4 Mbps is indeed the limit on the Slave side? As mentioned earlier, the I3C specification allows up to 12.5 Mbps; even the Building an I3C Sensor Network Using LPC553x/LPC55S3x example operates at 10 Mbps.

[Harry_Zhang · Accepted solution]

Hi @bell_huang 

I have debugged the slave code.

I add one toggle signal.

The start address header uses open-drain baudrate (typically less than 2MHz), allowing the target more time to fill the TX FIFO and thereby achieve ACK. However, the repeated start address header uses push-pull baudrate, and if set above 4MHz, the target doesn't have sufficient time to fill the TX FIFO, resulting in NACK. Based on current MCU performance, if we want to achieve higher rates, we need to optimize the target code to accelerate its response speed.

BR

Harry

[bell_huang]

Thank you for the explanation. As you noted, when the speed is too high, the Slave does not have sufficient time to fill the TX FIFO, so it responds with a NACK.