2008-07-28 06:06:29     Trouble with multi-message i2c_transfer()

Document created by Aaronwu Employee on Aug 7, 2013
Version 1Show Document
  • View in full screen mode

2008-07-28 06:06:29     Trouble with multi-message i2c_transfer()

Ian Jeffray (UNITED KINGDOM)

Message: 59473   

 

Hi guys,

 

I'm experiencing a strange problem with i2c_transfer(), using 2008R1 on a BF537 STAMP board

 

If I call i2c_transfer() with a single message, it's working fine.  However, if I call i2c_transfer() with two or more messages, I see the first one appear on the bus, then nothing else -- the system has not died, it's simply waiting "somewhere" [And I've not yet worked out where...]

 

Has anyone seen similar issues with i2c_transfer() on Blackfin?

 

The workaround - to use pairs of 1-message i2c_transfer() transfer calls - isn't great as it adds extra delay I'd really like to avoid.

 

Any insight in to this would be greatly appreciated.  Thanks.

 

 

QuoteReplyEditDelete

 

 

2008-07-28 06:21:05     Re: Trouble with multi-message i2c_transfer()

Mike Frysinger (UNITED STATES)

Message: 59474   

 

is the slave properly acking things ?  in other words, is the data you're sending to the slave correct according to the slave's communication protocol (consult the datasheet) ?

QuoteReplyEditDelete

 

 

2008-07-28 07:13:12     Re: Trouble with multi-message i2c_transfer()

Ian Jeffray (UNITED KINGDOM)

Message: 59480   

 

Hi Mike,

 

Yes, I believe that everything is as expected on the wire.   And I'm not changing my source messages between the working/non-working cases, merely making two calls to i2c_transfer() with one message each, rather than supplying both messages in a single call.   The device I'm talking to is a very simple m24c64 Eeprom.

QuoteReplyEditDelete

 

 

2008-07-28 07:38:25     Re: Trouble with multi-message i2c_transfer()

Mike Frysinger (UNITED STATES)

Message: 59483   

 

yes, but there is a long delay (relatively speaking) in between those messages when broken apart that does not exist otherwise, and many i2c slaves treat the SCL line going low for such a long period as meaning "reset itself to handle another command"

 

also, the device itself may not support back-to-back (repeated start) communication

 

i would put a signal analyzer on the lines to see what the signal actually looks like and make sure the slave's datasheet says it can do that

QuoteReplyEditDelete

 

 

2008-07-28 07:46:13     Re: Trouble with multi-message i2c_transfer()

Ian Jeffray (UNITED KINGDOM)

Message: 59488   

 

The two messages I'm sending actually form a single "read" operation ... a "dummy write" of the address to be read, followed by the actual read.  The datasheet shows this all as a continuous stream of data.   The point is that the master (the blackfin) never sends even the start bit of the second message after its sent the first.   I don't have a logic analyser, but I can see this on my digital 'scope.  Even if the device /didn't/ support it, surely the master should be sending the start bit of the next message?

 

 

QuoteReplyEditDelete

 

 

2008-07-28 08:08:23     Re: Trouble with multi-message i2c_transfer()

Mike Frysinger (UNITED STATES)

Message: 59490   

 

you may be seeing a repeated start transaction which the slave may not support.  by forcing two independent reads, you've forced two completely independent transactions.

Attachments

    Outcomes