If I read that trace right you have a 0x64, not 0x32 on the bus. Could be wrong, but is consistent with 32 << 1 in the wrong place... MS
Tommaso Montisci wrote: > Hi Michael sorry I've sent the wrong file!!! > Yes the slave address should be shifted, infact the 2 last bits are the > r/w bit and the ack (not received...). > The 0x32 address should be after shifting, is a 7 bits address. I send > the address through the I2CSA register, after sending the start > condition. What I would expect is an ack so that then I can send my data > (a reading command for example). > Also there should be no conflict on the bus, because I turned off other > chips (I use a tmote sky, so the usart bus is shared with the radio chip > cc2420, which I disabled to avoid conflicts of any kind). > Regarding the pullup resistances, I use the compass with an evaluation > circuit, with capacitors and resistances following the datasheet (page 6). > let me know if you have some ideas, also about the picture... > > I don't do robotics, I do telecommunication but for a project I have to > develop a sensorboard with this compass, an accelerometer, and a gyroscope. > > Thanks, > > Tommaso > > 2009/8/24 Michael Schippling <[email protected] <mailto:[email protected]>> > > Actually I don't see anything but a straight line on the Oscope trace, > but that could just be me... > > The slave address needs to be shifted up one bit in the first byte sent, > because the LSB (bit 8) is the rd/bar-wr bit. It's not clear to me if > that is what you are doing (because I can't see anything in the > picture). > Perhaps that is what you mean by "0x32 followed by a 0 and a 1 (no > ack)"... > > It is also not entirely clear from the spec sheet if the 0x32 slave > address is before or after shifting, have you tried both? > > I'm not familiar with the telos/MSP in this respect. You're sure that > there is no conflict on the I2C bus, and also that you have the pull- > up resistors in place? > > Looks like a nice compass chip. You doing robotics? > MS > > > > Tommaso Montisci wrote: > > I'm using the I2C part of the MSP430 datasheet and it seems very > clear: > http://focus.ti.com/lit/ug/slau049f/slau049f.pdf > From my oscilloscope (scl , sda) the synchronization between > clock and data seems ok, has you can see in the picture attached. > There should be an ack there on the 9th bit? > The slave address should be ok, 0x32, the default address > standing at the datasheet > http://www.magneticsensors.com/datasheets/HMC6343.pdf > > From the picture we can recognize the bits and indeed it is > 0x32 followed by a 0 and a 1 (no ack). > > I do not know what to do... > > thanks, > Tommaso > > > 2009/8/24 Michael Schippling <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > This is the I2C spec for the chip I was fighting: > http://www.nxp.com/acrobat_download/usermanuals/UM10204_3.pdf > It has a (to me) useful description of the spec and > clock/data sequence. > Careful comparison to your observations might turn something up. > Pay attention to the relationship between clock and > data...IIRC the > data must be stable the entire time the clock is active (high > or low, > I don't remember for sure...) > > Are you sure you are sending the right slave address? If the > target > doesn't agree it won't respond. > > Is your TOS MSP I2C implemented in hardware or software? > > MS > > > Tommaso Montisci wrote: > > Hi Michael, thanks for your answer. > > I try to explain you my problem: > I'm able to send the START condition and the slave > address, but > I receive no ACK from my sensor(HMC6343 digital-compass). > I know > that I have sent the right-byte through the Oscilloscope. > Without the acknowledgment it seems that I'm not able to sent > further data to my device (is it true that I need the ack > before > sending data?). > > Have you any suggestions? > > best, > Tommaso. > > > 2009/8/23 Michael Schippling <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> > > > I discovered a "lapse of implementation" in the T1 > atmega I2C > implementation, which is BTW entirely done in bit-banging > software. > I don't use or have access to a T2 tree and haven't > looked at the > MSP implementation, but I might be able to help if you > describe > your problem. > > My problem was when reading multi-byte data from an > I2C device. > According to the spec the slave can request a "wait-state" > between > bytes. The TOS code was ignoring this and getting out > of bit > sync. > > MS > > Tommaso Montisci wrote: > > Hi all, > > I'm working to write TinyOS 2.x drivers for a > 3-axiss digital > compass(HMC6343). > This sensor communicates via a two-wire I2C bus > system as a > slave divice with a microprocessor MSP430. > I would like to know if someone just working in > similar > context > couse I'm in trouble to recive the ack from the > compass. > > Thanks, > > Tommaso Montisci. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> > > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
