I2C EEPROM Beschreiben mit SAM3X8: Pollingproblem

[Hanns-Jürgen M. (yogy)]

Eigentlich klappt das Beschreiben des EEPROMS mit den daten, zumindest, 
solange ich nach dem Beschreiben einen Warteschlife einfüge.

Laut Datenblatt soll das Ende des Schreibzyklus auch per Poling 
festgestellt werden können, das ggf. Zeit spart. Aber das funzt bei mir 
irgendwie nicht. Da ist wohl ein blöder Fehler, den ich noch nicht 
finden konnte.

Das aktuelle Ende meiner Bescreibungsroutine sieht wie folgt aus:

  //wait for writecycle finished

  Delay1ms(20);
  /*
  while (millis_EEPROM < 24) {
    TWI0->TWI_MMR = 0;
    TWI0->TWI_MMR = TWI_MMR_MREAD | TWI_MMR_IADRSZ_2_BYTE | adr << 16; 
    TWI0->TWI_IADR = iadr;
    TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP; 
    Watchdog_Reset();
    
    if((TWI0->TWI_SR & TWI_SR_NACK) == 0) {
      millis_EEPROM = 100;
      j = 0;
    }
  }
  */
  return  j;

Mit der Notloesung "Delay1ms(20)", funktioniert es (Wartezeit 20 ms)

Die eigentlich, hier auskommentierte, vorgesehene Polling funktioniert 
nicht. Die darin befindliche Warteschleife wird mittels des ms-Zaehlers 
zwangsweise verlassen, damit sich die SW nicht aufhängen kann.

Wo bin ich wieder mal zu bloed gewesen?

[Peter D. (peda)]

Zum Polling sendet man Start + Adresse und wertet aus, ob NACK 
geantwortet wird. NACK bedeutet, daß der EEPROM noch beschäftigt ist. 
Dann muß Stop gesendet werden und der nächste Pollingversuch kann 
erfolgen.
Hier mal ein Beispiel:
Beitrag "Re: I2C Eeprom AT24C512 Lib für Pagewrite in C"

[Hanns-Jürgen M. (yogy)]

Ja, schon klar. Mit "manueller" I2C-Lösung oder auch mit einem AVR (dazu 
habe ich eine Vorlage) ist das auch okay, aber für den SAM3X8 nicht. Die 
dortige TWI-Maschine ist ziemlich komplex.

Da ich Datenblatt nun gelesen habe, daß zusammen mit NACK auch TXCOMP im 
Statusregister gesetzt werden, habe ich "meine" dennoch noch nicht 
funktionierende Polling-Routine wie folgt geändert:

millis_EEPROM=0;
  while (millis_EEPROM < 24) {
    TWI0->TWI_MMR = 0;
    TWI0->TWI_MMR = TWI_MMR_MREAD | TWI_MMR_IADRSZ_2_BYTE | adr << 16; 
    TWI0->TWI_IADR = iadr;
    TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP;  
    Watchdog_Reset();
    
    if(((TWI0->TWI_SR & TWI_SR_NACK) == 0) && ((TWI0->TWI_SR & TWI_SR_TXCOMP) == TWI_SR_TXCOMP)) {  //so muesste es dann gehen, oder?
      millis_EEPROM = 100;
      j = 0;
    }
  }

Die entspricht in etwa einem 1-byte Lesezyklus... Irgendwo mache ich da 
immer noch einen Fehler..

[TK (Gast)]

Hallo,

ist Deine Anwendung so zeitkritisch, dass Du nicht 20ms nach einem 
PAGE-Write warten kannst?
In der Zeit, die Du Dich jetzt schon mit dem Polling beschäftigt hast, 
hättest Du locker Deine Delay-Routine anspringen können und gut ist.

Ist vielleicht nicht das, was Du hören möchtest - aber die schnellste
Art und Weise, Dein Problem zu beseitigen.

Gruß
TK

[Hanns-Jürgen M. (yogy)]

TK schrieb:
> Hallo,
>
> ist Deine Anwendung so zeitkritisch, dass Du nicht 20ms nach einem
> PAGE-Write warten kannst?
> In der Zeit, die Du Dich jetzt schon mit dem Polling beschäftigt hast,
> hättest Du locker Deine Delay-Routine anspringen können und gut ist.
>
> Ist vielleicht nicht das, was Du hören möchtest - aber die schnellste
> Art und Weise, Dein Problem zu beseitigen.
>
> Gruß
> TK


So gesehen hast Du natürlich recht. Ich sehe die Lösung der 
Polling-Geschichte mehr sportlich, ich möchte halt, daß sie 
funktioniert. Quick & dirty ist eher nicht mein Fall.

CU Yogy

[Peter D. (peda)]

Hanns-Jürgen M. schrieb:
> TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP;

Das sieht schon komisch aus, Start und Stop gleichzeitig.
Das Stop darf erst erfolgen, nachdem man NACK festgestellt hat.
Schau Dir mal meinen Ablauf an. Die SW-I2C Funktionen müßten sich doch 
1:1 auf das HW-I2C runterbrechen lassen.

