TWI/I2C Bus free time

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe someone can help or have a solution for my current problem,

I have a prototype PCB with one ATmega128 & two ATmega8s.
They are connected to eachother with I2C/TWI.
With this prototype I planned to make a TWI library for multi-processor communication in the multi-master mode. This I have done before with philips chips like (80c552), the TWI module of the ATmega is actually have the same kind of state machine so I tought this would be not that difficult...

But my experience is that the ATmega's are working unstable at their TWI port.
This unstable behaviour only appears (often) if I use more than two devices (in multi master) with an high bus-occupation.

First of all I have checked a lot on the forum and verified this in my code:

1) no '&=' or '|=' used in the ISR to prevent early acknowledge of TWINT
2) Made the STOP-status (0xA0) as short as possible to prevent the TWI-hardware holding while a new start is on the bus (the ISR for 0xA0 is now 1.2 uS).
3) disable/enable 'restarts'.
4) lower the baudrate using TWSR
5) lower the baudrate using TWBR, TWBR always was higher then 10 like specified.

But nothing seems to help.

Finally I decided to work at 80kHz, which is 20% below 100kHz to ensure the "buss free time is 4.7 uS". Because I doubted this free time....

- My question is: How can de TWI decide if its <100kHz or >100kHz ?
(I'm using Xtal: 14.7456 Mhz because UART speed)

Finally I started to make a 'stop' detection with an external IC (4013, a FLIPFLOP).
When I trigger on the detection output and look at my scope it shows curious things...

Tbuf = "Buss free time" specified by philips at 4.7 uS for lower than 100kHz and 1.3 uS for higher then 100kHz. ATMEL did also specify these numbers in their TWI (ATmega) datasheets. But on my scope I can see this buss free time sometime is as short as:

700nS !! :(

My ISR will never be able to be that short i guess...
What I see is that somtimes after such short free time an other device generates a illegal start... (In a high clock cycle when data is high...)

This generates in the other devices a state: 0x00 (buss error) or 0x08 (Start) or 0x10 (repeated start for the master device at that moment).
After this situation the bus FREEZES (SDA low, SCL High), and I have the toggle TWEN on all devices or use reset before the system is up and running again....

I hope someone knows a solution or can confirm this problems. Is these problems are not easy to solve I guess I cannot use ATMEL chips in my applications... but It would be strange if they do not work conform the Specifications !

Regards,

Anton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

afaik the bus free time is the time you (and any other device on the TWI) is in the STOP state (SCL and SDA are HIGH). It has to be software controlled. If the bus is >= 4,7us in STOP then every device on the bus can detect a free TWI. Now any device can START and try to transmit data. The sending device has to re-read it´s sent data. since the TWI is connected with OpenCollector and PullUps a collision can be detected if the sent data is not the same that you read back (there will be additional LOWs, because of it´s wired-AND behavior). If a collision is detected every device should free the bus by sending a STOP. after the bus free timeout a random wait time shall be included to ensure that one device is slower than the other with retrying to send data via the TWI. The faster device wins the bus, the slower device have to wait until the bus is free again.

This is my understanding of BUS FREE. But i am not sure because i have never done sth multi master with TWI.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HI,

The I2C/TWI bus free time should not be software controlled, this because you have to set a TWSTA bit (start bit) and the TWI hardware will automatically set the start condition if the bus is free.

this 'automatically' should take care of the bus free time... thats not true at the Atmega processors in my opinion. It is simply not possible to do in software for the cpu because internal you only know it the CURRENT device is sending, receiving or doing nothing.

You don't have the information in the CPU if the TWI/I2C bus is used by other devices.
This makes it impossible in the multi-master-mode to have a software solution.

Thanks for your help,

Anton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Anton,

* deciding TWI speed:
YOU!! have to decide which speed to use:
there is a standard philips low speed rate of max. 100kHz and
there is a fast mode IIC Bus specified. It depends on the connected devices what max. speed you can use.

* the slowest device gives your max clock speed

* tbuf has to be at least one complete low period of scl (although SCL is high here)

* be careful with using TWEN!! disabling the TWI selects the standard port settings defined by DDRx and PORTx. This can cause illegal states and timings on the TWI bus!

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Klaus,

Ofcourse I know its possible to setup the TWBR and TWSR for the correct speeds. And i can do because I know the XTAL speed. but internally the AVR does not know the frequency of the XTAL. So how can the internal TWI buss decide to use 4.7 uS or 1.3uS ?
Actually I think they don't care about 'bus free time' so do not comply their specifications!!

I know the minimum requirement of the Tbuf, but thats dependend on the TWI module hardware.... in a multi processor enviroment its something you can not prevent with software!

So still my question is if more people have this experience? or know about this?
maybe have tested a multi-master enviroment...

How can it be ATMEL does not specify the correct specs??
Its even freezing the buss in some situations.... In my opinion its something
happening on ALL CPUs with a TWI module. So becarefull using a
MULTI-MASTER system.....

Regards,

Anton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aprins wrote:

I have a prototype PCB with one ATmega128 & two ATmega8s.

This unstable behaviour only appears (often) if I use more than two devices (in multi master) with an high bus-occupation.

Is it always the same device that causes the problem? Can you isolate the problem to a specific device?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No its just random depending on the amount of data on the bus,

Anton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that while the AVR's TWI is I2C compatible, to a certain degree, it is not I2C by name, and thus is free to deviate from the I2C spec. So there may be certain steps you need to take in software, to remain within the I2C spec.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi glitch,

Ofcourse the name is different ( i guess a royalty thing....).
But the intentions still is to be compatible to I2C.

I agreed TWI is free to deviate from the I2C spec, but they have copied the
I2C timing specs to the AVR-TWI timing specs:

tBuf = 4.7uS < 100 kHz
tBuf = 1.3uS > 100 kHz

but this is not the case! so they deviate from their own specs as well. And if we think of our goal it is to have a common communication method. I think their is no doubt.

but I'm just wondering how i can solve this problems.... so the TWI is just conform the TWI-specs. TBuf = 4.7 uS

Thanks a lot for your reply,

Anton

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has this been solved yet?

I think I am having the exact same problem.

I am using 4x ATMega128s on a TWI bus (all on the same board), with interrupt driven TWI comms code in avr-gcc, all in multi-master mode.

For a test I am sending/recieving packets randomly between devices at a fairly high rate, and eventually the bus 'dies' with one of the devices holding SDA low.

Debugging using duplicate sets of LEDs local to each chip (each chip is running the same code, with different addresses) to display what the TWSR was for each device when the last interrupt occured.

Usually one chip ends with a TWI_MASTER_DATA_ACK (at that point the software protocol setting a TWSTO to generate the end of the packet), all other chips are stuck at TWI_START.

This is completely random, it sometimes works for anywhere between 10 minutes to 10 hours before 'crashing', also depending heavily on bus load.

For peace of mind while debugging there are no other interrupts used on this chip except the TWI interrupt, all start transmission/recieve code is done in a polled main() loop for testing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you read appnote AVR300: Software TWI Master Interface? It talks about software implimentation of the delay time. Look in the tools section of this site.

Laurence Boyd II

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to wake up an old thread but I've been caught by this exact issue and found some reasons so I would like to add some conclusions here for further reference and completeness.

The issue is described in this thread:
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=11516&highlight=i2c+multi+master&sid=e54519fa884e98196edfa82025eb7de9

Basically, it seems the TWI hardware is partly disabled when the interrupt (TWINT) is set, waiting for processing. This is fine for all status where the slave can hold the bus while processing and release only at the end. But a STOP can't be hold so from the STOP until TWINT is cleared, the slave TWI hardware is somehow disabled. If the master issues a new START to the same slave during this period, the slave can't detect it.

This can lead to the slave not seeing the START which is not a big deal since the master will reissue it later on.

If the slave also has a start to issue, usually the bus crashes. When the slave exits it's ISR, the master is already issuing it's START then it looks like the slave thinks the bus is free (when TWINT is cleared) and also tries to issue a start which freezes the bus.

Solutions to this:
- try to deal with the STOP condition and clear TWINT in the salve as soon as possible in the ISR
- if you have control of the master, add some delay between a stop and a start
- use RESTART instead of a stop and a start

Hope that may be of some help to someone. This is only my understanding and may be wrong on some points but at least that solved my problems.

David