0

I use an AN108 to drive my I2C line (actually SMBus).

I'm debugging with an oscilloscope.

Doing a read, right after the 8b address, I found that the slave was pulling down my clock signal SDC for a few cycles, therefore the ACK isn't read correctly.

How can I handle that with MPSSE? I would need to wait until the slave stops pulling down the SDC line.

ocrdu
  • 8,705
  • 21
  • 30
  • 42
Alexis
  • 347
  • 2
  • 16

2 Answers2

2

If you read FTDI app notes such as AN355 on the subject, MPSSE on FT232H does not support clock stretching.

Solutions include using a low enough SCL rate to ensure the slave clock stretching is covered by the master communicating slowly enough, or changing to another chip that properly supports clock stretching.

Other solutions may exist; maybe don't use MPSSE and use some other available methods to bit-bang the I2C protocol.

ocrdu
  • 8,705
  • 21
  • 30
  • 42
Justme
  • 127,425
  • 3
  • 97
  • 261
  • Thanks! Reducing the frequency isn't enough, SCL is pulled low for few cycles, almost 8-9. Then I'll try the other answer. My goal is just to debug an I2C slave, nothing for production or permanent. I'd be fine if it works few days. – Alexis Jan 27 '23 at 13:52
1

Adaptive clocking feature of MPSSE allows to implement I2C clock stretching. I have a design with FT4232H that implements this, and same feature is supported on FT232H, so it should work there as well.

Adaptive clocking feature (DS_FT232H, 4.8.1 p. 32) uses a pin (GPIOL3, fixed) to sense a delayed copy of TCK after it went through the target and back. It is supposedly used to allow to clock TCK as fast as possible in JTAG mode on old ARM targets. As MPSSE is implemented, this actually works for non-JTAG protocols as well: It works as long as you use MPSSE clocked commands (bit shifts, free running clocks, etc.).

With the following wiring, FTDI TCK/TDI pins drive SCL/SDA down when needed, TDO senses SDA back, GPIOL3 senses SCL back.

MPSSE I2C wiring with adaptive clocking

Here is an excerpt of effect on bus, while the whole MPSSE command stream was sent as one USB transfer, we can see the target stretches the bus while preparing the next data byte:

Clock stretching before byte reads

This can be compared with writes where no stretching happens: Write, no stretching

The only downside is that MPSSE has no timeout on the adaptive clocking feature, so you never have response on MPSSE stream if I2C bus has SCL stuck low. Most common is when target is not powered. In such cases, you are forced to reset the endpoints and the whole MPSSE engine.

Nipo
  • 1,315
  • 8
  • 9
  • 1
    FTDI application note 355 specifically mentions that the adaptive clocking feature is not designed to be used with I2C and it does not provide full clock stretching support. They do not recommend implementing clock stretching with adaptive clocking, they do not guarantee operation, and they don't provide any support if you run into problems. That is a clear indication it should not be done on FT232H. As a solution they mention FT4222H will support clock stretching. – Justme Jan 27 '23 at 10:48
  • Agreed: some conditions are unworkable, as I mentioned. But not recommending only means they do not want to loose time supporting implementors that get into the pitfall. That does not mean it is totally useless. Moreover, OP needs SMBUS support rather than I2C. This may be favorable as stretching is bound on SMBUS (fmin = 10kHz). – Nipo Jan 27 '23 at 11:08
  • And my use-case is for playing around, not meant to be in production. Thank you Nipo, I will accept the answer once I tried tomorrow. – Alexis Jan 27 '23 at 13:38
  • Adaptive clocking worked nicely! Thanks! – Alexis Jan 28 '23 at 10:51
  • May I ask what is the device used for the screenshots? It seems quite good with I2C decoding. – Alexis Feb 12 '23 at 23:06
  • Saleae Logic Pro 8 – Nipo Feb 13 '23 at 13:38