AVR64DD20 - USART stürzt bei großem Buffer ab

[Max W. (crackerlino)]

Hallo liebes mikrocontroller.net - Forum,

ich habe heute die USART meines AVR64DD20 programmiert und mit ein paar 
Änderungen von der Bibliothek von Microchip selbst ( 
https://github.com/microchip-pic-avr-examples/avr64dd32-getting-started-with-i2c-mplabx 
, lediglich anderer Pin) verwendet. Die ganz gewöhnliche 
printf-Funktion, die jetzt den USART-stream verwendet, funktioniert für 
einzelne Werte und Texte tadellos. Jedoch ist mir aufgefallen, dass wenn 
ich:


int main(void) {

    USART0_Init();

    PORTA.DIR |= DSCK_PIN;

    char testbuffer2[1000];
    _delay_ms(10000);
    for (int i = 0; i< 1000; i++)
    {
        testbuffer2[i] = i;
    }
    testbuffer2[999] = '\0';
    while(1)
    {
        printf("%s", testbuffer2);
        _delay_ms(1000);
    }
}

nutze, ich nur noch garbage-data empfange ohne Grenzen. Der Delay wird 
nicht mehr erreicht und es kommt nur ein Stream an "0xFF" am Terminal 
an. Weiß jemand, was ich falsch mache? Sobald die Arraygröße von 
testbuffer2 größer als 100 ist, scheinen die Probleme zu beginnen. Es 
ist genug SRAM auf dem Controller vorhanden, da bis auf die USART und 
I2C-Inits nichts ausgeführt wird.

Liebe Grüße und lieben Dank im Voraus

crackerlino

[Falk B. (falk)]

Max W. schrieb:
> testbuffer2 größer als 100 ist, scheinen die Probleme zu beginnen. Es
> ist genug SRAM auf dem Controller vorhanden, da bis auf die USART und
> I2C-Inits nichts ausgeführt wird.

Mag sein, aber dein testbuffer2 ist eine lokale Variable in main(), die 
wird auf dem Stack angelegt. Mach aus der mal eine globale Variable.

[Max W. (crackerlino)]

Falk B. schrieb:
> Max W. schrieb:
>> testbuffer2 größer als 100 ist, scheinen die Probleme zu beginnen. Es
>> ist genug SRAM auf dem Controller vorhanden, da bis auf die USART und
>> I2C-Inits nichts ausgeführt wird.
>
> Mag sein, aber dein testbuffer2 ist eine lokale Variable in main(), die
> wird auf dem Stack angelegt. Mach aus der mal eine globale Variable.


Lieben Dank für die schnelle Antwort. Hab's getestet und leider das 
selbe Resultat. Hier Mal ein Bild vom Output. Baudrate und sonstiges 
stimmt, die Daten schicken ohne Pause.

[Peter D. (peda)]

