xmega verhält sich mit Debugger anders

[Jörg S. (Gast)]

Hallo,

ich stehe gerade total auf dem Schlauch und brauche frische Ideen. Ich 
hoffe ihr könnt mir helfen:

Ich setze einen ATxmega64A4U (getaktet auf 64MHz) ein und nutze dort das 
SPI an Port C als Master (Teiler 128).
Ich sende nur Daten über MOSI heraus.
Ich musste ein paar Pins sparen und haben folgendes gemacht:
Den Pin MISO (PC6) betreibe ich permanent als Eingang, ändere aber mit 
Hilfe der Pullup/Pulldown-Widerstände den Logikpegel.
Den Pin SS an PC4 nutze ich als Ausgang für andere Geschichten. Der Pin 
ist permanent auf Output.

Als SPI-Treiber nutze ich die Atmel-Bibliothek "spi_driver".

Nun zum Problem: Mein Programm bleibt in der while-Schleife hängen, die 
abfragt ob alle bits das Datenregister verlassen haben. Das habe ich mit 
Hilfe einer LED an einem Ausgang festgestellt.

uint8_t SPI_MasterTransceiveByte(SPI_Master_t *spi, uint8_t TXdata)
{
  /* Send pattern. */
  spi->module->DATA = TXdata;
  
  /* Wait for transmission complete. */
  while(!(spi->module->STATUS & SPI_IF_bm)) {    // hier

  }
  /* Read received data. */
  uint8_t result = spi->module->DATA;

  return(result);
}

Jetzt aber der Witz an der Sache: Mein Programm läuft korrekt durch, 
soweit ich es mit dem Debugger (Atmel-ICE) gestartet habe. Es ist egal 
ob ich aktiv debugge oder es einfach nur darüber anschubse.
Es fällt mir schwer die Ursache zu finden, denn mit Debugger dran rennt 
das Programm einfach durch, wie ich es auch im Normalbetrieb erwarten 
würde.

Da ich annehme, dass der Master-Mode verloren geht, habe ich diesen vor 
dem Senden explizit nocheinmal gesetzt.
Jetzt läuft zwar das Programm auch ohne Debugger durch, aber es werden 
"falsche" oder keine Daten gesendet. Ich betreibe einen Stromregler 
TLC5922 dran, daher kann ich recht schnell auf dem Messgerät sehen, dass 
es nicht passt.

---

- Liegt es daran, dass ich die ungenutzten SPI Pins anderweitig 
verwende?
- Kennt von euch jemand das Phänomen, dass das Programm mit Debugger 
anders funktioniert als ohne? (Es liegt nicht Debug/Release Version)
- Oszi-Aufnahme habe ich nocht nicht. Wäre da etwas sinnvoll zu messen?


Ich bin für jeden Denkanstoß dankbar!

Viele Grüße,
Euer Jörg

[Curby23523 N. (Gast)]

Jörg S. schrieb:
> Ich setze einen ATxmega64A4U (getaktet auf 64MHz)

Wie kriegst du das hin? Afaik kann der Xmega nur 32MHz, evtl. etwas mehr 
bei Übertaktung. Bitte korrigieren, wenn ich mich da irre.

[Sibbel (Gast)]

Jörg S. schrieb:
> Mein Programm läuft korrekt durch,
> soweit ich es mit dem Debugger (Atmel-ICE) gestartet habe

Wie ist es denn, wenn der Debugger lediglich angeschlossen, aber nicht 
über die IDE in Betrieb ist? Also nur anschließen, aber dennoch den 
Controller selbst laufen lassen.

[J Zimmermann (Gast)]

läuft das Programm, wenn Du den Controller mit 32MHz betreibst?
mfg

[Holger K. (holgerkraehe)]

Evtl hilft dies hier?

Beitrag "atxmega RAM korrupt ohne debugger"

[Jörg S. (Gast)]

Ich bin inzwischen doch mit dem Oszi ran gegangen und habe festgestellt, 
dass im Betrieb ohne Debugger einfach gar nichts gesendet wird. Kein 
SPI-Takt, nichts. Mir scheint es am Master-Mode zu liegen.



Curby23523 N. schrieb:
> Wie kriegst du das hin? Afaik kann der Xmega nur 32MHz

Ich habe extern einen 16MHz Quarz dran und den PLL auf 4.



Sibbel schrieb:
> Wie ist es denn, wenn der Debugger lediglich angeschlossen, aber nicht
> über die IDE in Betrieb ist? Also nur anschließen, aber dennoch den
> Controller selbst laufen lassen.

Dann läuft das Programm nicht. Es muss tatsächlich über den Debugger 
angestoßen werden, das reine "angeschlossen sein" ist es leider nicht.



J Zimmermann schrieb:
> läuft das Programm, wenn Du den Controller mit 32MHz betreibst?
> mfg

Nein, dann auch nicht.



Holger K. schrieb:
> Evtl hilft dies hier?
>
> Beitrag "atxmega RAM korrupt ohne debugger"
Ich schaue es mir an, danke.

[Volker B. (Firma: L-E-A) (vobs)]

