TWI Slave problems

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

Hi Guys

 

I've been making steady process on my AVR slave implementation but I'm having a few issues while testing

 

Setup

Atmega328p as slave writing to a display via SPI

Arduino Uno as master using wire library

Cable length 4"

Pull up resistors (4.7k) installed on both lines

 

Issue

 

The master is sending an 8 byte sequence 4 times repeatedly to the slave.

If I put in a delay(1) after each 'end transmission', it works fine.  If I don't, some sequences appear to the 'lost'

 

The slave is interrupt driven, a section of the ISR is as below

 

ISR(TWI_vect)
{
	switch(TW_STATUS)
	{
		case TW_START:
			break;
		case TW_SR_STOP:
			if(TW_BuffPtr != -1) //there's data in the buffer
				TW_RxProcBuffer(); // Process recieved data

			TWCR = (1<<TWIE) | (1<<TWINT) | (1<<TWEA) | (1<<TWEN);
			break;
		case TW_SR_DATA_ACK:
		        // received data from master, call the receive callback
		        TW_recv(TWDR); // Process byte and put it in receive buffer

		        TWCR = (1<<TWIE) | (1<<TWINT) | (1<<TWEA) | (1<<TWEN);
		    break;
		    ....................

 

My understanding that until the following is set, communication is paused while I process the data following a stop condition

 

TWCR = (1<<TWIE) | (1<<TWINT) | (1<<TWEA) | (1<<TWEN);

Am I missing something?

 

regards

 

 

 

 

Last Edited: Wed. Jul 31, 2019 - 09:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nikm wrote:
My understanding that until the following is set, communication is paused while I process the data following a stop condition

 

All that I can find in the datasheet is that the clock line is held low (pausing the TWI master)

after the slave recognizes its address when the uC is in sleep mode.

 

 

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

Thank you,

 

I wonder if this is not an TWI issue at all. (I'll fire up a logic analyser to confirm).  It may be the displays.  The slave is talking to 4 MAX7219 chips and I wonder if I'm refreshing too fast for the data to propagate.  The specs shows the MAX has a ~2ms data to display time.  Some of the Arduino examples suggest a 100ms delay before refresh.  This might explain what I thought was a buffer over Write condition.  Perhaps a 10ms delay after a display refresh might do the trick.

 

regards

 

 

 

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

Have you looked at Atmel app note AVR311?
Jim

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

ki0bk wrote:
Have you looked at Atmel app note AVR311?

 

Good find!

 

On page 5

As long as the TWINT Flag is set, the SCL line is held low. This allows the application software to
complete its tasks before allowing the TWI transmission to continue.

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

Hi,

 

I have indeed, but it didn't help me though.  Firing up the protocol analyser showed that the slave was sending a NACK at times when being addressed with a write operation. 

 

I'm processing the write registers with SPI writes to a number of MAX7219's which can take some time.  When I received a STOP from the master I was processing the buffer and then sending the following

 

TWCR = (1<<TWIE) | (1<<TWINT) | (1<<TWEA) | (1<<TWEN);

 

Sending the above before processing cleared up the issue. (still testing)

 

I also found that the case of a BUS_ERRROR  the following from the app note didn't seem to clear it.

 

TWCR =   (1<<TWSTO)|(1<<TWINT); //Recover from TWI_BUS_ERROR, this will release the SDA and SCL pins thus enabling other devices to use the bus

 

but this did, though I have no Idea why

 

 

TWCR = 0;

TWCR = (1<<TWIE) | (1<<TWINT) | (1<<TWEA) | (1<<TWEN);

 

 

Anyway, thanks for all the help Guys, much appreciated.

 

regards

 

 

Tiny video of an UNO talking TWI to a 328P as fast as it can to a 32 digit display