AVR TWI/I2C: 0xff wird empfangen

Michael R. (fisa) OP (Firma: Brainit GmbH) 01.05.2013 07:57 #3148211

Lesenswert?

•

Hi zusammen,

ich hab hier eigenartiges Phänomen, und find den Fehler nicht:

zwei ATmega328P kommunizieren per i2c miteinander, einer Master einer 
Slave, Master frägt alle 10 msec und Slave antwortet mit einem int32_t, 
also vier Byte.

Das ganze funktioniert soweit wunderbar, aber von Zeit zu zeit empfange 
ich -1 also 0xffffffff.

Das problem liegt definitiv am Empfänger = Master, ich hab testweise die 
i2c-Routine des Slaves so modifiziert dass TWDR beim Daten senden hart 
auf 0x66 gesetzt wird. Ich empfange dann auch 0x66666666, aber ab und an 
wieder 0xffffffff. Ursache kann eigentlich nur sein, dass TWDR eben 0xff 
enthält. Eigenartigerweise schaut der Transfer sonst ganz normal aus, es 
kommen vier Bytes, kein Fehler, nächster Transfer ist dann idR auch 
wieder in Ordnung.

Der i2c-Receiver ist interrupt-basierend, und die empfangenden Werte 
werden auch ausschließlich in den Stati "Data byte has been received; 
ACK has been returned" (erste bytes) und "Data byte has been received; 
NOT ACK has been returned" (letztes Byte) verarbeitet.

Gibts da noch irgendein Flag das mir einen Fehler mitteilen möchte? 
Vielleicht ein Timeout? Aber dann hätt ich doch im TWI-Status-Register 
nciht absolut plausible werte stehen?

Es kann doch auch nciht sein dass irgendwas mir die SDA auf low zieht, 
dann würde ja schon die ganze Slave-Adressierung usw. nicht 
funktionieren...

Hat bitte bitte jemand eine idee was da faul sein könnte?

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Klaus 2. (klaus2m5) 01.05.2013 09:11 #3148244

Lesenswert?

•

▲
▼

Wie kommst Du darauf, dass es definitiv am Master liegt? 0xff ist 
typisch für einen Slave, der SDA nicht ansteuert. Bekommst Du nach der 
Read Adresse immer ein ACK vom Slave?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 01.05.2013 09:58 #3148268

Lesenswert?

•

▲
▼

Klaus 2m5 schrieb:
> Wie kommst Du darauf, dass es definitiv am Master liegt?

"definitiv" ist natürlich relativ :-)

> 0xff ist typisch für einen Slave, der SDA nicht ansteuert. Bekommst Du
> nach der Read Adresse immer ein ACK vom Slave?

Ja, sonst würde mir die TWI-State Machine ja gar nicht erst in den 
lese-Teil springen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Tim Gast 01.05.2013 10:12 #3148282

Lesenswert?

•

▲
▼

Code?
Hast du eine I2C monitor? Oszi?
Vielleicht sendet der Slave ja auch nicht?
Mal auf beiden Seiten einen Zähler eingebaut und
geprüft ob die gleichmäßig hoch laufen?
Fehlerbehandlung und Zähler eingebaut?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 01.05.2013 10:46 #3148321

Lesenswert?

•

▲
▼

Tim schrieb:
> Code?
Bitte gerne.

> Hast du eine I2C monitor? Oszi?
I2C-Monitor nicht, Billigst-Oszi schon, aber kein Speicher-oszi. Da 
geschätzte 99% der Übertragungen problemlos funktionieren, wirds mit 
meinem oszi schwierig...

> Vielleicht sendet der Slave ja auch nicht?
Dann würde er auch kein ACK auf das SLA+R senden?

> Mal auf beiden Seiten einen Zähler eingebaut und
> geprüft ob die gleichmäßig hoch laufen?
Wie meinst du das?


Code des Slave-Transmitters/Receivers:

