I'm writing a Linux driver for the TMP006EVM. I understand the USB interface is a general purpose SM-USB-DIG device used in other evaluation modules also. I notice there is good documentation on the *hardware* of the SM-USB-DIG, but I can't find any documentation on USB protocol it uses.
Using Wireshark I can make sense of some of the USB bus data (I can see the TMP006 registers in the query and the register values in the response). But it would be nice to work from proper documentation (or firmware source code) if that's available.
The SM-USB-DIG uses a standard Windows Human Interface Device (HID) driver. I've attached the firmware that is loaded into the TUSB3210 that is on the SM-USB-DIG. The system works by taking simple commands from the PC over USB and translating the commands into Power, GPIO, SPI, or I2C actions.
Regards,Collin WellsPrecision Analog3660.SM-USB-DIG-Firmware.zip
Regards,Collin WellsPrecision Linear Applications
In reply to Collin Wells:
Thanks -- that was very helpful. The magic is in usb.c (GenCommand() and I2C_Write() functions in particular) and I can see how the protocol works now.
I've written some C code using the libusb-1.0 library which sends the TMP006 register queries and I get a response that is tantalizingly close... (I can get first byte of the contents of the 16 bit register, but never the second). Using Wireshark to compare the supplied Windows software with my own C code... the query packets look identical. There is a difference in the pattern of USB packets: The windows software always has a pair of requests and a pair of responses for each register query. One of the request/responses has a 0 byte payload. I'm obviously missing something.
If I make the Wireshark PCAP files available, I'm wondering if any USB protocol expert might cast their eye on the packet files (it's only about 10 packets) and see what I might be doing wrong. It's my intention to release the working code under BSD licence.
In reply to Joe Desbonnet:
Another clue. Here I am querying the TMP006 0xFE register (manufacturer ID, value 0x5449) and looking at the SDA/SCL lines on H1 with a logic analyzer. Something is going wrong after reading the first byte of data (0x54). But the SDA/SCL trace generated by the Windows software seems identical up to that point where 0x54 is read, but continues with the second byte (0x49). Also I2C stop is missing.
The first screen capture is from my Linux C program (which is sending USB packets to the SM-USB-DIG identical to the Windows software as far as I can see). And the second screen capture is the same query generated by the Windows software.
Perhaps there is some configuration/state that I've neglected to setup correctly.
ccompare that with the same query from the supplied Windows software:
I was searching for 'C' code to communicate SM-USB-DIG(TUSB3210) to run on Linux. From your message it looks like you were able to communicate USB DIG using 'C' code. It will great if you can share that sample code.
In reply to Mamatha Reddy:
Looking for that code now, but it's proving hard to find.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.