Das ist nicht C&P Deines Codes, stimmts?
Du schreibst als erstes in testbuffer2[0] = 0; d.h. erzeugst einen 
leeren String und printf("%s" gibt gar nichts aus.

Warum wird hier wohl immer wieder gebetsmühlenartig gefordert, benutzte 
C&P oder den Dateianhang!

[Falk B. (falk)]

Max W. schrieb:
> Lieben Dank für die schnelle Antwort. Hab's getestet und leider das
> selbe Resultat. Hier Mal ein Bild vom Output.

Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf() 
zu senden, denn das sind Steuerzeichen, die weiß was machen. Auch eine 
Schleife von 0-1000 ist hier fragwürdig, weil da beim Speichern von i im 
Array ein Überlauf passiert. Dann kommen wieder Steuerzeichen.

[Andreas M. (amesser)]

Woher willst Du wissen ob Du genug Platz für so eine Variable auf dem 
Stack hast? Es kommt nicht nur auf die Menge des verfügbaren RAMs an, 
sondern auch darauf wie er genutzt wird. Dazu müsste man ins MAP file 
oder Linkerscript schauen. Wer weiß schon wie viel RAM alleine durch die 
Microchip Library belegt wird. Dazu noch printf(). Wenn es sich um das 
printf() aus der newlib in Standard config handelt dann genehmigt sich 
das gerne mal mehrere kB.

[Max W. (crackerlino)]

Falk B. schrieb:
> Max W. schrieb:
>> Lieben Dank für die schnelle Antwort. Hab's getestet und leider das
>> selbe Resultat. Hier Mal ein Bild vom Output.
>
> Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
> Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf()
> zu senden, denn das sind Steuerzeichen, die weiß was machen. Auch eine
> Schleife von 0-1000 ist hier fragwürdig, weil da beim Speichern von i im
> Array ein Überlauf passiert. Dann kommen wieder Steuerzeichen.

Nun, das Problem war ursprünglich, dass es mit Sensordaten bereits nicht 
funktionierte, sobald der Buffer größer gewählt wurde als 100, 
unabhängig davon ob die übertragene Länge 100 übersteigt oder nicht.

Die Steuerzeichen sollten bei hterm oder printf nicht zu Problemen 
führen, immerhin schicke ich auch float-bytes byteweise raus und da kann 
ich nicht garantieren, dass kein Steuerzeichen ankommt.

Die ASCII-Darstellung ist natürlich vollkommener Quatsch. Falls Bedarf 
besteht, kann ich den Output wieder als HEX abspeichern.

Ich habe Mal die Main hochgeladen, das Projekt ist an einem anderen 
Computer. Da sieht man die anderen Versuche zu printen. Der ewiglange 
printf-Text hat funktioniert.

[Max W. (crackerlino)]

Andreas M. schrieb:
> Woher willst Du wissen ob Du genug Platz für so eine Variable auf dem
> Stack hast? Es kommt nicht nur auf die Menge des verfügbaren RAMs an,
> sondern auch darauf wie er genutzt wird. Dazu müsste man ins MAP file
> oder Linkerscript schauen. Wer weiß schon wie viel RAM alleine durch die
> Microchip Library belegt wird. Dazu noch printf(). Wenn es sich um das
> printf() aus der newlib in Standard config handelt dann genehmigt sich
> das gerne mal mehrere kB.

Gut zu wissen, danke für den Hinweis!  Als globale Variable funktioniert 
es leider auch nicht.

[Falk B. (falk)]

Max W. schrieb:
> Ich habe Mal die Main hochgeladen, das Projekt ist an einem anderen
> Computer.

Schönes Chaos. Und dort sind ZWEI Arrays drin! 2x 1kB! Wieviel hat dein 
Controller?

Ich empfehle eine systematische Fehlersuche. Alles was nicht 
UNBEDINGT benötigt wird sollte auskommentiert werden!

Und den Fehler hier beachten!

Beitrag "Re: AVR64DD20 - USART stürzt bei großem Buffer ab"

Kann man so lösen, nach der Schleife

testbuffer2[0] = 1;
testbuffer2[999] = 0;

[Steve van de Grens (roehrmond)]

Falk B. schrieb:
> Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
> Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf()
> zu senden, denn das sind Steuerzeichen, die weiß was machen.

Das ist beim verwendeten Terminalprogramm schon so OK, das macht nicht 
"wer weiß was".

> Auch eine Schleife von 0-1000 ist hier fragwürdig

Die Schleife geht bis 999

> Dann kommen wieder Steuerzeichen.

Selbst wenn es so wäre, würde das die Ausgabe nicht beeinträchtigen, 
denn er schließt die Zeichenkette deppensicher ab:

> testbuffer2[999] = '\0';

Falk B. schrieb:
> Kann man so lösen, nach der Schleife
> testbuffer2[999] = 0;

Ach was!?

Falk B. schrieb:
> Schönes Chaos. Und dort sind ZWEI Arrays drin! 2x 1kB!

Wo denn?

[Falk B. (falk)]

Steve van de Grens schrieb:
>> Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
>> Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf()
>> zu senden, denn das sind Steuerzeichen, die weiß was machen.
>
> Das ist beim verwendeten Terminalprogramm schon so OK, das macht nicht
> "wer weiß was".

Ich rede von der printf() Funktion im Controller! Im Idealfall sendet 
die einfach ALLES bis zum Nullterminator.

>> Auch eine Schleife von 0-1000 ist hier fragwürdig
>
> Die Schleife geht bis 999

Ja und? Aber wenn testbuffer2[0]=0 von der Schleife beschrieben wird, 
gibt printf() nie was aus!

> Selbst wenn es so wäre, würde das die Ausgabe nicht beeinträchtigen,
> denn er schließt die Zeichenkette deppensicher ab:
>
>> testbuffer2[999] = '\0';

Ja, sogar doppeldeppensicher mit 0 am Anfang! ;-)

[Falk B. (falk)]

Steve van de Grens schrieb:
> Falk B. schrieb:
>> Schönes Chaos. Und dort sind ZWEI Arrays drin! 2x 1kB!
>
> Wo denn?

Im Anhang?

Beitrag "Re: AVR64DD20 - USART stürzt bei großem Buffer ab"

[Steve van de Grens (roehrmond)]

Falk B. schrieb:
> Ich rede von der printf() Funktion im Controller! Im Idealfall sendet
> die einfach ALLES bis zum Nullterminator.

Sicher, wo ist jetzt das Problem?

> Aber wenn testbuffer2[0]=0 von der Schleife beschrieben wird,
> gibt printf() nie was aus!

Ja, das hat der Peter schon gut erkannt.

[Steve van de Grens (roehrmond)]

Falk B. schrieb:
>> Wo denn?
> Im Anhang

Ah verstehe. jetzt ergibt dein Kommentar auch für mich Sinn.

[Peter D. (peda)]

Max W. schrieb:
> Hier Mal ein Bild vom Output.

Das sieht sehr nach falscher Baudrate aus.
Da steht ja 115,2kBaud. Welchen Quarz hast Du denn angeschlossen, damit 
der Fehler klein genug (<1%) ist?

[Max W. (crackerlino)]

Peter D. schrieb:
> Max W. schrieb:
>> Hier Mal ein Bild vom Output.
>
> Das sieht sehr nach falscher Baudrate aus.
> Da steht ja 115,2kBaud. Welchen Quarz hast Du denn angeschlossen, damit
> der Fehler klein genug (<1%) ist?

Gar keinen, ich benutze die interne Clock. Es funktioniert ja für alles 
andere, dieser Output ist "random" und hört nie auf. Also stoppt auch 
nicht kurz für eine Sekunde. Und wenn ich eine while(1); dranhänge, wird 
diese nie erreicht. Irgendwas passiert mit der USART, dass da alles 
schief läuft.

