I2C start condition have a bug

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open in I2C mode
2. Issue start condition (call Start() method)

I found a bug in Start() method.
See the attached patch file.

Original issue reported on code.google.com by 6sa2n4r...@gmail.com on 19 Sep 2012 at 9:58

Attachments:

• fix_i2c_start_condition.patch

[GoogleCodeExporter]

Can you please provide more information on the bug, such as:

   o What FTDI device are you using with libmpsse?
   o What I2C device are you communicating with?
   o How do you have your I2C device connected to the FTDI chip?
   o Have you tested and verified that the start condition did not work prior to your patch and that it does work after applying your patch?

Considering that the I2C clock and data lines are part of the low 8 bits on the 
FTDI chip's MPSSE bus (reference: FTDI Application Note 135), I don't see how 
applying changes to the high 8 bits would provide proper control over the I2C 
pins. Additionally, I have used libmpsse in its current configuration to 
communicate with I2C devices before, so I can verify that the current 
implementation of the Start() method is functioning properly for me.

Original comment by heffne...@gmail.com on 19 Sep 2012 at 1:38

[GoogleCodeExporter]

FTDI chip: FT2232H
Target I2C device: micro controller (it supports EEPROM like accessing)
Connection: FTDI device channel A and MCU are connected directly.

MCU SCL - FTDI TCK/SK(16)
MCU SDA - FTDI TDI/DO(17) & TDO/DI(18)
(SCL and SDA lines are pulled-up to 3.3V)

I have to say sorry that the patch was incorrect.
It breaks a repeated start condition.

Attached files are test code and captured waveform.

Original comment by 6sa2n4r...@gmail.com on 20 Sep 2012 at 1:29

Attachments:

• regutils.py
• test1.py
• test2.py
• test1_test2_waveform.pdf

[GoogleCodeExporter]

Ah, a picture is worth a thousand words; sorry, I thought you were having 
problems with speaking I2C to a particular device. 

This is a known issue, although it *shouldn't* cause problems with I2C 
compliant devices.

The extra low clock output that you're seeing is performed in order to 
absolutely ensure that the SDA and SCL lines are in their expected states prior 
to issuing a repeated start condition (the Start() function is used for both 
starts and repeated starts). If a start condition has not been previously 
issued, the clock toggle will be ignored by I2C devices on the bus anyway, and 
if it has then this will be seen as a repeated start condition. However, it 
does look odd on the 'scope and is an undesirable side-effect.

After some thought, I think there is a simple fix for this that doesn't break 
repeated start conditions, but I'll have to wait until I get home tonight to 
test it and check it in.

Original comment by heffne...@gmail.com on 20 Sep 2012 at 2:55

• Changed state: Started

[GoogleCodeExporter]

Just checked in a patch that removes the extra clock toggle on a start 
condition, but preserves the expected behavior for a repeated start condition.

Original comment by heffne...@gmail.com on 21 Sep 2012 at 3:04

• Changed state: Fixed

[GoogleCodeExporter]

Thank you for your quick work.
Latest code on repository works perfectly!

Original comment by 6sa2n4r...@gmail.com on 21 Sep 2012 at 4:17