[Peter D. (peda)]

TK schrieb:
> ist Deine Anwendung so zeitkritisch, dass Du nicht 20ms nach einem
> PAGE-Write warten kannst?

Die typischen Schreibzeiten liegen weit darunter. Bei größeren Blöcken 
macht sich das deutlich bemerkbar.

[Hanns-Jürgen M. (yogy)]

Peter D. schrieb:
> Hanns-Jürgen M. schrieb:
>> TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP;
>
> Das sieht schon komisch aus, Start und Stop gleichzeitig.
> Das Stop darf erst erfolgen, nachdem man NACK festgestellt hat.
> Schau Dir mal meinen Ablauf an. Die SW-I2C Funktionen müßten sich doch
> 1:1 auf das HW-I2C runterbrechen lassen.

Beim SAM3X8 (auf Arduino DUE) ist die TWI offenbar anders anzusteuern 
als beim AVR. Die Leseroutine fuer ein einziges Byte sieht dort wie 
folgt (meine Implementierung) aus

//*********************************************************************************************
//
//
//*********************************************************************************************
//  Lese ein byte aus dem Device <adr> an der internen Adresse <iadr> aus. iadr ist U16!  
//
U16 twi0_master_read_EE_byte(U8 adr,U16 iadr)
{
  U16 data = 0;
  U16 i = 0;
  TWI0->TWI_MMR = 0;
  TWI0->TWI_MMR = TWI_MMR_MREAD | TWI_MMR_IADRSZ_2_BYTE | adr << 16; //TWI0 Master Mode Register RW   (Bit ist 1 bei READ
  TWI0->TWI_IADR = iadr;
  
  millis_EEPROM=0;
  TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP;  // BEIDES muss hier gesetzt werden
   
     while((TWI0->TWI_SR & TWI_SR_RXRDY) != TWI_SR_RXRDY)
     {
       if (millis_EEPROM >= 2)
       return 0xffff;
     }
  data = TWI0->TWI_RHR;
  
  millis_EEPROM=0;
  while((TWI0->TWI_SR & TWI_SR_TXCOMP) != TWI_SR_TXCOMP)
     {
       if (millis_EEPROM >= 2)
       return 0xffff;
     }
     
     return  (U16)data;
}

Beim Lesen von mehrere Bytes ist die Stop-Anweisung beim letzten Byte zu 
setzen. z.B.:

//*********************************************************************************************
//
//
//*********************************************************************************************
//    lese einen fortlaufenden Block von IANZ-Zeichen ab Adresse IADR aus dem EEPROm aus und speichere die
//    Daten im Array TWI_ARRAY. Rueckgabe: CRC8 in dem LSByte, bei Rückgabe 0xffff -> Systemerror
//
U16 twi0_master_read_EE_block_into_twi_array(U8 adr,U16 iadr,U8 ianz)
{
  U16 i = 0;
  U16 j = 0;
  U8 crc_8 = 0;
  U8 wert;
  
  
  TWI0->TWI_MMR = 0;
  TWI0->TWI_MMR = TWI_MMR_MREAD | TWI_MMR_IADRSZ_2_BYTE | adr << 16;   //TWI0 Master Mode Register RW   (Bit ist 1 bei READ
  TWI0->TWI_IADR = iadr;
// 
  TWI0->TWI_CR = TWI_CR_START;  //
  while (j < ianz - 1) {
    Watchdog_Reset();
    millis_EEPROM=0;
    while((TWI0->TWI_SR & TWI_SR_RXRDY) != TWI_SR_RXRDY)
    {
      if (millis_EEPROM >= 14)
        return 0xffff;
    }
    wert = TWI0->TWI_RHR;
    twi0_array[j++] = wert;
    crc_8 = _crc8_update(crc_8, wert);

  }

  TWI0->TWI_CR = TWI_CR_STOP;  //
  
  millis_EEPROM=0;
  while((TWI0->TWI_SR & TWI_SR_RXRDY) != TWI_SR_RXRDY)
  {
      if (millis_EEPROM >= 2)
      return 0xffff;
  }
  wert = TWI0->TWI_RHR;
  twi0_array[j] = wert;
  crc_8 = _crc8_update(crc_8, wert);
  
  millis_EEPROM=0;
  while((TWI0->TWI_SR & TWI_SR_TXCOMP) != TWI_SR_TXCOMP)
  {
      if (millis_EEPROM >= 2)
      return 0xffff;
    }
  
  return (U16)crc_8;
}
//---------------------------------------------------------------------------------------------

Aber ich glaube, ich habe den Fehler entdeckt, ich werde das morgen mal 
checken.

Denn jetzt geniesse ich das Eifelwasser vom seligen Simon aus aus 
Bitburg...

Viele Grüße, Yogy

[Hanns-Jürgen M. (yogy)]

Peter D. schrieb:
> TK schrieb:
>> ist Deine Anwendung so zeitkritisch, dass Du nicht 20ms nach einem
>> PAGE-Write warten kannst?
>
> Die typischen Schreibzeiten liegen weit darunter. Bei größeren Blöcken
> macht sich das deutlich bemerkbar.

