USB Interface Adapter (to SMBus)

Jim,

Moving this post to the Digital Power Forum, since the TI USB Interface Adapter (USB-TO-GPIO) uses parts that start with UCDxxxx (UCD3138, UCD9090, etc.)

www.ti.com/.../usb-to-gpio

Brian,

Thanks.  I think I have resolved my problems relating to the USB Interface Adapter.  I thought I could use the SMBus clock edge for a trigger, but, it turns out, I had to condition the edges of the SMBus clock because my state machines were running fast enough to see the metastable region for too long (relative to their clock) and they were flipping unexpectedly.  Once I 'sharpened up' the edges of the SMBus clock signal, things worked fine.

Jim

If you're using it in a noisy environment, like a power supply, you may want to sample it with a relatively slow clock (compared to what an FPGA can do) and add a clocked glitch filter.  I think there may be some glitch filtering requirements in the spec, actually. 

I'm glad to hear that the adapter is not actually sending process calls incorrectly. 

Hello Ian,

I was too quick to dismiss the Process Call issue.  All of the read and write transactions are solid with or without PEC.  The problem I was having originally was related to the slower SMBus clock versus the FPGA clock.  You were correct in your observation - the FPGA state machines would occasionally transition multiple times on a rising SMBus clock edge because it was so slow compared with the FPGA clock.  The metastable region of the SMBus clock was long enough to where a state machine register might go to a 1 and back to a 0 (not good) during the SMBus clock transistion.  Conditioning the SMBus clock to sharpen the edges cleaned everything up BUT I do have a problem with the Process Call.

For some reason I can do a regular read (byte, write or block) and the USB adapter will send an Address (R/W bit = 0) => Command => RepeatStart => Address (R/W bit = 1)... and everything works great, but when I do a Process Call I get the following sequence:

Address (R/W bit = 0) => Command => NumBytes => Byte#1 => Resend Byte#1 => RepeatStart => Address (R/W bit = 0)  When the Process call is a Word write, word read for example with a payload of 0xCDAB, it will send 0xCDCD instead of 0xCDAB as shown in the GUI window.  I ACK these properly and then the adapter will send the RepeatStart followed by the address, but instead of setting the R/W bit to a 1, it sets it to a 0.  So I have two issues:  1) when sending a word, it writes the first byte twice.  2) instead of the R/W bit = 1 after a RepeatStart it sets the bit to a 0.

I am using the Fusion Power 'SMBus & I2C & SAA Debug Tool' GUI on top of the TI USB Interface Adapter because I have been led to believe that the GUI originally published for the USB adapter does not work for OS' later than XP (I'm running Windows 7).  In general everything works except Process Calls.

Any Ideas?,

Jim

Jim, that's surprising to me.  I think I've used the same function, although in the device GUI, to debug block process calls with success. 

Which version are you using?  Also what version of the SAA code is installed?  You can see by clicking on SAA settings. 

Hello Ian,

Thank you for your quick response. The SAA settings indicate that the USB Adapter Firmware Version is: 1.0.10 and the version of SAA code according to the splash screen that comes up during the opening of the GUI is: Version 2.0.120 [2016-02-23]

In regard to your 'Happy Debugging', I am loving this. I spent the last 1/2 a year successfully designing the power subsystem for a 150 Watt PCIe card (with a significant amount of help from the TI FAE), but my heart is much more in tune with RTL development. After 45 years in electronics, I am still finding interesting work.

Best Regards,

Jim

Hello Ian,

Thanks for verifying my observation about the Process Call not setting the RnW = '1' bit on a repeat start (I also noticed that Process Call sends the one byte twice instead of sending a word so if you put in 0xCDAB it sends 0xCDCD).

I am not out of the woods though.  I tried to use Block Process Call and, while it handles the write phase correctly (as many bits as I want to ship come across the protocol analyzer correctly), after a Repeat Start, it sends the slave address, but does not raise (release) the RnW bit.  Attached is an example scope shot showing a 3 bit write transaction 0xCDABEF followed by a Repeat Start followed by the slave address (0x44 with the RnW bit remaining low - between the cursors).

I will keep working on this, but if you saw it working correctly on your end, I must be doing something wrong - though I don't control the bus during this period other than to ACK the address on the 9th clock edge.

Regards,

Jim

On mine, I see it releasing that RnW bit for both cases, process and block process. I wonder if your FPGA is getting its bit count off because of the repeated start. I'd suggest putting a resistor in between the master and slave on the data line. That way you can see who is pulling it down. It will be lower for the side closer to the pull up.

Ian,

Sorry, I need to clarify. I said in my last reply, "...3 bit write transaction 0xCDABEF followed by a Repeat Start...", but I should have said "...3 BYTE write transaction 0xCDABEF followed by a Repeat Start..."

AND I noticed I interpreted your last reply incorrectly, I thought you were verifying that the RnW bit is not going high after a Repeat Start, but you were confirming the re-writing of the LS Byte on a Process Call. The problem I have with both the Process Call (in addition to duplicating a byte twice instead of writing a word) and the Block Process Call is the fact that it does not turn the bus around by raising the RnW bit after a Repeat Start.

Isn't this fun!

Jim

Ian,

Looks like our messages crossed. I will look at the FPGA more closely.

Thanks,

Jim

Hello Ian,

You were right!  I have 10 state machines running in my design of an SMBus slave.  I found that one of them, during the Write phase of a process call, was active one extra cycle (1 byte length) and contending with the FSM that was operating during the Repeated Address phase.  Once I got that straightened out it began supporting all versions of Read, Write and Process Call with or without PEC.  The resistor suggestion was a good one and helped me narrow down the possible causes.  Now the tough part - closing timing.

Thanks again,

Jim