• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1807 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

USB Interface Adapter (SMBus)

Jim Slupe
Prodigy 90 points

In an earlier post I indicated that I was using a TI USB Interface Adapter to check out an SMBus module that I am writing.  I mentioned that the "Process Call" section of the SMBus/I2C/SAA GUI tool from the Fusion power design suite was being used to drive the adapter.  I mentioned that I was not seeing the Read command from the host after a 'Restart' was issued during a "Process Call".  That the bus was reporting the reissuance of the slave address followed by a the RnW bit set low. 

What makes this more interesting is that "BLOCK Process Call" seems to work correctly.  It does turn the bus around as one would expect.  The RnW bit is high after a 'Restart' and the transaction seems to work properly.

I also noticed another problem with the "Process Call" section:  "Process Call" however, doesn't seem to work right in another respoect.  If I enter ABCD hex for the data payload, monitoring the bus I notice that it ships out and reports ABAB hex.  This is true for any entry I try.  It just ships out the first byte twice instead of one followed by the other.

If worse comes to worse I guess I can use a Block Process Call that ships and receives only two bytes each way, but I am curious if anyone else has seen this problem.

  • 0
    TI__Mastermind 30280 points
    Jim,

    As with your other post, I have moved this thread to the Digital Power Forum.
  • 0
    Genius 5200 points

    Hi Jim,

    I also have noticed issues with the GUI tool. (I have not yet checked if the same errors are present in the API provided in the same package).

    When sending a process call the first byte of data is sent twice and the second byte is never sent.

    When sending a write word the bytes are reversed. I believe this latter issue maybe because the implementation treats the data as an actual word (i.e. a 16-bit piece of data) rather than 2 bytes (i.e. 2 separate 8-bit pieces of data).

    The write word issue can be overcome by simply using the I2C write option instead and just sending two bytes of data. unfortunately there doesn't seem to be any similar easy way to produce a correct process call using this GUI tool however.

    In the image attached you can see that the GUI claims to be sending 0x7A00 data for the 0x1B WriteWord command, but the scope shows that the data bytes are sent reversed. the image also shows directly that although the data entered to the process call user control is 0xA5FD, it is instead sending 0xA5A5.

    Rgds, T

  • 0 in reply to TobyM
    TI__Genius 17090 points
    Jim, I think we worked out this on the message associated with your first post. The repeating of the byte with the process call is confirmed, and it's on the backlog to get fixed. The read/write bit issue was from your FPGA interface.

    Toby, I think the order is actually correct, but counterintuitive. The SMBus and PMBus specs say that if you do a word write, you send the least significant byte first. It's confused me more than once.
  • 0 in reply to Ian Bower
    Genius 5200 points

    Thanks for the clarification Ian!

  • 0 in reply to Ian Bower
    Genius 5200 points
    Hi Ian,
    I have come across a couple of other potential bugs with this tool.

    1. When using the I2C Write, NACKs do not appear to be reported. If I send a string of bytes using this command that I expect to be NACK'ed I can see the NACK on the scope, but the GUI reports an ACK both in the log and next to the I2C Write option. Forcing the Write Block command to generate the same byte string (e.g. Write Block Cmd: 01 Data: 00 00 00, I2C Write Cmd: 01 Data: 03 00 00 00) results in the expected NACK being reported correctly where the scope shows the exact same waveforms.

    2. The GUI does not allow Block Write to accept a data length of 0. I guess this is a pretty low need use-case. However a small UX bug is that if the GUI is showing its error for an empty data block in the Block Write command the GUI does not prevent switching to a different protocol although it does continue to block all other user input - a minor issue but confusing.