Ist der Buffer klein genug oder printe ich (wie in der angehängenten 
main_1_.c) einen sehr langen const String aus, funktionierts ohne 
Probleme. Aber verwende ich ein 1 kB großes Array geht alles den Bach 
runter.

Unabhängig davon ob ich
1. zu oft nullterminiere oder das Array mit einem fixen char-Wert fülle,
2. das zweite 1 kB Array rauslösche und das erste Array als globale 
Variable deklariere,
3. Baudrate anpasse.

Liebe Grüße

[C-hater (c-hater)]

Max W. schrieb:

> Gar keinen, ich benutze die interne Clock.

Welche genau und wie konfiguriert? Das Teil hat verschiedene interne 
Taktquellen und sind obendrein recht vielfältig konfigurierbar.

> Es funktioniert ja für alles
> andere, dieser Output ist "random" und hört nie auf.

Poste einfach mal das fertige Programm, bevorzugt als Hex-File. Dann 
kann man reinschauen und sehen, was wirklich passieren sollte.

[Max W. (crackerlino)]

C-hater schrieb:
> Max W. schrieb:
>
>> Gar keinen, ich benutze die interne Clock.
>
> Welche genau und wie konfiguriert? Das Teil hat verschiedene interne
> Taktquellen und sind obendrein recht vielfältig konfigurierbar.
>

Ich nutze den internen "high-frequency oscillator". Die Taktfrequenz ist 
dabei default 4 MHz und sonst wird auch nichts an der Clock gedreht. AVR 
ist für mich relativ neu und ich hatte schon genug Problem, dass 
"CPU_CCP"-Register zu finden, dass im Datenblatt und teilweise in den 
Header noch als "CPU.CCP" in den Kommentaren erwähnt wird.

>> Es funktioniert ja für alles
>> andere, dieser Output ist "random" und hört nie auf.
>
> Poste einfach mal das fertige Programm, bevorzugt als Hex-File. Dann
> kann man reinschauen und sehen, was wirklich passieren sollte.

Danke für den Hinweis! Mach ich gleich am Montag.

[C-hater (c-hater)]

Max W. schrieb:

> Ich nutze den internen "high-frequency oscillator". Die Taktfrequenz ist
> dabei default 4 MHz

Das sollte OK sein, zumindest so lange sich die Umgebungstemperatur 
nicht nennenswert von 25°C entfernt, also im Bereich "Zimmertemperatur" 
bleibt.

[S. L. (sldt)]

Gab es da nicht vor kurzem einen ahnlichen Fall - irgendwas mit String 
mal als Variable, mal als Konstante?

[Sebastian W. (wangnick)]

Was tut printf("%s",testbuffer2) genau? Streamt die Bibliothek an dieser 
Stelle testbuffer2 direkt an die UART, oder wird ein temporärer Speicher 
alloziert, der Inhalt von testbuffer2 dorthin kopiert, und dann der 
temporäre Speicher an die UART gestreamt?

LG, Sebastian

[C-hater (c-hater)]

S. L. schrieb:
> Gab es da nicht vor kurzem einen ahnlichen Fall - irgendwas mit String
> mal als Variable, mal als Konstante?

Kann ich mich nicht erinnern. Kannst du das genauer spezifizieren?

Wenn nicht, warten wir halt bis Montag. Dann kommen die belastbaren 
Fakten vom TO, so hat er zumindest versprochen.

Ich bin wirklich gespannt. Die DD sind ja wirklich noch sehr frisch. Ein 
Erratum wäre also durchaus möglich. Aber auch ein Fehler in den MC-Libs 
ist nicht ausgeschlossen.

[Sebastian W. (wangnick)]

Peter D. schrieb:
> Das sieht sehr nach falscher Baudrate aus.

Der Ausschnitt spricht eher für korrekte Baudrate aber falschen 
Speicherbereich ...

LG, Sebastian

[S. L. (sldt)]

>> Gab es da nicht vor kurzem einen ahnlichen Fall - irgendwas mit String
>> mal als Variable, mal als Konstante?

> Kann ich mich nicht erinnern. Kannst du das genauer spezifizieren?

Es war wohl dies hier:
Beitrag "Fehlerhafte Adressierung von lokalen Arrays bei tinyAVR(R) 0-series"

Für mehr reicht es aber heute morgen nicht, und ob es wirklich etwas mit 
dem Fall hier zu tun hat ...?

[Eckhard T. (etik)]

Ist DSCK_PIN eine Bitmaske oder die Pin-Nummer?

[Wilhelm M. (wimalopaan)]

Schau Mal nach, wie groß der interne Puffer von dem scheiss printf ist. 
Der wird doch statisch sein, oder?
Schau Mal in die Symbol-Tabelle.

[Harald K. (kirnbichler)]

Wilhelm M. schrieb:
> Schau Mal nach, wie groß der interne Puffer von dem scheiss printf ist.

Wieso sollte es einen haben?

[C-hater (c-hater)]

S. L. schrieb:

> Es war wohl dies hier:
> Beitrag "Fehlerhafte Adressierung von lokalen Arrays bei tinyAVR(R) 0-series"
>
> Für mehr reicht es aber heute morgen nicht, und ob es wirklich etwas mit
> dem Fall hier zu tun hat ...?

