XMega braucht Delay damit HW Module korrekt funktionieren

[Chris N. (Gast)]

Hallo Gemeinde,

ich wundere mich gerade über Probleme mit internen Modulen im XMega an 
meheren Baustellen die ich mit einem ATXMEGA256A3U habe. Vielleicht 
kennt ja jemand von euch dieses Verhalten.

Wenn ich eine Datenkommunikation nach außen durchführen möchte, sei es 
per I2C, SPI oder UART funktioniert immer nur die erste Datenübertragung 
korrekt. Bei der zweiten stimmen die Datenraten nicht mehr. Dieses 
Problem kann ich lösen, indem ich ein Delay nach!!! dem aussenden des 
Datenpacketes einbaue.  Sieht dann zum Beispiel so aus

      TWI_MasterWriteRead(&twiDSP, TWI_SLAVE_DSP_W, &volume[0], 5,0);
        
      while(twiLCD.status != TWIM_STATUS_READY)  //wait until last package was correctly send (wait for Ack from dsp)
      {
          
      }
      
      _delay_ms(1);

Der Rest der I2C Programmierung entstammt der Atmel Referenz Implementierung

der XMEGA läuft mit der internen PLL auf 2x mit einem externen 16 MHz 
als Quelle. Also stabiler Systemtakt mit 32 MHz.

Gruß Chris

[jb (Gast)]

>Wenn ich eine Datenkommunikation nach außen durchführen möchte, sei es
>per I2C, SPI oder UART funktioniert immer nur die erste Datenübertragung
>korrekt.

Dummy-Byte gesendet?

Gruß j

[martin (Gast)]

Hallo,
hier findest du noch einige Beispiele zum Xmega, speziell das beispiel 
"Tutorial Xmega - SRF02 (I2C Ultraschall Entfernungssensor)".
http://www.jtronics.de/avr-projekte/xmega-tutorial.html
Ich arbeite sehr viel mit dieser Serie und kann mich nicht beklagen.
Grüße Martin

[Stefan F. (Gast)]

> Bei der zweiten stimmen die Datenraten nicht mehr.

Ganz sicher? Hast du das nachgemessen? Falls ja, prüfe mal die 
Spannungsversorgung während der Übertragung.

Ansonsten könnte auch daran liegen, dass deine Peripherie etwas Zeit 
benötigt, um empfangene Daten zu verarbeiten. Bei LCD Displays und 
Ultraschall Sensoren ist das ganz Sicher der Fall.

Weiterhin könnte es sein, dass du den R/C Oszillator ohne 
Synchronisation verwendest. Dann läuft er ziemlich instabil (in etwa wie 
beim Atmega).

Vergleiche mit diesem erprobten Code:

        // Set clock source to 32Mhz using the internal R/C Oscillator.
        OSC.CTRL|=OSC_RC32MEN_bm;
        while (!(OSC.STATUS & OSC_RC32MRDY_bm)); 
        CCP=CCP_IOREG_gc;
        CLK.CTRL=CLK_SCLKSEL_RC32M_gc; 
        // Synchronize to the calibrated 32kHz oscillator (needed for the UART)
        OSC.CTRL&=(~OSC_RC2MEN_bm);
        OSC.CTRL|= OSC_RC32KEN_bm;
        while (!(OSC.STATUS & OSC_RC32KRDY_bm)); 
        OSC.DFLLCTRL &= ~OSC_RC32MCREF_bm;
        DFLLRC32M.CTRL |= DFLL_ENABLE_bm;

[Chris N. (Gast)]

Nein auch mit dieser Art den Clock zu Initialisieren wird es nicht 
besser. Ohne ein Delay stimmen die Datenraten einfach nicht. Ich habe 
mein Programm jetzt auch auf das Minimum gekürzt. Atmel Referenz Dateien 
für I2C Kommunikation, die zuvor von Stefan erwähnte Clock 
Initialisierung und dann einfach alle 100ms ein festes Register meines 
DSP abfragen. Ich muss das Delay einbauen, sonst funktioniert es nicht.

[Michael K. (Gast)]

Bau doch mal einen Breakpoint vor dem delay ein und schau Dir an was in 
den I2C Registern steht.
Sieht so aus als ob Dein while nicht funktioniert und Du den I2C einfach 
überfährts.

Hier könnte schon Deine Lösung liegen.
Beitrag "Frage zur TWI Lib des ATXmega"