Prozessor startet sich beim Array beschreiben neu

[Stefan (Gast)]

Hallo,

ich versuche von einer MMCard einen 512 byte grossen Sektor auszulesen.
Hierfuer ist folgender Code vorgesehen:

u08 sectorBuffer[512];
u08 * pSecPtr;

[...]

u08 mmc_sectorRead( u32 lba ) {
   union u32convert conv;
   conv.value = lba;

   cbi( MMC_PORT, MMC_CS );

   u08 params[] = { conv.byte.b4, conv.byte.b3, conv.byte.b2,
conv.byte.b1 };

   mmc_sendCmd( MMC_READ_SINGLE_BLOCK, params );

   if ( mmc_dataToken( ) != 0xfe ) {
      mmc_disable( );
      return 1;
   }

   u16 i;

   pSecPtr = sectorBuffer;
   for ( i = 0; i < 512; i++ ) {
      *pSecPtr++ =  mmc_spi(0xFF);
   }

   mmc_spi( 0xFF );
   mmc_spi( 0xFF );

   mmc_disable( );

   return 0;
}

Sobald ich z.B. folgendes ausfuehre

   u32 i =0;
   mmc_sectorRead( i );

startet sich der Prozessor neu. Selten kommt es auch zu anderen
unkontrollierten Verhaltensweisen, aber eigentlich startet er sich
einfach neu.

Meine bisherigen Debugging-Versuche haben ergeben, dass er bis zum
Beschreiben des Sektor-Buffers kommt.
Findet ihr einen Fehler dort?

Falls noch mehr vom Code noetig ist, gebt einfach bescheid.

Vielen Dank fuer Antworten,

~stefan

[Thorsten (Gast)]

Hallo,

dein Stack läuft wahrscheinlich über. Hatte das Problem kürzlich bei
einem ATmega128 und konnte durch Vergrößern des Stacks behoben werden.
Wie du das anstellen kannst, weis ich ellerdings nicht. In meiner IDE
gibt es dazu eine spezielle Option.

Gruß
Thorsten

[Stefan (Gast)]

Hallo Thorsten,

erstmal vielen Dank fuer deine Antwort.

> Wie du das anstellen kannst, weis ich ellerdings nicht.

Hmm, ich leider auch nicht. Ich habe mal in den includes gesucht und in
iom162.h steht RAMEND und XRAMEND. Aber ich vermute, dass man da lieber
die Finger von laesst. :-)

Der Compiler macht die Routine zum Stack Initialisieren wie folgt:

       ldi r28,lo8(__stack - 0)
        ldi r29,hi8(__stack - 0)
        out _SP_H_,r29
        out _SP_L_,r28

Allerdings finde ich nicht, was nun anstatt __stack genau dasteht.

> In meiner IDEgibt es dazu eine spezielle Option.

Erzeugt die IDE irgendwie Makefiles? Vielleicht koennte man auf dem Weg
rausfinden was genau veraendert wird ?

Ich habe auch mal einen Blick in die vom Compiler erzeugten asm (.s)
files geworfen, aber nicht wirklich etwas verdaechtiges gefunden.

Fuer die asm gurus, vielleicht den entsprechenden Ausschnitt:

.L21:
        .stabn 68,0,70,.LM33-mmc_sectorRead
.LM33:
        ldi r24,lo8(-1)
        call mmc_spi
        lds r30,pSecPtr
        lds r31,(pSecPtr)+1
        st Z+,r24
        sts (pSecPtr)+1,r31
        sts pSecPtr,r30
        .stabn 68,0,69,.LM34-mmc_sectorRead
.LM34:
        subi r16,lo8(-(1))
        sbci r17,hi8(-(1))
        ldi r24,hi8(512)
        cpi r16,lo8(512)
        cpc r17,r24
        brlo .L21
        .stabn 68,0,84,.LM35-mmc_sectorRead


~stefan

[Jörg Wunsch (Gast)]

Stackgröße kann man beim AVR-GCC nicht vorgeben, der Stack wird so
groß, wie er groß wird (man kann den Prozessor sowieso nicht wirklich
daran hindern ;-) und ,,wächst'' von oben nach unten.  Die Variablen
werden von unten nach oben belegt.

Irgendwie hast Du aber wohl mit Deinen Variablen insgesamt zu viel RAM
verbraten, so daß der tatsächlich für den Stack benötigte Platz mit
dem Speicherplatz Deines 512-Byte-Puffers (der ja bereits den halben
RAM einnimmt) kollidiert.  Da mußt Du mal analysieren, wofür der
restliche RAM so draufgeht.  Die Symboltabelle (avr-nm -n) ist dafür
ganz hülfreich.

Gern übersehen wird, daß string literals standardmäßig (also wenn sie
nicht via PSTR() deklariert werden und einer auf _P endenden Routine
übergeben werden) auch RAM benötigen (damit sie mit den normalen
String-Funktionen aus <string.h> kompatibel sind).  Vielleicht hast Du
davon recht viele?

[Stefan (Gast)]

Hallo,

danke fuer die Antwort!
Habe den Fehler gefunden. Es gab noch so einen grossen Puffer. Zwar
"nur" 509 Byte gross, aber das war eben insgesamt doch zu viel. Der
war in einer anderen Datei des Projektes die ich gar nicht mehr recht
in Erinnerung und voellig vergessen hatte. Und meine Fehlersuche
beschraenkte sich lediglich auf den Bereich um den sector buffer. :-)
Nun ja, gluecklicherweise kommt man auch gut ohne den anderen puffer
aus, so dass nun alles bestens ist.

Vielen Dank!

~stefan