/* $Id: i2c_slave.c 371 2013-04-12 16:17:31Z michi $
 * $URL: https://svn.trisoft.at/AVR/StepCtrl/i2c_slave.c $
 * simple I2C slave
 * Copyright (C) 2013 Michael Reinelt <michael@reinelt.co.at>
#include <stdint.h>
#include <avr/interrupt.h>
#include <util/twi.h>
#include "i2c_slave.h"
#define I2C_PORT PORTC
#define I2C_DDR DDRC
#define I2C_SDA _BV(4)
#define I2C_SCL _BV(5)
#define I2C_FREQ 100000L  // 100 kHz
#define I2C_PACKETSIZE 64  // maximum receive bytes
static volatile uint8_t I2C_RxBuffer[I2C_PACKETSIZE];
static volatile uint8_t I2C_RxIndex;
static volatile uint8_t I2C_TxBuffer[I2C_PACKETSIZE];
static volatile uint8_t I2C_TxIndex;
static volatile uint8_t I2C_TxLength;
static volatile uint8_t I2C_busy;
static volatile uint8_t I2C_error;
// hack to report current stepper position
extern uint32_t Stepper_position;
void i2c_start(const uint8_t address)
    I2C_DDR &= ~(I2C_SCL | I2C_SDA);  // set pins to input
    I2C_PORT &= ~(I2C_SCL | I2C_SDA);  // no internal pullups on slave
    // init transceiver
    I2C_RxIndex = 0;
    I2C_busy = 0;
    I2C_error = 0;
    // enable I2C  
    TWSR &= ~(TWPS0 | TWPS1);  // prescaler
    TWBR = ((F_CPU / I2C_FREQ) - 16) / 2;  // bit rate
    TWAR = address << 1;  // set I2C address
    TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // fully enable TWI
uint8_t i2c_busy(void)
    return I2C_busy;
uint8_t i2c_get(uint8_t * data, uint8_t len)
    if (I2C_busy) {
  // Transceiver currently busy
  return 0;
    if (I2C_error) {
  // recover from error
  I2C_error = 0;
  I2C_RxIndex = 0;
    // maybe we have less data than expected
    if (len > I2C_RxIndex)
  len = I2C_RxIndex;
    // copy data to caller buffer
    for (uint8_t i = 0; i < len; i++) {
  data[i] = I2C_RxBuffer[i];
    I2C_RxIndex = 0;
    TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // fully (re-)enable TWI
    return len;      // number of bytes received
// I2C ISR
ISR(TWI_vect)
    // code based on tables 21.4..6 from ATmega328 data sheet
    switch (TW_STATUS) {
    case 0x00:      // Bus error due to an illegal START or STOP condition
  TWCR = _BV(TWSTO) | _BV(TWINT);  // return to a well-defined unaddressed slave mode and release SCL and SDA
  I2C_busy = 0;    // transmission aborted
  I2C_error = 1;    // set error flag
  break;
    case 0x60:      // own SLA+W has been received; ACK has been returned
    case 0x68:      // own SLA+W has been received; ACK has been returned; Arbitration lost in SLA+R/W as Master
    case 0x70:      // general call address has been received; ACK has been returned
    case 0x78:      // general call address has been received; ACK has been returned; Arbitration lost in SLA+R/W as Master
  TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // send ACK
  I2C_RxIndex = 0;  // reset packet index
  I2C_busy = 1;    // transmission started
  break;
    case 0x80:      // previously addressed with own SLA+W; data has been received; ACK has been returned
    case 0x88:      // previously addressed with own SLA+W; data has been received; NAK has been returned
    case 0x90:      // previously addressed with general call; data has been received; ACK has been returned
    case 0x98:      // previously addressed with general call; data has been received; NAK has been returned
  if (I2C_RxIndex < I2C_PACKETSIZE) {
      I2C_RxBuffer[I2C_RxIndex++] = TWDR;  // store received data
  if (I2C_RxIndex < I2C_PACKETSIZE) {
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // send ACK
  } else {
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT);  // last byte, send NAK
  break;
    case 0xA8:      // own SLA+R has been received; ACK has been returned
    case 0xB0:      // own SLA+R has been received; ACK has been returned; Arbitration lost in SLA+R/W as Master
  *(uint32_t *) I2C_TxBuffer = Stepper_position;  // hack to report current stepper position
  I2C_TxLength = 4;  // we have 4 bytes
  I2C_TxIndex = 0;  // reset packet index
  I2C_busy = 1;    // transmission started
    case 0xB8:      // data byte in TWDR has been transmitted; ACK has been received
  if (I2C_TxIndex < I2C_TxLength) {
      TWDR = I2C_TxBuffer[I2C_TxIndex++];  // transmit next byte
  } else {
      TWDR = 0;    // we have nothing more...
  if (I2C_TxIndex < I2C_TxLength) {
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // send ACK
  } else {
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT);  // last byte: send NAK
  break;
    case 0xA0:      // a STOP condition or repeated START condition has been received while still addressed as Slave
    case 0xC0:      // data byte in TWDR has been transmitted; NAK has been received
    case 0xC8:      // last data byte in TWDR has been transmitted (TWEA = 0); ACK has been received
  TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // re-enable twi
  I2C_busy = 0;    // transmission ended
  break;
    case 0xF8:      // no relevant state information available; TWINT = 0
    default:      // all other states
  TWCR = _BV(TWSTO) | _BV(TWINT);  // return to a well-defined unaddressed slave mode and release SCL and SDA
  I2C_busy = 0;    // transmission aborted
  I2C_error = 1;    // something strange happened
  break;


Code des Masters:

/* $Id: i2c_master.c 254 2013-02-18 05:04:27Z michi $
 * $URL: https://svn.trisoft.at/AVR/RoboCtrl/i2c_master.c $
 * simple I2C master
 * Copyright (C) 2013 Michael Reinelt <michael@reinelt.co.at>
#include <stdint.h>
#include <avr/interrupt.h>
#include <util/twi.h>
#include <util/delay.h>
#include "i2c_master.h"
#define I2C_PORT PORTC
#define I2C_DDR DDRC
#define I2C_SDA _BV(4)
#define I2C_SCL _BV(5)
#define I2C_FREQ 100000L  // 100 kHz
static volatile uint8_t I2C_slarw;
static volatile uint8_t *I2C_Packet;
static volatile uint8_t I2C_PacketSize;
static volatile uint8_t I2C_PacketIndex;
static volatile uint8_t I2C_busy;
static volatile uint8_t I2C_status;
static volatile uint8_t I2C_error;
void i2c_init(void)
    I2C_DDR &= ~(I2C_SCL | I2C_SDA);  // set pins to input
    I2C_PORT |= (I2C_SCL | I2C_SDA);  // enable pullups
    // init transceiver
    I2C_PacketSize = 0;
    I2C_PacketIndex = 0;
    I2C_busy = 0;
    I2C_status = 0;
    I2C_error = 0;
    // enable I2C  
    TWSR &= ~(TWPS0 | TWPS1);  // prescaler
    TWBR = ((F_CPU / I2C_FREQ) - 16) / 2;  // bit rate
    TWDR = 0xFF;    // Default content = SDA released.
    TWCR = _BV(TWEN);    // enable TWI to standby state
uint8_t i2c_busy(void)
    return I2C_busy;
static uint8_t i2c_start(uint8_t slarw, uint8_t * data, uint8_t len)
    while (I2C_busy);    // wait until i2c is idle
    I2C_slarw = slarw;    // slave address + R/W bit
    I2C_Packet = data;    // set buffer pointer
    I2C_PacketSize = len;  // expected number of bytes
    I2C_PacketIndex = 0;  // reset buffer index
    I2C_busy = 1;    // Transmission in progress
    I2C_status = 0;    // reset TWI status
    I2C_error = 0;    // reset error flag
    TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWSTA);  // enable TWI and send START
    while (I2C_busy);    // wait until i2c is idle
    return I2C_error;
uint8_t i2c_get(uint8_t address, uint8_t * data, uint8_t len)
    for (uint16_t i = 10000; i > 0; i--) {
  uint8_t ret = i2c_start((address << 1) + 1, data, len);
  if (ret == 0 || I2C_status != 0x48)
      return ret;
  // slave may be busy, retry
  _delay_us(10);
    return 1;
uint8_t i2c_put(uint8_t address, uint8_t * data, uint8_t len)
    for (uint16_t i = 10000; i > 0; i--) {
  uint8_t ret = i2c_start((address << 1) + 0, data, len);
  if (ret == 0 || I2C_status != 0x20)
      return ret;
  // slave may be busy, retry
  _delay_us(10);
    return 1;
// I2C ISR
ISR(TWI_vect)
    // code based on tables 22.2..6 from ATmega328 data sheet
    switch (TW_STATUS) {
    case 0x08:      // A START condition has been transmitted
    case 0x10:      // A repeated START condition has been transmitted
  TWDR = I2C_slarw;  // send slave address + R/W
  TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT);  // send byte
  break;
    case 0x18:      // SLA+W has been transmitted; ACK has been received
    case 0x28:      // Data byte has been transmitted; ACK has been received
  if (I2C_PacketIndex < I2C_PacketSize) {
      TWDR = I2C_Packet[I2C_PacketIndex++];
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT);  // send byte
  } else {
      TWCR = _BV(TWEN) | _BV(TWINT) | _BV(TWSTO);  // send STOP after last byte
      I2C_busy = 0;  // Transmission finished
  break;
    case 0x38:      // Arbitration lost
  TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWSTA);  // Initiate a (RE)START condition
  break;
    case 0x40:      // SLA+R has been transmitted; ACK has been received
  TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // Send ACK after reception
  break;
    case 0x50:      // Data byte has been received; ACK has been returned
  if (I2C_PacketIndex < I2C_PacketSize) {
      I2C_Packet[I2C_PacketIndex++] = TWDR;  // store received data
  if (I2C_PacketIndex < I2C_PacketSize) {
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // Send ACK after reception
  } else {
      TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT);  // Send NAK after reception of last byte
  break;
    case 0x58:      // Data byte has been received; NOT ACK has been returned
  if (I2C_PacketIndex < I2C_PacketSize) {
      I2C_Packet[I2C_PacketIndex++] = TWDR;  // store received data
  TWCR = _BV(TWEN) | _BV(TWINT) | _BV(TWSTO);  // Send STOP
  I2C_busy = 0;    // Transmission finished
  break;
    case 0x20:      // SLA+W has been transmitted; NOT ACK has been received
    case 0x30:      // Data byte has been transmitted; NOT ACK has been received
    case 0x48:      // SLA+R has been transmitted; NOT ACK has been received
    case 0xF8:      // No relevant state information available; TWINT = “0”
    case 0x00:      // Bus error due to an illegal START or STOP condition
    default:
  I2C_busy = 0;    // transmission aborted
  I2C_status = TW_STATUS;  // keep TWI status
  I2C_error = 1;    // set error flag
  TWCR = _BV(TWEN);  // Reset TWI
  break;


Der Slave sendet bei Anfrage den int32_t Stepper_position.

Der Master fragt 100mal in der Sekunde per i2c_get(0x66, &int32_var, 
sizeof(int32_var) ab.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Klaus 2. (klaus2m5) 01.05.2013 12:22 #3148422

Lesenswert?

•

▲
▼

Ich würde mir an Deiner Stelle einen Trace bauen: Die letzten 20 
Statuscodes in einem Array speichern und wenn Du 0xffffffff 
zurückbekommst ausgeben.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Tim Gast 01.05.2013 17:59 #3148790

Lesenswert?

•

▲
▼

>> Hast du eine I2C monitor? Oszi?
>I2C-Monitor nicht, Billigst-Oszi schon, aber kein Speicher-oszi.
Hier im Forum sind ein parr I2C Monitore beschrieben.
Definitiv eine Anschaffung wert.

>> Vielleicht sendet der Slave ja auch nicht?
>Dann würde er auch kein ACK auf das SLA+R senden?
Nun wenn du alles ausschließt muss die Übertragung ja auch
immer zu 100% funktionieren....

>> Mal auf beiden Seiten einen Zähler eingebaut und
>> geprüft ob die gleichmäßig hoch laufen?
>Wie meinst du das?
Nun, nach erfolgreichem Abschluss der Übertragung auf
beiden Seiten einen Zähler erhöhen. Dann weisst du
wenigstens ob die Routinen der Ansicht sind das alles OK ist.
Fehlerzähler sind natürlich Pflicht.

Ich habe mir den Code durchgelesen aber keinen offensichtlichen
Fehler finden können.
Ich gehe mal davon aus das du den return wert von i2c_get auswertest.
Externen Pullups hat du dran?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 04.05.2013 07:07 #3151824

Lesenswert?

•

▲
▼

bin leider erst jetzt dazu gekommen, mir das genauer anzuschauen.

ja, externe Pullups (je 4k7 am Master und am Slave) sind dran.

Ich hab mal die idee aufgegriffen, mir die letzten 32 TWI-Stati am 
Master receiver zu merken, und im Fall dass ich 0xff empfange, 
auszugeben.

Das Ergebnis hilft nciht wirklich weiter:

0x58 // Data byte has been received; NOT ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x40 // SLA+R has been transmitted; ACK has been received
0x08 // A START condition has been transmitted
0x58 // Data byte has been received; NOT ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x40 // SLA+R has been transmitted; ACK has been received
0x08 // A START condition has been transmitted
0x58 // Data byte has been received; NOT ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x50 // Data byte has been received; ACK has been returned
0x40 // SLA+R has been transmitted; ACK has been received
0x08 // A START condition has been transmitted

Die hex-Werte sind Echtdaten, die "Übersetzungen" hab ich händisch 
hinzugefügt.

Die Tabelle ist "umgedreht", neuester Eintrag ist oben.

Die letzte Übertragung liefert 4x 0xff, die anderen "normale" Werte. Die 
Übertragungen schauen aber alle gleich aus, keine Fehler, keine 
Ausreisser im Status, und entsprechen genau meinen Erwartungen bzw. auch 
der Auflistung aus dem ATmega-Datenblatt:

1. master Receiver sendet ein "START" um den Bus zu kriegen
2. Master Receiver sendet SLA+R und adressiert damit den Slave
3. Slave antwortet mit ACK
4. Slave schickt der reihe nach die Daten, master antwortet mit ACK bzw. 
mit NAK beim letzten Byte

Als nächstes werd ich halt versuchen sowas ähnliches am Slave zu 
implementieren, wird nur etwas lästiger weil ich dort keinen UART habe 
um die Debug-Daten auszugeben.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 05.05.2013 07:44 #3152883

Lesenswert?

•

▲
▼

So, ich bin einen Schritt weiter: Das problem tritt immer dann auf, wenn 
am Slave der Status 0xf8 " no relevant state information available; 
TWINT = 0" auftritt.

ich weiss leider nicht wirklich, was dieser Status bedeutet, wann und 
warum er auftritt, und wie ich am besten darauf reagieren soll. Aus dem 
Datenblatt werd ich nciht wirklich schlau...

Kann mir da jemand weiterhelfen?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Harald M. (mare_crisium) 05.05.2013 08:50 #3152901

Lesenswert?

•

▲
▼

Michael,
wenn ich mich nicht täusche, müsste der Master nach dem Empfang des 
abschliessenden NAK vom Sklaven ein STOP-Signal senden!? Ohne das STOP 
erscheint dem Sklaven das nächste START als "repeated Start-Signal".

Ciao,
mare_crisium

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 05.05.2013 08:59 #3152906

Lesenswert?

•

▲
▼

Harald M. schrieb:
> wenn ich mich nicht täusche, müsste der Master nach dem Empfang des
> abschliessenden NAK vom Sklaven ein STOP-Signal senden!? Ohne das STOP
> erscheint dem Sklaven das nächste START als "repeated Start-Signal".

Tut er doch:

    case 0x58:      // Data byte has been received; NOT ACK has been returned
  if (I2C_PacketIndex < I2C_PacketSize) {
      I2C_Packet[I2C_PacketIndex++] = TWDR;  // store received data
  TWCR = _BV(TWEN) | _BV(TWINT) | _BV(TWSTO);  // Send STOP
  I2C_busy = 0;    // Transmission finished

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Klaus 2. (klaus2m5) 05.05.2013 09:03 #3152909

Lesenswert?

•

▲
▼

0xf8 sollte nie einen Interrupt erzeugen (TWINT=0)! Trotzdem scheint der 
Slave die Interrupt Routine zu durchlaufen. Hast Du vielleicht einen 
Interrupt enabled, der vor dem TWI Vektor liegt, aber keinen Vektor 
definiert?

0xf8 ist wohl eher nur ein Status, der ohne Interrupts zum Tragen kommt, 
wenn das Program periodisch TWSR abfragt. Auf jeden Fall ist es kein 
Fehlerstatus und die ISR sollte einfach nichts tun, also nicht

    case 0xF8:      // no relevant state information available; TWINT = 0
    default:      // all other states
  TWCR = _BV(TWSTO) | _BV(TWINT);  // return to a well-defined unaddressed slave mode and release SCL and SDA
  I2C_busy = 0;    // transmission aborted
  I2C_error = 1;    // something strange happened

sondern

    case 0xF8:      // no relevant state information available; TWINT = 0
    default:      // all other states
  TWCR = _BV(TWSTO) | _BV(TWINT);  // return to a well-defined unaddressed slave mode and release SCL and SDA
  I2C_busy = 0;    // transmission aborted
  I2C_error = 1;    // something strange happened


Harald M. schrieb:
> wenn ich mich nicht täusche, müsste der Master nach dem Empfang des
> abschliessenden NAK vom Sklaven ein STOP-Signal senden!? Ohne das STOP
> erscheint dem Sklaven das nächste START als "repeated Start-Signal".

Für den Slave besteht zwischen STOP...START und repeated START kein 
Unterschied. STOP wird nur in einer Multimaster Umgebung gebraucht, um 
dem anderen Master(s) mitzuteilen, dass der Bus jetzt wieder frei ist.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 05.05.2013 09:22 #3152919

Lesenswert?

•

▲
▼

Klaus 2m5 schrieb:
> 0xf8 sollte nie einen Interrupt erzeugen (TWINT=0)! Trotzdem scheint der
> Slave die Interrupt Routine zu durchlaufen. Hast Du vielleicht einen
> Interrupt enabled, der vor dem TWI Vektor liegt, aber keinen Vektor
> definiert?

Nein, kein falscher/fehlender Vektor.

Offensichtlich ist das schon ein Interrupt, aber ein irgendwie 
spezieller. Auch die Application Notes avr311 und avr315 bzw. der 
Beispielcode dort ist sich nciht ganz sicher wie damit umzugehen ist :-)

> 0xf8 ist wohl eher nur ein Status, der ohne Interrupts zum Tragen kommt,
> wenn das Program periodisch TWSR abfragt. Auf jeden Fall ist es kein
> Fehlerstatus und die ISR sollte einfach nichts tun
Danke, da hast du natürlich recht! Hat mein problem aber nicht gelöst...

Aber ich bin guter Hoffnng den Fehler schlussendlich gefunden zu haben: 
der Slave ruft in der MainLoop periodisch i2c_get() auf, um auf 
Kommandos des masters zu reagieren. Und dabei wird am TWCR 
herumgespielt, was so nicht sein darf.

Ich muss das jetzt überdenken, halte euch aber am laufenden!

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael R. (fisa) OP (Firma: Brainit GmbH) 05.05.2013 09:37 #3152937

Lesenswert?

•

▲
▼

Yep, das wars. Ich bin ein Trottel :-)


in der i2c_get() vom Slave wurde generell und immer folgende zeile 
ausgeführt:

   TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWINT) | _BV(TWEA);  // fully (re-)enable TWI


und das hat natürlich eine gerade laufende Transaktion gehörig 
durcheinandergebracht.

Die zeile ist so schon korrekt, gehört aber nur ausgeführt wenn ein 
Fehler aufgetreten ist (also im "if I2C_error" zweig)


Danke euch allen!

Antwort Zitieren Bearbeiten Löschen Beitrag melden

AVR TWI/I2C: 0xff wird empfangen

Antwort schreiben