Beim byteweisen Beschreiben von mehrenen k Bytes ist das natürlich 
richtig. Beim 24C256 kann ich aber in Blöcken a' 64 byte beschreiben und 
muß nur ein einziges Mal pro Block den Delay benutzen.

[Hanns-Jürgen M. (yogy)]

So, ich glaube, wir können das Thema schließen. Ich habe zwar das 
"Polling Problem" nicht lösen können, aber meine Recherchen im web haben 
ergeben, daß die Atmels at91xx Bugs in der TWI haben, die insb das NACK 
Signal betreffen. Die (hier!) beschriebene Lösung (Workaround) erscheint 
mir aktuell zu aufwendig, um sie zu implementieren und zu testen. 
Vielleicht mache ich das "irgendwann".

der Link: https://www.mikrocontroller.net/articles/AT91-TWI

Schoenes WE, Yogy

[STM Apprentice (Gast)]

Hanns-Jürgen M. schrieb:
> Schoenes WE, Yogy

Beitrag "Re: I2C auf STM32F103"

[STM Apprentice (Gast)]

STM Apprentice schrieb:
> Beitrag "Re: I2C auf STM32F103"

Ein paar Vorteile einer Soft-I2C-Implementierung:

- keine Geschwindigkeits-Verluste da der I2C Bus meist langsamer
arbeitet als der Controller

- Unahbhängigkeit von der SPI_harware bedeuted praktisch völlig
freie Wahl der Pins SCL/SDA am Controller.

- leicht zu debuggen da die I2C-Bus Slaves/Bausteine meist quasi-
statisch arbeiten und man jedes Bit einzeln anschauen kann (was
ja beim NACK/ACK sehr wichtig sein kann).

- "interruptible", aus dem gleichen Grund wie vorher (quasi-
statisch)

[Peter D. (peda)]

Hanns-Jürgen M. schrieb:
> TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP;  // BEIDES muss hier
> gesetzt werden

Das kommt mir immer noch unlogisch vor.
Ich weiß doch erst nach dem NACK auf die I2C-Adresse, ob ich ein Stop 
senden muß oder ob der Söave adressiert wurde und ich weiter machen 
kann.
Ist das wirklich in dem Microchip Beispielcode so angegeben?

[Peter D. (peda)]

Hanns-Jürgen M. schrieb:
> Beim 24C256 kann ich aber in Blöcken a' 64 byte beschreiben und
> muß nur ein einziges Mal pro Block den Delay benutzen.

Das sind dann beim Beschreiben der 32kB schon 10s Wartezeit gegenüber 
nur 2,5s, wenn der Chip schon nach 5ms wieder bereit ist.

[Hanns-Jürgen M. (yogy)]

Peter D. schrieb:
> Hanns-Jürgen M. schrieb:
>> TWI0->TWI_CR = TWI_CR_START | TWI_CR_STOP;  // BEIDES muss hier
>> gesetzt werden
>
> Das kommt mir immer noch unlogisch vor.
> Ich weiß doch erst nach dem NACK auf die I2C-Adresse, ob ich ein Stop
> senden muß oder ob der Söave adressiert wurde und ich weiter machen
> kann.
> Ist das wirklich in dem Microchip Beispielcode so angegeben?

Nein, das ist kein Microchip Beispielcode gewesen. Ich weiß auch aktuell 
nicht mehr, wo ich ihn her habe. Ich glaube, das war grob in einer 
Applikationnote beschrieben, die ich wohl nicht abgespeichert hae. Das 
Auslesen von einem einigen Byte geht auf jeden Fall so, wie ich 
beschrieben habe. Das funktioniert ja auch.  Ich habe da gerade etwas 
bei GITHUB gefunden:

https://github.com/brandonbraun653/SAM3X8E-Libraries/blob/master/ASF_Support/TWI/twi.c

siehe ca Zeile 282.

BTW: Die dort auch angegeben Polling-Lösung funktioniert nicht, WTF auch 
immer. Ich bleibe erst einmal beim  Delay. (s.u.)

[Hanns-Jürgen M. (yogy)]

Peter D. schrieb:
> Hanns-Jürgen M. schrieb:
>> Beim 24C256 kann ich aber in Blöcken a' 64 byte beschreiben und
>> muß nur ein einziges Mal pro Block den Delay benutzen.
>
> Das sind dann beim Beschreiben der 32kB schon 10s Wartezeit gegenüber
> nur 2,5s, wenn der Chip schon nach 5ms wieder bereit ist.

Nun, das EEPROM wird ja nicht ständig neu beschreiben. Es beinhaltet die 
Konfigurationsgrößen meines Systems. Und das sind aktuell 16 Tabellen a' 
64 byte, jeweils mit CRC sowie 182 Bytes an Einzelgroessen, deren Anzahl 
aber noch wachsen kann.

Alle diese Größen können natürlich geändert werden, aber das geschieht 
manuell über das User-Interface und ist daher usergemäß langsam.

Wenn ich das gesamte Systeme soweit ferig und funktionsfähig habe, werde 
ich mich ggf. an Optimierungen geben.