• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 1388 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C bus is locked during EEPROM boot

Andy Yin
Genius 9320 points
Other Parts Discussed in Thread: TMS320C6678

Hi experts,

During the I2C booting of the DSP (TMS320C6678), we figure out sometime the DSP will lock the I2C lines and then fail to boot but also lock the I2C EEPROM. The only way to solve the problem is to follow the TI Silicon errata I2C reset workaround(Errata usage note 6).

Please find more information here about our design and issue met:

The I2C EEPROM is into a +3.3V environment. There is two I2C masters: First is an FPGA (direct connection), and second is an I2C Level Transceiver +1.8/+3.3V (PCA9306DCTT) connect to DSP. The transceiver enable pin is controlled by FPGA. FPGA is fully under our control.

During boot-up sequence (but also before and after), we verified and we are sure that the FPGA drive nothing (Keep Hi-Z) and transceiver is enabled and do not toggle.

To reproduce the error case, we just need to power cycle the DSP again and again (power of DSP is independent controlled by FPGA, it would not affect power of EEPROM.) until the DSP lock its I2C Reading. This error case is not easily reproducible. FPGA I2C interface and DSP power control interface are independent. 

If we power on again the DSP, after error happened, no I2C command is sent by the DSP and SDA remain low. 

The only way to “free” the bus is to generate an I2C command with FPGA. Basically, an I2C reading command sent by FPGA will make the EEPROM answer an error on the “acknowledgment” bit of the first sending byte, and then, will free the bus. A power cycle of the DSP after this point will make the I2C boot success. 

For the Reset timing Sequence, We just follow the DSP Reset time diagram of the EVM board. 

So far, we never got I2C reading/Writing error with FPGA command which exclude any EEPROM Issue. 

After testing and review, we got then the certitude that the error come from the DSP side, and no others. Please help us to support on the issue. 

Thanks in advance.

  • 0
    TI__Mastermind 30825 points

    Andy,

    This has not be observed on the EVM which uses I2C EEPROM and hasn't been reported as an 'I2C EEPROM' isolated issue, significant testing has been done on this.  The only time it's occured is under the condition of the usage note.  Do you have scope captures when the failure occurs?

    Best Regards,

    Chad

  • 0 in reply to Chad Courtney
    Prodigy 110 points

    Chad,

    Sure we have (sorry for the quality, it is a screen capture):

    as the capture shows, the error happens when the DSP reads 7bits on the last byte try (Should be 8bits data+1bit ack). As no "stop condition" is sent by the DSP, the EEPROM just wait the DSP pulse one more clock period to send the bit-8; Then it lock the I2C lines.

    This error happen suddently during a sequential read phase, after many bytes already sent before...

    Thank you for your support.

    Olivier.

  • 0 in reply to olivier faurie
    TI__Mastermind 46460 points

    Olivier,

    Please provide a zoomed capture of just the last SEEPROM read and show the SCL and SDA for both the 1.8V and 3.3V circuit portions.  You will need to capture all 4 channels on a single scope capture.  Take care to clearly set the ground level for all 4 probes so that the voltage levels are clearly readable.

    Tom

     

  • 0 in reply to Tom Johnson 16214
    Prodigy 110 points

    Tom,

    I will do my best to try to capture this event (Not happen that often actually).

    What I can say is that we already tried to do so, and nothing special had been noticed : the +3.3V side and +1.8V side had the same shape. By the way, the third channel of the scope (I remove it from the capture) probe the "enable" pin if the transceiver. It remains active all the time (and without glitches).

    The provided waveform shows signal on the EEPROM's pins. Do you have any concern about FPGA driving something or transceiver issues?

    Thnak you.

    Olivier.

  • 0 in reply to olivier faurie
    TI__Mastermind 46460 points

    Olivier,

    I am concerned with levels and timing.  Precise scope captures are needed.  The one provided is insufficient.  You should be able to setup your scope trigger to look for this stall when clock stops toggling for more than a maximum time period.

    Tom