Kann man wohl nicht völlig ausschließen, auch wenn das Problem zunächst 
ein anderes zu sein scheint. Es könnte trotzdem sein, das beides im Kern 
auf denselben Fehler zurückzuführen ist, wo auch immer der genau 
angesiedelt sein mag.

Deswegen wollte ich auf Binärebene schauen, was da die MCU tatsächlich 
als Programm erreicht. Wenn da schon klar wird, dass es fehlerhaft ist, 
dann kann der Fehler nur irgendwo in der gcc-Toolchain (oder natürlich 
beim Programmierer des jeweiligen Codebestandteils selber) liegen.

Interessant für mich persönlich wird es aber eher dann, wenn sich 
herausstellt, dass das Programm auf Binärebene formal OK ist und 
funktionieren müsste, aber trotzdem Mist passiert.

[C-hater (c-hater)]

Max W. schrieb:

> Danke für den Hinweis! Mach ich gleich am Montag.

Dann bitte auch etwas hinzufügen, aus dem der Zustand der Fuses 
hervorgeht. Also notfalls Screenshot aus dem Studio.

[Falk B. (falk)]

Erst einfacher Test. Den Buffer klein machen, 10 Zeichen. Dann 
schrittweise verdoppeln, bis der Fehler auftritt. Dann nachdenken.

[C-hater (c-hater)]

Moby A. schrieb im Beitrag #7450543:
> Tja Freundchen, Hochsprache hat ihren Preis 😉

Das ist sicher so, aber das wissen inzwischen auch alle, die es 
interessiert. Und den Fetischisten ist eh' nicht zu helfen. Die bleiben 
bei ihrer Bibel.

[Peter D. (peda)]

Max W. schrieb:
> Ich nutze den internen "high-frequency oscillator". Die Taktfrequenz ist
> dabei default 4 MHz und sonst wird auch nichts an der Clock gedreht.

Die Frage ist aber, ob Deine Lib 115.2kBaud bei 4MHz auch unterstützt.
Sende doch einfach mal erst einen konstanten String "Hallo Test\n", 
erstmal ohne haufenweise Arrays im RAM zu reservieren.

Debuggen heißt nicht, ein Programm als unteilbaren Brocken zu testen, 
sondern erstmal jede Teilfunktion für sich.

[S. L. (sldt)]

an Peter Dannegger:
> Sende doch einfach mal erst einen konstanten String "Hallo Test\n" ...

Max W. schrieb:
> Ist der Buffer klein genug oder printe ich (wie in der angehängenten
> main_1_.c) einen sehr langen const String aus, funktionierts ohne
> Probleme. Aber verwende ich ein 1 kB großes Array geht alles den Bach
> runter.

Und der genannte String besteht ja ausschließlich aus Kleinbuchstaben.

[Max W. (crackerlino)]

Hi,


hier ist Mal das Main-Programm, dass bei mir äußerst komischen Output 
gibt. Baudrate ist auf 115200, der TX-Pin ist Pin 4 Port D. Verwendet 
wurde der AVR64DD20.

#define ARRAY_LEN 100

char rxBuf[ARRAY_LEN] = {0x65};

int main(void) {

    USART0_Init();
    configureClock();

    _delay_ms(1000);

    for (int i = 0; i < ARRAY_LEN; i++)
    {
        rxBuf[i]= 0x65;
    }

    rxBuf[ARRAY_LEN-1] = '\0';

    printf("%s", rxBuf);

    while(1);
}

Der Output führt bei mir zu dem selben, wie in dem Bild oben gezeigt.

Anbei die HEX-File.

Liebe Grüße

[Max W. (crackerlino)]

Und hier sind noch die einzelnen Dateien. Ich wusste nicht was lieber 
ist, ein paar main/USART-Files oder das ganze Projekt hochzuladen.

[C-hater (c-hater)]

Max W. schrieb:
> Und hier sind noch die einzelnen Dateien. Ich wusste nicht was lieber
> ist, ein paar main/USART-Files oder das ganze Projekt hochzuladen.

Dieses "Werk" kann unmöglich Quelle für das gepostetete Hexfile gewesen 
sein. Weil: es läßt sich auf Grund eines Tippfehlers und eines nicht 
vorhandenen Includefiles schonmal garnicht übersetzen.
Weiteren Kram, der unglücklich bis falsch ist, schenke ich mir hier. Da 
sollen die C-Fetischisten sich die Mäuler drüber zerreissen, das macht 
denen Spaß.

Nach der Korrektur der gröbsten Fehler kommt jedenfalls tatsächlich 
erstmal was raus.

Was da rauskommt, hat allerdings schon strukturell kaum etwas mit dem 
Hexfile zu tun, was du geposted hast. Das Hexfile stammt mit an 
Sicherheit grenzender Wahrscheinlichkeit von einem völlig anderen Target 
und wurde obendrein mit einiger Wahscheinlichkeit 
"post-build"-manipuliert.

Ich würde mal sagen: Troll. Für einen Troll immerhin deutlich über dem 
üblichen Niveau, aber trotzdem verdammenswert.

[S. L. (sldt)]

Wie magst du deine Rednerei
Nur gleich so hitzig übertreiben?


