Hi Sebastian, On Fri, Dec 9, 2011 at 2:30 PM, Sebastian Dölker <sebastian.doel...@hs-karlsruhe.de> wrote: > Hi Andris, > > Yesterday I continued with my i2c problems and discovered the following: > > The debug values: > 20:03:44 "cmd" 0x00 0x00 > 20:03:44 "ir read done.." > 20:03:44 "init" 255 3 > 20:03:44 "cmd" 0x04 0x01 > 20:03:44 "cmd" 0x25 0x01 > 20:03:44 "int" 0x08 0x01 > 20:03:44 "cmd" 0x45 0xb5 > 20:03:44 "int" 0x40 0xb5 > 20:03:44 "cmd" 0x45 0xb5 > 20:03:44 "int" 0x00 0x6a <- bus error > 20:03:44 "cmd" 0x05 0x6a > 20:03:45 "*start*" > 20:03:46 "*start*" > 20:03:46 "bb read done.." > 20:03:46 "***start***" > 20:03:46 "cmd" 0x04 0x6a > 20:03:46 "*error*" <- error means EBUSY is returned.. > 20:03:47 "***start***" > 20:03:47 "cmd" 0x14 0x6a > 20:03:47 "*error*" > 20:03:47 "bb read done.." > 20:03:48 "***start***" > 20:03:48 "cmd" 0x14 0x6a > 20:03:48 "*error*" >
Thanks, it's much more easier to fix with this help. > So the i2c-status is 0x00. > According to the atmel128 datasheet page 224 this means bus error. > To recover one should set TWSTO flag and clear TWINT („by writing a logic > one to it“?!) Yes, the TWINT flags seems a bit illogical, but that's how you can clear it. This translates to send a stop condition (TWSTO), and clear the interrupt flag. > I didn’t find this procedure in the device driver sources. Is the bus error > state handled in the driver? You're right, it doesn't handle it. Actually I don't like the interrupt handler (I2C.commandComplete) at all, since it doesn't care with the TWSR, it persumes that with its own internal state variable. However, when I fixed some of the bugs in this, I wanted to change as little as possible, becouse it's an old component, and some users may count on this not quite good solution. > I tried to add this procedure but I wasn’t successful.. > Must this be added in the driver? > Have you an idea where? I attached the modified dirver, but I just tested it with a working i2c sensor. It should do the recovery procedure, disable the i2c interrupt, and return with FAIL. > > One more, in the attachment I added a picture of the sequence while the > error occurs. > Channel 1 is i2c-clock, channel 2 i2c-data. At the beginning the i2c sensors > are read out successfully. > Then a sensor pulls clock low for ca. 2.3 seconds. Probably because of that > the bus error occurs. The atmega1281 datasheet mention that bus error only occurs when an illegal start/stop condition happens. It would be more intresting to see the last part of the failed communication in detail, to check for this. Although if that's the case, we couldn't do much more, a slave device should never send start/stop, so this is a bug in your sensor. Handling bus error interrupt should fix it, but it's just a workaround. Andris > > Thanks in advance! > Best regards > Sebastian
Atm128I2CMasterPacketP.nc
Description: Cdf file
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
