I2C Slave with new AVR MCUs pulls SDA / SCL to LOW

I tried I2C with the new AVR MCUs. For the master MCU it works fine.
But strangely the slave will pull down SDA and SCL after initialization (TWCR = (1<<TWEA)|(1<<TWEN)|(1<<TWIE)).
For the slave the pins should stay an input at high impedance.
It looks like TWSTA was set, but i haven't seen (and didn't toggle) the bit in TWCR.

Code:

#define F_CPU 8000000UL
#define F_SCL 100000L //100 kHz

// Include of Header-files
#include <avr/interrupt.h>

// constants
#define SET_BIT(PORT, BIT)  ((PORT) |=  (1 << (BIT))) // set Port-Bit
#define TGL_BIT(PORT, BIT)  ((PORT) ^=  (1 << (BIT))) // toggle Port-Bit

int Address = 0b0001010;

int main(void)
{
 SET_BIT(DDRD, PORTD1);           // define debug pin
 TWSR = 0x00;                     // clears status code register and all prescalers.
 TWBR = ((F_CPU/F_SCL)-16)/2;     // sets bit rate
 TWAR = (Address<<1) + 0;         // sets address
 TWAMR = 0b11111110;              // sets address mask
 TWCR = (1<<TWEA)|(1<<TWEN)|(1<<TWIE); // enable acknowledge, enable TWI, enable interrupt
                                       // with TWEN=1 SDA and SCL are pulled to low
 
 while (1)
 {
    TGL_BIT(PORTD, PORTD1); // just for debugging  
 }
}


Thank you very much.
I will have a look.

All communication perifericals are already implemented (SPI just yesterday).
Some modes might not be implemented yet, like Usart in SPI mode.
But only basic testing is done in the simplest case,
Now is time to fix problems and add what is missing, so testing is much needed.

New AVRs are very close to be fully functional.
Comparators is the only periferical not implemented yet (maybe it's ready for next update).

Solved in Rev 341.

I think we need a way that allows us a fast testing/fixing cycle for this version... It will be many issues like this to solve.

Great, thanks for the fast response.

Can you also have a look on Pin Change interrupts of the new AVRs?
They also seem not to work. I tried to implement a software TWI  slave but it did not work in the new AVR MCU. in the old one it works fine.

Might it be possible to get an "out of syncrelease candidate"?
I'm highly interested in an woking TWI

Might it be possible to get an "out of syncrelease candidate"?
I'm highly interested in an woking TWI

Yes I'm thinking in something like that.
But I found a bunch of other problems with AVR TWI as slave.
I will upload updated builds when those issues get fixed.

Can you also have a look on Pin Change interrupts of the new AVRs?
They also seem not to work. I tried to implement a software TWI slave but it did not work in the new AVR MCU. in the old one it works fine.

Yes... I don't remember why those interrupts are not yet activated.
I will have a look.

I'm not sure, whether you already corrected it, but there might be another bug in TWI:
It looks like the TWSR is clearing the prescaler (TWPS1 and TWPS0), when the status (TWS7...TWS3) gets changed, e.g. after SLA_ACK. At least I saw a change of my baudrate after implementing SLA_ACK.


Edit: It's even more confusing, since the baudrate even changes with prescaler off The TWBR stays constant, but the bautrate of the second data packet roughly doubles

I fixed a few issues and commited to Rev 342.
I hope this is at least an startpoint to test New AVR TWI slave.

Have a look at "Testers" section.

Can you also have a look on Pin Change interrupts of the new AVRs?
They also seem not to work. I tried to implement a software TWI slave but it did not work in the new AVR MCU. in the old one it works fine.

Solved some issues and activated Pin Change interrupts (not INT0 and INT1).

Commited to Rev 343, so this will be available for next "testing/fixing iteration".