an Max W.:
Zwar habe ich gewisse Zweifel, dass Ihnen das weiterhilft, denn a) habe 
ich eine zusammengestoppelte C-Umgebung (nicht fragen!) und b) nur einen 
AVR128DB28, trotzdem: das zuletzt Gezeigte läuft hier, mutatis mutandis, 
es kommen 99 'e' an.
  Es kommen auch z.B. 999, mit ARRAY_LEN = 1000.

[C-hater (c-hater)]

S. L. schrieb:

> Zwar habe ich gewisse Zweifel, dass Ihnen das weiterhilft, denn a) habe
> ich eine zusammengestoppelte C-Umgebung (nicht fragen!)

Und die stört sich nicht an falschen Symbolen und fehlenden Includes? 
Dann stimmt an deiner Umgebung definitiv auch was nicht...

[S. L. (sldt)]

Nun ja, dieses '#include "testfunctions.h"' habe ich auskommentiert, und 
den Ausgabepin für USART0 auf mein A0 gelegt. Mehr aber nicht.

[C-hater (c-hater)]

S. L. schrieb:
> Nun ja, dieses '#include "testfunctions.h"' habe ich auskommentiert, und
> den Ausgabepin für USART0 auf mein A0 gelegt. Mehr aber nicht.

Ernsthaft? Also mein Includefile für den AVR64DD20 kennt jedenfalls kein 
Symbol "CLKCTRL_FRQSEL_24M_gc". Das heißt da: "CLKCTRL_FREQSEL_24M_gc".

Und genau so heißt es auch in meinem Includefile für den von dir 
verwendeten AVR128DB28.

Also zumindest das mußt du ebenfalls noch geändert haben...

[S. L. (sldt)]

Nee, das ist alt: das wurde von Microchip irgendwann mal geändert, und 
ich hatte das von Hand nachgezogen. War vor ein paar Wochen hier erwähnt 
worden.

[C-hater (c-hater)]

S. L. schrieb:
> Nee, das ist alt: das wurde von Microchip irgendwann mal geändert, und
> ich hatte das von Hand nachgezogen. War vor ein paar Wochen hier erwähnt
> worden.

Was ist alt? Das mit dem "FREQ" oder das mit dem "FRQ"? Ich habe 
testweise gerade mal das Pack aktualisiert, aber das ist immer noch auf 
"FREQ" geeicht. Also dürfte "FRQ" alt bis bis längst begraben sein sein. 
Sprich: falls es so eine Änderung tatsächlich mal gegeben hat, muß das 
vor sehr viel längerer Zeit als nur "ein paar Wochen" passiert sein.

[S. L. (sldt)]

Die Änderung muss vor ein oder zwei Jahren erfolgt sein, aktuell ist 
'FRQSEL'; dass es hier im Forum erwähnt wurde, liegt einige Wochen 
zurück (aber ich finde es jetzt nicht mehr).
  Schauen Sie mal in die diversen Datenblätter unter CLKCTRL-OSCHFCTRLA.

[S. L. (sldt)]

Ah! - doch noch gefunden; übrigens beim selben Fragesteller, Max W.:
Beitrag "Re: AVR64DD28 Clock Source ändern"

[C-hater (c-hater)]

S. L. schrieb:

> aktuell ist
> 'FRQSEL'

Nein, sicher nicht. Aktuell ist das Pack AVR-Dx_DFP in der Version 
2.2.253. Und das heißt der Kram "FREQSEL". Und so hieß er auch schon in 
der Version 1.8.95 (das war die bei mir installierte vor dem heutigen 
Upgrade). Und die weist sich mit dem Datum 2021-04-29 aus.

Also: mindestens seit zwei vollen Jahren heißt diese Scheiße "FREQSEL".

[C-hater (c-hater)]

C-hater schrieb:

> Also: mindestens seit zwei vollen Jahren heißt diese Scheiße "FREQSEL".

Was übrigens bedeutet: für den DD hieß sie wohl schon immer so. Ich 
hatte jetzt keine Lust, die ollen Packs runterzuladen, aber der DD ist 
sicher nicht viel älter als 2021-04-29. D.h.: mit einiger 
Wahrscheinlichkeit hat das bei dem niemals anders geheißen.

[S. L. (sldt)]

Also ich weiß ja nicht, wo bzw. was Sie herunterladen, aber in meinem 
Microchip.AVR-Dx_DFP.2.3.272 mit '2022-12-16' steht es sowohl in 
AVR64DD20def.inc als auch in ioavr64dd20.h mit 'FRQSEL'.
  Ist doch aber nur eine Petitesse, da stehen wir drüber, so 
fehlertolerant sind wir allemal, und zumindest bei mir kommt noch die 
Altersmilde hinzu.

Zurück zum eigentlichen Thema, Max W. wird sicher schon ungeduldig.

[C-hater (c-hater)]

S. L. schrieb:
> Also ich weiß ja nicht, wo bzw. was Sie herunterladen

Von MC, denke ich doch.

> aber in meinem
> Microchip.AVR-Dx_DFP.2.3.272 mit '2022-12-16'

Das bietet er mir auch mit explizitem "Update" überhaupt nicht an. Da 
haben die MC-Wichser wohl was gegen Windows7...

