RTL8720DN as I2C slave


I’m currently trying to use the RTL8720dn chip as I2C Slave. I’ve tried using some functions and implementations of the sdk (i2c_api), but facing some weird issues where the polling mode doesn’t seem to work. Because of this, I’m curious if the Arduino package contains the full implementation. What’s the best practise in this occasion?

Currently I’m programming the chip with a library (self made) on top of the i2c_api.h header which in included in the arduino package (AmebaD/3.0.7/system/libameba/sdk/component/common/mbed/hal/i2c_api.h). But I just had a look into the SDK and faces the rtl8721d_i2c.h header and source (ambd_sdk/rtl8721d_i2c.c at master · ambiot/ambd_sdk · GitHub). Does any of you have experience with this case, and what’s best practise?
Use the i2c_api in the arduino package, or take a look into the official sdk. As told it’s required to use the 8720dn in polling mode (waiting for the master to send a request to respond on).

Thanks guys!

Kind regards,

1 Like

hi Tim,

afaik, arduino also only uses i2c in master mode

do you mind elaborate?

1 Like

Hi Simon,

That’s what I was a bit afraid of hahah! I tried editing the header a bit by changing the way it uses the slave. I did this by changing the TwoWireStatus and calling the functions, which are provided by the package a bit different. For writing, it seems to work. But it’s more of a brute force where the slaves tries to finish the transaction, which needs to be on the specific time when the master reads. Ofcourse, this isn’t the desired behaviour, but this was just me trying to find a workaround for the lack on slave-mode. Happy to hear that you think to know that the arduino package only provides master usage.

Have you used the rtl8721d_i2c header and source of the sdk? Just checked the code and header and this seems to have a chance of working. Only not sure if it provides a polling mode for the slave. In an ideal scenario, the slave keeps listening, and will be triggered (by callback) when he get’s polled by the master.

To elaborate on the polling issues:
The slave tries reading from the bus, but this doesn’t sees anything. However, i’ve checked the signal with a logic analyser, which is all fine (address and payload). I think, as you told, the arduino package spares some support for the slave side.

Hi Tim, you probably should look into this file instead, as this is the api primarily used for I2C operation

Hi Simon,

I could be wrong, but that’s the same as in the arduino package (AmebaD/3.0.7/system/libameba/sdk/component/common/mbed/hal/i2c_api.h), in which the slave mode seem to has lacks (as you told).

I can have a look in the source, but on the bus (using this api, as provided above) I’m not seeing a read signal when the slave is in polling mode.

check this line out, is this the one you need?

also this line for polling mode

1 Like

Hi everyone,

I’ve finally been able to get the slave in polling mode with the Master. However I’m stil facing a couple smaller issues.

The image below shows a simple I2C transmission where the master (raspberry pi 4, SMBUS protocol) sends a message (0). Then the interrupt of the slave is triggered which then returns WriteAddressed (i2c_slave_receive), with in this case the register (0x10 = 16 dec) and the payload (0). This is read correctly by the Slave, which then sends a response back (1) to the Master using i2c_slave_write. This flow is valid. Also on the logic analyzer (image below) you can see that the transaction is then completed, and the SDA line is pulled up by the Master.


However, the i2c_slave_receive function remains constantly ‘ReadAddressed’ returned in an infinite loop. Is this because of the NACK to the (1) response message? Which on the one hand would be strange since the SDA line is pulled up, and the ‘1’ is actually read on the Master side. Does anyone have experience with this? And how do I fix this to repeat the previous transaction again without letting the WriteAddressed pass through because the slave thinks it is constantly being asked to read (which is not the case on the line).

The slave does not send the response until it receives a “ReadAddressed” for the first time. This also makes it strange that he keeps asking again while the master side (SMBUS) only asks for 1 byte.

Thanks guys.

1 Like