AVR Freaks

Following up on this.  I can't seem to make clock stretching work to hold off the master until I am ready with data. 

AVR311 clearly states:  "If a Slave device cannot handle incoming data until it has performed some other function, it can hold SCL
low to force the Master into a wait-state."

The ATmega324 Data sheet says: 

    "As long as the TWINT Flag is set, the SCL line is held low."

and

     "Writing a one to TWINT clears the flag."

The Interrupt flow chart in AVR311 (fig 2-3)  clearly shows that "Receiving a stop or repeated start while still addressed as a slave"  should then disable the TWI interrupt and NOT clear the interrupt flag.   

Now the code for this condition in the AVR311 ISR is as follows:

    case TWI_SRX_STOP_RESTART:       // A STOP condition or repeated START condition has been received while still addressed as Slave    
                                                        // Enter not addressed mode and listen to address match
      TWCR = (1<<TWEN)|                                 // Enable TWI-interface and release TWI pins
             (1<<TWIE)|(1<<TWINT)|                      // Enable interrupt and clear the flag
             (1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|           // Wait for new address match
             (0<<TWWC);                                 //
      
      TWI_busy = 0;  // We are waiting for a new address match, so we are not busy
      
      break;           

The code and the flow chart don't seem to agree.  The flow chart suggests when I receive the STOP condition from the host the AVR should hold the clock line low until the calling routines restart the I2C bus.  The code though seems to simply clear everythign and exit.  

Has anybody seen the Clock held low (clock stretching) by this code?  I need time between the host doing an address write and a data read in order to create and fill the buffer with the response data.    As is I have no way to hold off the host so it occasionally reads back the write data since there is only one buffer.

Thanks in advance for any help/comments

Hi Jim,

For my application the the last thing the host sends me is a byte indicating what data it wants.  It then immediately sends me a byte read command and expects the data to be ready.  

At 100KHz the only thing between the ID byte and the need for the data is the slave address byte for the read.  That is only about 100uSec.  

If I did the the reply data formatting in the ISR I could probably hit this but the reference app code is setup assuming you fill the buffer in the calling non ISR code.   At the moment I do that in a round robin background loop so I don't always hit 10uS and thus I get errors.   I just need some way to let the host know it has to wait for me to fill the buffer.  

The app note flow chart implies this is done in the ISR by not clearing the interrupt flag.   

My understanding based on what I have been reading today is that the slave can hold off the master by holding the clock low during any low phase of the clock.  So I could even do this in the middle of the the address byte of the read.  Or even the ack of that byte?   The TWI though is byte oriented so I think it would be on the first clock of any byte.  ???  Still working this all out.

Still looking for somebody else to confirm that clock stretching doesn't work on this code. 

Dave

Thanks!  

Against all my general tendencies I thought this time, no I won't code this myself.  It's 2020 after all, there has to be an off the shelf driver that works.  Right?  

The requirements for what I want to do are pretty simple.   I am going to do my own simple interrupt driven driver in the next day or two.  Will advise.  Appreciate the input.

Dave

Took a peek at that one and unfortunately it is a bit banged implementation.  I've used bit banged Masters before but in this case I don't think this will fly.  My host needs to run the clock pretty fast since I am sharing  the bus with a another part that has some fairly high throughput requirements.   I also have some other time critical high sample rate ADC stuff going here on the ATmega324.  Somewhat DSPish multi channel Analog sensor conditioning.   

At the moment my plan is to try and "fix" the AVR311 code without starting from scratch.  It seems as though if I make the code follow the flow chart in the app note it will do what I want.   

Thanks for all the ideas/suggestions.  Will report back on my progress.

Dave

Minor update.  The ATmega324 does not seem to like to be clock stretched at the start of of an address byte.  If my master timing is such that I don't need to clock stretch everything works perfectly.  If I pull in the read back so that I get any clock stretching, the address byte for the read transaction immediately after the clock stretch is not decoded properly and not ACK'd.  Interestingly my address+R byte is 0xB1 (10110001) and if I look in the TWDR after a failed address (No ACK) I see 0x63 (01100011).  Sort of looks liek a rotate by 1 bit of the correct data.    The Saleae though think it is a perfectly good address byte.   

My AVRINT# line shows pulses on any TWI interrrupt and I never get one under these circumstances.  

Here is a normal read with no preceding clock stretch.

I do see a few threads with some mention of missed address ACKs.  Need to do some digging.  Suggestions welcome.