Naja, stört natürlich die "Telemetrie" ein wenig. Werde ich also mal mit 
dem dienstlichen Windows10 weiter durchexerzieren müssen. Da läuft die 
"Telemetrie" ja vermutlich ungestört und obendrein massiv gepimpt. Muss 
ich mir privat aber nicht antun...

Ich muß die Diskussion über dieses Thema also erst einmal vertagen.

> Ist doch aber nur eine Petitesse, da stehen wir drüber, so
> fehlertolerant sind wir allemal

Ja klar. Es bleibt der Fakt, dass das Hexfile niemals durch einen 
einfachen Compilerlauf aus den geposteten Quellen entstanden sein kann. 
Weder mit einer aktuellen noch mit einer rezenten Version der 
AVR64DD20-Includes.

Das ist und bleibt natürlich der Punkt.

[A. B. (Firma: ab) (bus_eng)]

Der Link zum Microchip Packs Repository ist.
http://packs.download.atmel.com

Aktuell für Dx:  Atmel AVR-Dx Series Device Support (2.2.253) 
(2022-12-16)

Addendum:

Es existiert ein zweites Repository:
https://packs.download.microchip.com

Aktuell für Dx: Microchip AVR-Dx Series Device Support (2.3.272) 
(2022-12-16)

[Max W. (crackerlino)]

C-hater schrieb:
> Max W. schrieb:
>> Und hier sind noch die einzelnen Dateien. Ich wusste nicht was lieber
>> ist, ein paar main/USART-Files oder das ganze Projekt hochzuladen.
>
> Dieses "Werk" kann unmöglich Quelle für das gepostetete Hexfile gewesen
> sein. Weil: es läßt sich auf Grund eines Tippfehlers und eines nicht
> vorhandenen Includefiles schonmal garnicht übersetzen.
> Weiteren Kram, der unglücklich bis falsch ist, schenke ich mir hier. Da
> sollen die C-Fetischisten sich die Mäuler drüber zerreissen, das macht
> denen Spaß.


Hi,

ich bin kein Troll, wirklich nicht. Ich habe nicht gemerkt, dass der 
Student die testfunctions.h inkludiert hat, die man für die usart gar 
nicht braucht. Er dachte sich wohl, viel hilft viel und hat alles 
überall inkludiert.

> Nach der Korrektur der gröbsten Fehler kommt jedenfalls tatsächlich
> erstmal was raus.
>
> Was da rauskommt, hat allerdings schon strukturell kaum etwas mit dem
> Hexfile zu tun, was du geposted hast. Das Hexfile stammt mit an
> Sicherheit grenzender Wahrscheinlichkeit von einem völlig anderen Target
> und wurde obendrein mit einiger Wahscheinlichkeit
> "post-build"-manipuliert.
>
> Ich würde mal sagen: Troll. Für einen Troll immerhin deutlich über dem
> üblichen Niveau, aber trotzdem verdammenswert.

Welche grobe Fehler? Das mit der nicht inkludierten .h ist nun eben 
Quatsch, ich wollte sie nicht mitschicken, weil sie nun eben nicht von 
mir ist.

C-hater schrieb:
> S. L. schrieb:
>> Nun ja, dieses '#include "testfunctions.h"' habe ich auskommentiert, und
>> den Ausgabepin für USART0 auf mein A0 gelegt. Mehr aber nicht.
>
> Ernsthaft? Also mein Includefile für den AVR64DD20 kennt jedenfalls kein
> Symbol "CLKCTRL_FRQSEL_24M_gc". Das heißt da: "CLKCTRL_FREQSEL_24M_gc".
>
> Und genau so heißt es auch in meinem Includefile für den von dir
> verwendeten AVR128DB28.
>
> Also zumindest das mußt du ebenfalls noch geändert haben...

Wie gesagt, ich bin neu in der Programmierung von AVR und habe keine 
Ahnung, was sich über die Jahre geändert hat. Die Zeile Code, die in 
configureClock() verwendet wird, ist 1:1 aus dem Thread der zuvor 
gepostet wurde.


> Ja klar. Es bleibt der Fakt, dass das Hexfile niemals durch einen
> einfachen Compilerlauf aus den geposteten Quellen entstanden sein kann.
> Weder mit einer aktuellen noch mit einer rezenten Version der
> AVR64DD20-Includes.
>
> Das ist und bleibt natürlich der Punkt.

Ganz ehrlich: Ich habe dann einen Fehler beim Auswählen der Datei 
gemacht. Ich habe die einzige .hex-File, die ich im Projekt gefunden 
habe, hochgeladen, nachdem ich vorher das Projekt compiliert habe.

Liebe Grüße

[Max W. (crackerlino)]

S. L. schrieb:

> an Max W.:
> Zwar habe ich gewisse Zweifel, dass Ihnen das weiterhilft, denn a) habe
> ich eine zusammengestoppelte C-Umgebung (nicht fragen!) und b) nur einen
> AVR128DB28, trotzdem: das zuletzt Gezeigte läuft hier, mutatis mutandis,
> es kommen 99 'e' an.
>   Es kommen auch z.B. 999, mit ARRAY_LEN = 1000.

Danke schön fürs Ausprobieren! Auf meinem AVR64DD28 funktioniert der 
Code leider auch.

[S. L. (sldt)]