Jörg S. schrieb:

> uint8_t SPI_MasterTransceiveByte(SPI_Master_t *spi, uint8_t TXdata)

SPI_Master_t finde ich nicht in den avr-libc Headern. Wie ist das 
definiert?

> Ich habe extern einen 16MHz Quarz dran und den PLL auf 4.

Natürlich kann man das einstellen. Die Frage ist nur, was die MCU dann 
macht...?

Es gibt Peripherie-Module, die ein Vielfaches des MCU-Taktes benötigen. 
Deshalb lässt sich die PLL auf solche Frequenzen einstellen.

Grüßle
Volker

Nachtrag: OK, ich hab's überlesen:

> Als SPI-Treiber nutze ich die Atmel-Bibliothek "spi_driver".

Das wird dann wohl korrekt sein.

[Jörg S. (Gast)]

Zwischendurch ein DANKE für euer Feedback!

Volker B. schrieb:
> Natürlich kann man das einstellen. Die Frage ist nur, was die MCU dann
> macht...?
>
> Es gibt Peripherie-Module, die ein Vielfaches des MCU-Taktes benötigen.
> Deshalb lässt sich die PLL auf solche Frequenzen einstellen.

Ja ok, mit meinen 64MHz bin ich natürlich nicht im sicheren 
Arbeitsbereich. Ich habe mal gelesen, dass es geht und ausprobiert. Bis 
jetzt kann ich sagen, dass es stabil läuft. Um aber auszuschließen, dass 
es daran liegt, betreibe ich den Spaß jetzt mit 32MHz (also 16MHz mit 
PLL auf 2). Ohne Erfolg, wie oben schon erwähnt.



Holger K. schrieb:
> Evtl hilft dies hier?
>
> Beitrag "atxmega RAM korrupt ohne debugger"

In dem Beitrag war das Problem, das zu wenig Stack vorhanden war. 
Tatsächlich traten die Probleme auf, nachdem ich mein Programm erweitert 
habe. Ich nahm aber an, dass der Zusammenhang anders ist. Ich versuche 
mich daran und berichte.

Falls aber jemand noch eine Idee, zögert nicht zu schreiben.

[Holger K. (holgerkraehe)]

Ich hätte noch einen Vorschlag.

Selber erlebt bei meinem Programm.

Der Debugger initialisiert das SRAM mit "0".
Dadurch sind alle Variablen automatisch mit Null initialisiert, sollten 
diese nicht anderweitig initialisiert worden sein.

So hatte ich das Problem, das mit zunehmender Zeit in der die 
Stromzufuhr unterbrochen war auch mehr Probleme auftraten.

Abhilfe schaffte es, die Variablen korrekt zu initialisieren.
Ich nahm an, dass die Variablen automatisch auf null initialisiert 
werden.

[Jörg S. (Gast)]

Danke für den Vorschlag. Ich habe überall versucht zu nullen, leider 
ohne Erfolg. Das heißt natürlich nicht, dass ich nicht irgendwo etwas 
vergessen habe.

Ich bin aber noch einen kleinen Schritt weiter: Per LED habe ich heraus 
bekommen, dass SCK nicht mehr Ausgang war. Als Workaround setze ich SCK 
in einer Routine vor dem Senden als Ausgang. Dass funktioniert dann auch 
ohne Debugger.

Es fragt sich natürlich trotzdem warum der SCK mit Debugger so bleibt 
wie initialisiert und ohne nicht?

Zufrieden bin ich also nicht, irgendwo ist noch der Wurm drin.

Gibt es eine Möglichkeit einen Stack-Overflow mit zu bekommen?

Viele Grüße,
Jörg

[Jörg S. (Gast)]

Nach einigen Tagen debugging möchte ich mich nochmal für die 
konstruktive Hilfe bei allen bedanken: DANKE!

Für denn Fall, dass noch jemand ein ähnlich Problem hat, möchte ich 
kundtun wie ich aktuell Herr der Lage geworden bin. Anstoß war Holger's 
Post:


Holger K. schrieb:
> ...
> Der Debugger initialisiert das SRAM mit "0".
> Dadurch sind alle Variablen automatisch mit Null initialisiert, sollten
> diese nicht anderweitig initialisiert worden sein.
>
> So hatte ich das Problem, das mit zunehmender Zeit in der die
> Stromzufuhr unterbrochen war auch mehr Probleme auftraten.
>
> Abhilfe schaffte es, die Variablen korrekt zu initialisieren.
> Ich nahm an, dass die Variablen automatisch auf null initialisiert
> werden.


Ich denke zwar alle meine Variablen initialisiert zu haben, bin aber 
noch einen Schritt weiter gegangen. Mit Hilfe einer kleinen Funktion, 
basiert auf MichaelMcTernan's Stackmonitor setzte ich zu Beginn des 
Programms den kompletten SRAM auf 0x00. Michael war so freundlich seine 
Routinen frei zur Verfügung zu stellen, daher möchte ich hier meine 
Anpassungen posten:

#define STACK_DEFAULT 0x00

