How to communicate with unknown I2C device?
sccoupe
Posts: 118
I am trying to figure out how to communicate via I2C with a video converter. This converter resets all of the screen position settings each time its powered down, seemingly by design. The datasheet shows that it has an I2C bus that isn't attached to anything in the box that I'm working on. The idea is to connect a prop to the bus to see if I can read all of the addresses. Then make one adjustment, say move the screen to the left one pixel using the menu buttons on the box, and then read all of the addresses again to see which one changed. This should allow me to then save just that value in the prop and write it back on power up. Pin 56 is pulled high so I guess 0x6A and 0x6B should be used for the slave address. What i'm not sure about is what should be started with as clock speed and what are the best assumptions for addresses? Just start at address 0x00 and go up from there? What is the best I2C object for this task? This would seem pretty easy i guess if it were just a known SD Card or something, but is perhaps tricky given an unknown device. Is any of this even possible without any more information on the protocol or a lost cause without the proper documentation? Thoughts? Ideas?
uP Serial Bus Interface
SCL 59 I IIC bus clocking.
SDA 60 IO IIC bus address/data bus.
ADDR_SEL_FREEZE 56 I Slave address selection.
ADDR_SEL=1: 0x6A for write, 0x6B for read.
ADDR_SEL=0: 0x4A for write, 0x4B for read.
Freeze when hardware mode (falling edge triggerand pull-up externally)
Regards.
uP Serial Bus Interface
SCL 59 I IIC bus clocking.
SDA 60 IO IIC bus address/data bus.
ADDR_SEL_FREEZE 56 I Slave address selection.
ADDR_SEL=1: 0x6A for write, 0x6B for read.
ADDR_SEL=0: 0x4A for write, 0x4B for read.
Freeze when hardware mode (falling edge triggerand pull-up externally)
Regards.
Comments
It sounds like you want to listen in on the I2C bus while you induce commands on another bus. This won't do anything: you won't hear anything on the I2C bus.
Why not look up the video converter datasheet?
Yes, the slave address seems to be 6A and 6B which fits a standard 7 bit address. There is currently no I2C traffic because there is only the video converter at the moment with nothing hooked up the the I2C pins. I want to attach a master (prop) and start talking to the converter to figure out what the register addresses are. I have the data sheet, but it is limited. The only mention of I2C is what you see above. The company that manufactures the chip and the company that makes the device are in China and have been contacted multiple times via email with no response.
Often a register will have multiple bits assigned to some function with other bits assigned to a different function. So you not only need to figure out what the various registers do, you need to figure out what each bit within the register does. IMO, this video converter would have to be capable of some amazing things in order to make it worth your time to figure this out from scratch.
Here is the link to the conveter box that is sold everywhere for as little as 10 bucks.
http://www.lenkeng.net/YPbPrzhuanVGA/lenkeng67.html
Here is the link to the datasheet for the converter chip used in this device.
http://wenku.baidu.com/view/88627b87bceb19e8b8f6bab0.html
Its not that it does anything spectacular. Its that it does everything that I need it to do EXCEPT save the screen adjustments on shutdown and does it real cheap. Its possible that I dont need to know what each bit does, just what registers change when I move the screen left or right for instance. Those are the registers that I need to poll and save for re-writing at boot up. This shouldnt bee too difficult unless these registers are changing constantly during normal operation. So in theory, take a snapshot of all of the registers that will answer a read call, move the screen to the left, take another snapshot to see which register changed. Now I would know that that register stores left to right screen position. Now do it again for up and down, then again for stretch vertical, and once again for stretch horizontal and I'm all done......In theory. Is this a good high level theory or are there wrenches waiting to be thrown into the gears?
I understand better what you want to do. Thanks.
So do you make these screen adjustments with the buttons on the front of the device? What about simulating button presses by having the Propeller trip relays which are connected internally to the buttons. Have the Prop remember what settings you want and have it automatically "press the buttons" needed to get these settings.
A better idea would be to snoop on the I2C traffic between the converter box and I2C device it uses as you adjust the screen. You could then have the Propeller send these same I2C commands to make the desired adjustments.
Correct, the better idea would be to use I2C. However, there is no snooping to do, because the I2C pins are not connected to anything in this box. Its just a feature on the chip that isnt utilized by this particular product. So, I need to setup a master I2C device to connect to these unused I2C pins on the chip and read/write these unknown registers as needed.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 SCL_pin = 0 SDA_pin = 1 VAR byte buffer[512] OBJ I2C : "I2C Spin Driver v1.2" FDS : "FullDuplexSerial" PUB Main | index FDS.start(31,30,0,115200) I2C.start(SCL_pin,SDA_pin) if \I2C.read_page({device_ID},0,@buffer,512) ' read 512 bytes from device into buffer, starting at register 0 FDS.Tx($00) ' display the register contents in an easier-to-read format index := 0 repeat 512 / 16 FDS.Hex(Index,4) FDS.Tx(" ") FDS.Tx(" ") repeat 16 FDS.Hex(buffer[Index++],2) FDS.Tx(" ") FDS.Tx($0D) else FDS.Str(string("no response"))It's essentially the same routine I used for my EEPROM demo, you probably (hopefully) won't have too many registers to compare. And hopefully it follows all of the standard conventions for address lengths and auto-incrementing registers.Great idea.
If the register content is examined before the screen settings are changed, and after the changes have been made, then this information could be used to set the registers to the desired settings in the future.
Another thought I'm having is that there is an xreset pin that sets all register values to default according to the data sheet. This pin is connected to a transistor presumably for switching. Perhaps the chip is actually saving the changes but being reset on powerup by design to auto detect resolution or something. Cutting this trace should answer this and maybe save some this work, but at this point I2C investigation needs to be done just because.
ADDR_SEL=1: 0x6A for write, 0x6B for read. Becomes device ID $35
ADDR_SEL=0: 0x4A for write, 0x4B for read. Becomes device ID $25
Obviously if you could interactively talk with the chip it would so very easy, you could examine contents, write contents, write one-liners etc. This is what I do all the time with Tachyon Forth and then I build named methods such as CHAN for instance so that if I can just type "3 CHAN" to switch the channel without having to worry any further. Tachyon already has all the utilities built in to the scan the bus and dump contents etc.
Are you sure the i2c can reflect, and set, the operations, that the buttons control ?
If you really want to use i2c, can you find a variant product that does connect the i2c, so you can at least get some working traffic to decode ?
Not many ASICS have power off storage inbuilt, as that costs a lot more to fab.
If you just want to emulate a config setup, it may be smarter to simply record/playback on the buttons.
Experiment with the delay needed for first press after POR and at what rate you can 'press' on playback
I mean, does it use the I2C bus to receive commands from an MCU, or simply to store configuration data off-chip, to be read back in on startup?
Some of these devices don't truly power down, but rather enter a low-power standby mode- might be another consideration.
Just grab one of the Tachyon binaries which also has the word .I2CBUS in there which will list out devices and their basic contents. Connect serial terminal at 230400 baud.
.I2CBUS
Fast Device at 00A0 00 00 00 00 00 00 00 00
Fast Device at 00A2 52 4D 82 C4 01 07 43 4F
Fast Device at 00A6 00 3B 58 08 6F 4E 10 00 ok
Thanks Peter. This was up and working pretty quickly and easily. It seems that the wiring connections may be good. Perhaps you can take a look at the results. The first .I2CBUS was run without anything hooked up. Presumably 0xA0 is the EEPROM on the Prop board. The second and third .I2CBUS runs were with the video chip hooked up. It seems like a lot of noise or something causing all of this or is this a normal thing? A0 is not in either of the other two calls...
Probably be a bit easier to read if you turned off echo and extra line feed or if you can't then just use TeraTerm. Anyway, it looks like there is activity on those lines I guess. You could try pasting in this next line and then invoking it by name "MON" which will simply spit out a digit representing the I2C lines, 3 = idle, 2 = clock low data high, 1 = clock high data low, 0 = clock low data low.
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ;
You can terminate the monitoring by hitting the escape key.
No pullup detected on SDA Polling I2C bus for devices 7-bit ID Device type - not all inclusive 0000000 unknown 0000001 unknown 0000010 unknown 0000011 unknown 0000100 unknown 0000101 unknown 0000110 unknown 0000111 unknown 0001000 unknown 0001001 unknown 0001010 unknown 0001011 unknown 0001100 AK8975C magnetometer 0001101 unknown 0001110 unknown 0001111 unknown 0010000 unknown 0010001 unknown 0010010 unknown 0010011 unknown 0010100 unknown 0010101 unknown 0010110 unknown 0010111 unknown 0011000 unknown 0011001 unknown 0011010 unknown 0011011 unknown 0011100 unknown 0011101 ADXL345, MMA7455L accelerometer 0011110 HMC5843 / HMC5883 compass 0011111 unknown 0100000 IO expander - various types 0100001 IO expander - various types 0100010 IO expander - various types 0100011 IO expander - various types 0100100 IO expander - various types 0100101 IO expander - various types 0100110 IO expander - various types 0100111 IO expander - various types 0101000 unknown 0101001 unknown 0101010 unknown 0101011 unknown 0101100 unknown 0101101 unknown 0101110 unknown 0101111 unknown 0110000 unknown 0110001 unknown 0110010 unknown 0110011 unknown 0110100 unknown 0110101 unknown 0110110 unknown 0110111 unknown 0111000 BMA150 accelerometer 0111001 unknown 0111010 unknown 0111011 unknown 0111100 SSD1308 128x64 display driver 0111101 SSD1308 128x64 display driver 0111110 unknown 0111111 unknown 1000000 IQS156 touch sensor 1000001 IQS156 touch sensor 1000010 IQS156 touch sensor 1000011 IQS156 touch sensor 1000100 unknown 1000101 unknown 1000110 unknown 1000111 unknown 1001000 AD7745 / AD7746 capacitance to digital converter ADS1113/4/5 16bit analog to digital converter 1001001 ADS1113/4/5 16bit analog to digital converter 1001010 ADS1113/4/5 16bit analog to digital converter 1001011 ADS1113/4/5 16bit analog to digital converter 1001100 unknown 1001101 unknown 1001110 unknown 1001111 unknown 1010000 24LCxxx EEPROM 1010001 24LCxxx EEPROM 1010010 24LCxxx EEPROM 1010011 ADXL345 accelerometer alternate address 24LCxxx EEPROM at address 3 1010100 24LCxxx EEPROM 1010101 24LCxxx EEPROM 1010110 24LCxxx EEPROM 1010111 24LCxxx EEPROM 1011000 unknown 1011001 unknown 1011010 MPR121 touch sensor 1011011 MPR121 touch sensor 1011100 MPR121 touch sensor 1011101 MPR121 touch sensor 1011110 unknown 1011111 unknown 1100000 MPL3115A2 altimeter 1100001 unknown 1100010 unknown 1100011 unknown 1100100 unknown 1100101 unknown 1100110 unknown 1100111 unknown 1101000 DS1307 real-time clock L3G4200D gyroscope with SDO low MPU9150 gyroscope and accelerometer with AD0 low 1101001 L3G4200D gyroscope with SDO high MPU9150 gyroscope and accelerometer with AD0 high 1101010 unknown 1101011 unknown 1101100 unknown 1101101 unknown 1101110 unknown 1101111 unknown 1110000 unknown 1110001 unknown 1110010 unknown 1110011 unknown 1110100 unknown 1110101 unknown 1110110 MS5607 altimeter with CSB high 1110111 BMP085 pressure sensor MS5607 altimeter with CSB low 1111000 unknown 1111001 unknown 1111010 unknown 1111011 unknown 1111100 unknown 1111101 unknown 1111110 unknown 1111111 unknown FinishedYour device is in the same address range as my I/O expander, which is where I first encountered that problem.
That might also explain my poller finding something on every address. Those pullups are entirely too large; they should be somewhere in the 4.7K to 10K range. The poller even stated that it didn't detect a pullup on SDA, which means it was using a driven-output version. Again, the same issue as with the Prop bootloader trying to force a clock high that the slave is holding low.
Yes, right now booting from EEPROM using your I2C code. Attached to pins 8(SCL) and 9(SDA) with nothing else attached to those pins, save the pullup resistors.
While using Forth, I had to use pins 28 and 29 because I didnt know how to change them. OBEX is back up now so i'm trying some of your stuff out.
How do you know those lines are I2C? You must have some information on them and anyway if it's I2C there might already be another micro in there that's talking to it. Either way you should see some break in the listing. Just in case here's one that does a quick capture to a buffer then dumps it, a FF just means nothing is happening.
#1024 BYTES i2cbuf
pub MON BEGIN CR i2cbuf #1024 ADO P@ #24 SHR I C! LOOP i2cbuf #1024 DUMP ESC? UNTIL ;
You can use other port pins for I2C bus, if they are for instance P24 = SDA and P25 = SCL just type:
#P24 #P25 I2CPINS
Then try .I2CBUS
The datasheet (http://wenku.baidu.com/view/88627b87bceb19e8b8f6bab0.html) says they are IIC pins. There is no other micro on the converter board and these two pins are currently unused. I wish to make use of them.
You may need to add pullup resistors then as the datasheet seems to indicate that there are none on the chip and that may be the case with pin 56 (ADDR_SEL_FREEZE) too,
I'm going to try re-soldering the wires by gluing them down first and then hot air soldering with paste. At that point, i'll verify with an ohm meter whether or not they are connect to ground.