Verstehe ich das richtig: Sie haben einen AVR64DD28 und einen AVR64DD20, 
und nur bei Letzterem gibt es Probleme? Falls ja, so sei c-haters Frage 
nach den Fuses wiederholt, für beide Controller. Mehr fällt mir erstmal 
nicht ein.

[Max W. (crackerlino)]

Hier ein Video, wie es aussieht und hoffentlich zeigt, dass das kein 
Getrolle ist.

Liebe Grüße

[Max W. (crackerlino)]

S. L. schrieb:
> Verstehe ich das richtig: Sie haben einen AVR64DD28 und einen
> AVR64DD20,
> und nur bei Letzterem gibt es Probleme? Falls ja, so sei c-haters Frage
> nach den Fuses wiederholt, für beide Controller. Mehr fällt mir erstmal
> nicht ein.

Hier sind die Fuses:

// AVR64DD20 Configuration Bit Settings

// 'C' source line config statements

#include <avr/io.h>

FUSES = {
  .WDTCFG = 0x00, // WDTCFG {PERIOD=OFF, WINDOW=OFF}
  .BODCFG = 0x00, // BODCFG {SLEEP=DISABLE, ACTIVE=DISABLE, 
SAMPFREQ=128Hz, LVL=BODLEVEL0}
  .OSCCFG = 0x00, // OSCCFG {CLKSEL=OSCHF}
  .SYSCFG0 = 0xD0, // SYSCFG0 {EESAVE=CLEAR, RSTPINCFG=GPIO, 
UPDIPINCFG=UPDI, CRCSEL=CRC16, CRCSRC=NOCRC}
  .SYSCFG1 = 0x08, // SYSCFG1 {SUT=0MS, MVSYSCFG=DUAL}
  .CODESIZE = 0x00, // CODESIZE {CODESIZE=User range:  0x0 - 0xFF}
  .BOOTSIZE = 0x00, // BOOTSIZE {BOOTSIZE=User range:  0x0 - 0xFF}
};

LOCKBITS = 0x5CC5C55C; // {KEY=NOLOCK}



Ich hoffe ich hab die Einstellung richtig kopiert, habe aber auch nichts 
aktiv daran verändert.

[Falk B. (falk)]

Max W. schrieb:
> Hier ein Video, wie es aussieht und hoffentlich zeigt, dass das kein
> Getrolle ist.

Naja, wir haben schon deutlich schlimmere Sachen gesehen. Aber du musst 
an deiner Kommunikation arbeiten, siehe Netiquette. Dazu gehört hier 
im Speziellen

- vollständigen, fehlerfrei compilierbaren Code als Anhang einfügen
- eine klare, explizite Fehlerbeschreibung

Du hast nie gesagt, daß dauerhaft Zeichen empfangen werden! Das sieht 
erst auf deinem Video.

Wir stellen fest. Dein UART funktioniert. Ein konstanter String wird 
fehlerfrei ausgegeben. Das Array, auch wenn es mit 0x65 gefüllt und mit 
0 terminiert ist, gibt erst viele 0x20 (Leerzeichen) und dann 0xFF aus. 
Sehr merkwürdig. Das sieht fast so aus, als ob der Pointer auf den Flash 
zeigen würde. Das sollte er aber nicht. Printf der libc vom AVR gcc 
kennt zwei Strings

%s (kleines s) Pointer auf RAM
%S (großes S) Pointer auf Flash

Aber in deinem Video ist es ein kleines s. Das sollte funktionieren.

[Falk B. (falk)]

Max W. schrieb:
> Ich hoffe ich hab die Einstellung richtig kopiert, habe aber auch nichts
> aktiv daran verändert.

Bleibt die Frage, ob und wie die Fuse-Einstellungen in die echten Fuses 
kommen? Es gibt das Wege. Aber funktionieren die bei dir WIRKLICH?
Sollte aber egal sein, der UART funktioniert.

[Falk B. (falk)]

Noch ein Tipp zum CCP-Register. Das sollte man NICHT naiv so in C 
hinschreiben! Denn je nach Compilereinstellung kann das auch mal nicht 
so optimal umgesetzt werden und dann funktioniert es nicht. Man sollte 
das IMMER mit einem Inline-ASM-Makro machen.

Beitrag "Re: AVR128, CCP und Optimierung"

[S. L. (sldt)]

> Du hast nie gesagt, daß dauerhaft Zeichen empfangen werden!
Doch, doch, hat er, im Verlauf der Diskussion:
> dieser Output ist "random" und hört nie auf. Also stoppt auch
> nicht kurz für eine Sekunde. Und wenn ich eine while(1);
> dranhänge, wird diese nie erreicht.

Fuses: das sind die Default-Werte, folglich unauffällig.
  Dann wäre jetzt die nächste Frage nach dem Assemblerlisting und den 
Optionen beim Build-Prozess, aber da kenne ich mich kaum aus, überlasse 
ich lieber Spezialisten.

[Falk B. (falk)]

Zum eigentlichen Problem. Im Video funktioniert es auch nicht mit einem 
100er Array! Sehr merkwürdig! Also mit Größe 10 testen! Wenn auch das 
nicht geht, eine Schleife schreiben und die einzelnen Zeichen manuell 
per printf() ausgeben. Da ist nur zum testen! Nicht als Workaround.

 for (int i = 0; i < ARRAY_LEN; i++)
    {
        printf("%c", rxBuf[i]);
    }