void ClearStackOnStartup(void) __attribute__ ((naked)) __attribute__ ((section (".init1")));

/** Fill the stack space with a known pattern.
 * This fills all stack bytes with the 'STACK_DEFAULT'
 * This runs in the .init1 section, before normal
 * stack initialisation and unfortunately before __zero_reg__ has been
 * setup.  The C code is therefore replaced with inline assembly to ensure
 * the zero reg is not used by compiled code.
 */
void ClearStackOnStartup(void)
{
#if 0
    uint8_t *p = INTERNAL_SRAM_START;

    while(p <= INTERNAL_SRAM_END)
    {
        *p = STACK_DEFAULT;
        p++;
    }
#else
    __asm volatile ("    ldi r30,lo8(_end)\n"
                    "    ldi r31,hi8(_end)\n"
                    "    ldi r24,lo8(0x00)\n" /* STACK_DEFAULT = 0x00 */
                    "    ldi r25,hi8(__stack)\n"
                    "    rjmp .cmp\n"
                    ".loop:\n"
                    "    st Z+,r24\n"
                    ".cmp:\n"
                    "    cpi r30,lo8(__stack)\n"
                    "    cpc r31,r25\n"
                    "    brlo .loop\n"
                    "    breq .loop"::);
#endif
}

Die Funktion muss nicht aufgerufen werden, sie wird durch die Attribute 
vom Compiler in das assembler-file integriert.

Viele Grüße,
Euer Jörg

[Jörg S. (Gast)]

Hoppla, Korrektur:

nicht der gesamte SRAM, sondern der Teil zwischen ersten ungenutzten 
RAM-Adresse bis zum Stack-Ende

Es fehlt noch dieser Teil:

/** Gain access to linker symbol for end of variable section.
 * This symbol is defined to be the address of the first unused byte of SRAM.
 * The stack is by convention at the top of the SRAM, growing down towards
 * the address at which this variable resides.
 */
extern uint8_t _end;

/** Gain access to linker symbol for base of the stack.
 * This symbol is defined to be the address at the bootom of the stack.
 */
extern uint8_t __stack;

So sieht es dann aus:

#include <stdint.h>

#define STACK_DEFAULT 0x00

/**************************************************************************
 * Variables
 **************************************************************************/

/** Gain access to linker symbol for end of variable section.
 * This symbol is defined to be the address of the first unused byte of SRAM.
 * The stack is by convention at the top of the SRAM, growing down towards
 * the address at which this variable resides.
 */
extern uint8_t _end;

/** Gain access to linker symbol for base of the stack.
 * This symbol is defined to be the address at the bootom of the stack.
 */
extern uint8_t __stack;

/**************************************************************************
 * Local Functions
 **************************************************************************/

void ClearStackOnStartup(void) __attribute__ ((naked)) __attribute__ ((section (".init1")));

/** Fill the stack space with a known pattern.
 * This fills all stack bytes with the 'STACK_DEFAULT'
 * This runs in the .init1 section, before normal
 * stack initialisation and unfortunately before __zero_reg__ has been
 * setup.  The C code is therefore replaced with inline assembly to ensure
 * the zero reg is not used by compiled code.
 *
 * \note This relies on the linker defining \a _end and \a __stack to define
 *        the bottom of the stack (\a __stack) and the top most address
 *        (\a _end).
 */
void ClearStackOnStartup(void)
{
#if 0
    uint8_t *p = INTERNAL_SRAM_START;

    while(p <= INTERNAL_SRAM_END)
    {
        *p = STACK_DEFAULT;
        p++;
    }
#else
    __asm volatile ("    ldi r30,lo8(_end)\n"
                    "    ldi r31,hi8(_end)\n"
                    "    ldi r24,lo8(0x00)\n" /* STACK_DEFAULT = 0x00 */
                    "    ldi r25,hi8(__stack)\n"
                    "    rjmp .cmp\n"
                    ".loop:\n"
                    "    st Z+,r24\n"
                    ".cmp:\n"
                    "    cpi r30,lo8(__stack)\n"
                    "    cpc r31,r25\n"
                    "    brlo .loop\n"
                    "    breq .loop"::);
#endif
}

[Oliver S. (oliverso)]

Jörg S. schrieb:
> Ich denke zwar alle meine Variablen initialisiert zu haben, bin aber
> noch einen Schritt weiter gegangen. Mit Hilfe einer kleinen Funktion,
> basiert auf MichaelMcTernan's Stackmonitor setzte ich zu Beginn des
> Programms den kompletten SRAM auf 0x00

Wenn dein Programm ohne das Nullen nicht funktioniert, enthält es also 
nach wie vor Programmfehler, die du mit der Aktion kaschierst. Kann man 
so machen, ist aber nur der halbe Weg.

Oliver

[Jörg S. (Gast)]

Oliver S. schrieb:
> Wenn dein Programm ohne das Nullen nicht funktioniert, enthält es also
> nach wie vor Programmfehler, die du mit der Aktion kaschierst. Kann man
> so machen, ist aber nur der halbe Weg.
>
> Oliver

Ja da hast du leider recht. Ich suche auch weiter :-)