I2C in circuit Debugging question - Help a Jar Head

[MarineCorpsComm]

Hello Prop heads... This Marine is looking for some help ... before I go crazy (and we don't want that http://forums.parallax.com/images/smilies/nono.gif )

I am working on debugging traffic on an established circuit that is using I2C between a micro and a... lets just call it slave chip A.

I thought it would be a good idea to lend another Marine my USB <--> I2C adapter and have been trying to decode this traffic for the past 4 hours with a scope and a notepad. Needless to say my eyes (and brain) hurt. So... I decided to dig out my prop and use it to aid in the process. I started to rip apart the objects from exchange, however I have hit a roadblock. (It's always the things that sound so simple in your head that end up taking the most time) My first issue is that I am unsure if I need to use the SCL line, or since I am just trying to "sniff" the traffic, I could just use the SDA and a ground?... I am definitely seeing structured data on the scope, viewport, and EventLogger with just SDA and the ground.

Since the 'read' commands in the objects I have tested assume that you are sending a read request, and know the address of what you are looking for.... I am just lost in the sauce without starting from scratch.

All I want to do is be able to spy on those little bits and dump them out as hex to a term with some sort of deliminator. In my delirious mind something that looks like :

[DeviceID2] XXX Write / Read [DeviceID2] [Data]


PS. For any curious people that dream about the many ways other folks use Parallax products. I use the BS2 and Prop on all sorts of tactical satcom gear while trouble shooting. It saves me having to haul out an a scope, sig gen, cables, power supply to the field. All I need is a 9volt and a small LCD or sometimes just some LEDs and a bunch of jumper wires... and it all fits in my cargo pocket. For things like.... reading external GPS clock rates, verifying a sat modem is in loopback... or even bit bang a simple baseline router config WITHOUT a laptop <Thanks Kye the FAT SD object will work perfectly for storing configs) ... awesome stuff. This forum is great.

I appreciate any help. Just picture a sad Marine with his notepad and dirt covered O-scope http://forums.parallax.com/images/smilies/cool.gif

[Timmoore]

Take a look in this thread for a i2c logger from hippy http://forums.parallax.com/forums/default.aspx?f=25&m=263511

[T Chap]

You will need SCL and SDA to sniff lines, but will probably have to create a new program or modify something from an object. Take a look at Minimali2cdriver. See the example below to understand the protocol. I2C always starts with a START + ack. Then follows with an address byte + read/write bit + ack. Then the payload follows depending on whether it was read or write, if write then the side that started the START will send its payload, otherwise the receiver will respond of it was a READ. After the payload will be a STOP. You can scan through the driver mentioned above to understand what makes up a start and stop. You would need to write some code that identifies a START and STOP, these may or may not be valuable on a LCD or display, but the data in between will be what is of value, and can be displayed as hex, dec, ascii or whatever is needed. Hopefully someone else will have some more ideas.






i2c2.i2cStart(i2cSCL2) 'START
i2c2.i2cWrite(i2cSCL2, KPaaddr + 0) 'address + read or write bit (0 or 1) 1 = read 0 = write(send some payload next)
i2c2.i2cWrite(i2cSCL2, tmpvar) 'payload
i2c2.i2cstop(i2cSCL2)

i2c2.i2cStart(i2cSCL2)
i2c2.i2cWrite(i2cSCL2, KPaaddr + 1) 'start the read
readkeyvar[ 0] := i2c2.i2cRead(i2cSCL2, 0) 'lsb begin 4 bytes of payload
readkeyvar[ 0] |= i2c2.i2cRead(i2cSCL2, 0) << 8 'msb
readkeyvar[ 1] := i2c2.i2cRead(i2cSCL2, 0) 'lsb
readkeyvar[ 1] |= i2c2.i2cRead(i2cSCL2, 1) << 8 'msb
i2c2.i2cStop(i2cSCL2) 'STOP



Post Edited (Todd Chapman) : 6/5/2010 4:15:25 AM GMT

[lardom]

Thank you for your service.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

[MarineCorpsComm]

@Timmoore / Todd Chapman

Thanks for the suggestions. I'm heading back to work now to give it another try. I will update progress.

@Lardom You are welcome. I joined when I was 17, 11 years ago and I love it.

[MarineCorpsComm]

@Timmoore

Thanks for the great code from the posts between you and hippy. I was able to get the I2c logger working after using your scan routine to help identify the unknown nodes. Sometimes I still get some wild addresses that say they got an ACK, even though they are not connected to the system. I'm re reading the Phillips guide to better understand the special circumstances of using 10 bit addressing.

I think it's time to put together a debugger framework that allows us to use a prop just like a bus pirate , or any other bus analyzer solution. More to come

[Zap-o]

I see it a lot so I am going to ask. What is Bit Bang mean?

[MarineCorpsComm]

@zap-o

Bit banging is when you use software to simulate the job that hardware would normally do. For example in serial communications a hardware UART handles the timing and buffering of data so the programmer does not have to worry about things on such a low level. In the end we know that when it comes to data flowing on the wire it all comes down to 1s and 0s, represented by high and low states. This means that if we have digital control over line states, like in a micro, we can emulate any signal we want, without additional hardware. No matter how complicated the protocol, it's just highs and lows.

In the case of protocols like SPI, I2C you will see other micros that contain the on board hardware to communicate with these natively. As a coder all you have to do is send some data to the bus and it worries about the line syncing and that voltage levels are returned to an idle state after the data has been sent...etc. When we want to do something like this on the prop you will find objects that were written that contain hundreds of lines of code implementing all of the low level routines that emulate that hardware. When you implement one of these objects, you can pretend that you have native support, since someone else has done all the hard work.

Bit banging when you take it at face value, is nothing more than BANGING or forcing the bits onto the line.

Hope that helps a little.

[kwinn]

Bit Banging generally refers to having program code emulate the hardware required to send a serial data protocol. The "FullDuplexSerial.spin object is an RS232 bit banging program as are the 1-wire, SPI, I2C, and quite a few of the other objects in the Protocol section of the OBEX.