[S. L. (sldt)]

an Max W.:

Da muss es doch einen Unterschied beim Build-Prozess geben im Vergleich 
zu Ihrem AVR64DD28 - einfach mal vergleichen.

[Falk B. (falk)]

Max W. schrieb:
>> Verstehe ich das richtig: Sie haben einen AVR64DD28 und einen
>> AVR64DD20,
>> und nur bei Letzterem gibt es Probleme?

Kann es sein, daß bei dem IC, wo es nicht geht, der falsche Controller 
in der IDE eingestellt ist und dadurch irgendwas mit den 
Speicherbereichen nicht stimmt? Vor allem mit dem RAM?

[S. L. (sldt)]

Nee, ist gleich.

Ich vermute eher, dass der Fehler beim Vergleich der beiden Build-Files 
zu finden ist.

[S. L. (sldt)]

an Falk Brunner:

Ich habe von C fast keine Ahnung, also: in dem Filmchen läuft das printf 
bei 00:35 zum erstenmal in den Flash (übrigens bei 00:41 wieder, also 
ganz grob nach 6 s entsprechend 64 KiB bei 115200 kBd) und findet dort 
0x0C 0x94 0x51 0x00 - warum stoppt es nicht an dieser Stelle, ich dachte 
immer, in C seien Strings mit 0x00 terminiert?

[Peter D. (peda)]

S. L. schrieb:
> warum stoppt es nicht an dieser Stelle

Vermutlich zeigt der SP in den Wald und daher geht das RET nicht zurück, 
sondern woanders hin.
Es sieht also nur so aus, als würde printf nicht beendet.

[S. L. (sldt)]

Das heißt, dass bereits im Vorfeld etwas schiefgeht, denn die Ausgabe 
beginnt ja nicht mit den 'e's, sondern mit Blanks.

[Dieter S. (ds1)]

Für eine genauere Untersuchung wären die beiden HEX Dateien interessat: 
diejenige, die auf dem AVR64DD28 funktioniert und die, die auf dem 
AVR64DD20 nicht funktioniert.

Idealerweise auch die beiden ELF Dateien (unter der Annahme daß die 
Toolchain auch eine ELF Datei erzeugt), alternativ die MAP Dateien.

[Falk B. (falk)]

S. L. schrieb:
> Ich habe von C fast keine Ahnung, also: in dem Filmchen läuft das printf
> bei 00:35 zum erstenmal in den Flash

Das scheint so, sollte aber nicht sein. Der Pointer rxBuf zeigt auf RAM!

> (übrigens bei 00:41 wieder, also
> ganz grob nach 6 s entsprechend 64 KiB bei 115200 kBd) und findet dort
> 0x0C 0x94 0x51 0x00 - warum stoppt es nicht an dieser Stelle, ich dachte
> immer, in C seien Strings mit 0x00 terminiert?

Gute Frage.

[Falk B. (falk)]

S. L. schrieb:
> Das heißt, dass bereits im Vorfeld etwas schiefgeht, denn die Ausgabe
> beginnt ja nicht mit den 'e's, sondern mit Blanks.

IN der Tat. Darum auch mehrfach mein Hinweis, mal mit einem sehr kleinen 
Array mit 10 Elementen zu testen. Und mit Einzelausgabe. Man sollte die 
Hinweise auch mal lesen und umsetzen, das dauert nur wenige Minuten.

[S. L. (sldt)]

> Der Pointer rxBuf zeigt auf RAM!

Läuft halt bei 0x7FFF (INTERNAL_SRAM_END) einfach weiter, in den 
Mapped-Flash-Bereich hinein.

Edit:

Nee, kann so auch nicht stimmen: also Mapped-Flash schon, aber dass da 
im SRAM nur 0xFFs stehen sollen ...?

[Sebastian W. (wangnick)]

Ich würde trotz allem immer noch gerne den Sourcecode vom hier 
verwendeten printf() sehen. Ich kann mir vorstellen, dass die 
Implementierung bei der Verwendung von %s eine Längenobergrenze der 
Zeichenkette voraussetzt.

LG, Sebastian

[Johann L. (gjlayde)]

printf gibt einfach zeichenweise via der per stdout gegebenen Funktion 
aus.  Zumindest wenn AVR-LibC verwendet wird.

[Wilhelm M. (wimalopaan)]

In der avr-libc ist der Buffer in printf() 11 Bytes groß (Stack). Wird 
aber nicht für %s verwendet.

[Johann L. (gjlayde)]

Puffer???

[Wilhelm M. (wimalopaan)]

Alternativ kann man auch mal fputc() verwenden, um vfprintf() 
auszuschließen.

[Sebastian W. (wangnick)]

Max W. schrieb:
> mit ein paar Änderungen von der Bibliothek von Microchip selbst (
> 
https://github.com/microchip-pic-avr-examples/avr64dd32-getting-started-with-i2c-mplabx
> , lediglich anderer Pin) verwendet. Die ganz gewöhnliche
> printf-Funktion, die jetzt den USART-stream verwendet,

Ist das denn geklärt, dass der TO wirklich die avr-libc verwendet?

LG, Sebastian