Hallo, warum unterscheiden bzw. wo unterscheiden sich die beiden Formate in der Code erstellung? Hintergrund: Ich habe ursprünglich den ethersex Bootloader verwendet und damit binarys geflasht. Nun hatte ich das Problem das der Code nicht sauber ausgeführt wurde. Das Äuserte sich in der fehlerhaften Übertragungen des Uart. Ich bin ums verrecken nicht hinter den Fehler gekommen. Dann habe ich das binary File mal direkt geflasht und ... fehlerhafte Übertragungen. Erstelle ich aber ein Hex File (Selber Code) und flashe direkt ist alles ok. Ich bin bisher nicht dahinter gekommen warum das so ist. System Atmega644 16MHz und avrdude Kann mir einer erklären worauf ich bei binarys achten muss. Gerry
Bei neueren GCC version gibt es m.M.n. die Möglichkeit die Fuses direkt ins Hexfile zu integrieren. Der Programmer muss dies dann natürlich unterstützen, aber falls deiner dies kann, dann ist das Problem somit wohl auch gleich gefunden. Ich nehme an die Fehler mit der Uart stammen von falschen Fusebits, die in den Binary files nicht enthalten sind und somit manuell vorgenommen werden müssten.
Hallo, die Fusebits sind es nicht. Der Uart funktioniert ja soweit. Nur werden halt nicht alle Zeichen übertragen. Beispiel String "12345 12345 AAAAA BBBB" steht fest im Programm Mit binary wird "AAA BBBB" übertragen bei ihex alles. Ich hab das Gefühl das es irgendetwas mit dem Speicherbereich zu tun hat. Aber wie gesagt ich komm nicht dahinter. Kann es sein das Progmem Chars anders bei binary code behandelt/abgelegt werden? Gerry
Gerry L. schrieb: > Kann es sein das Progmem Chars anders bei binary code behandelt/abgelegt > werden? Nein, beides sind reine Image-Formate, d. h. sie enthalten einen Speicherabzug. Bei Intel Hex gibt's zusätzlich noch Adressinfor- mationen, sodass man nicht benötigte Adressen überspringen kann und auch bei Adressen ≠ 0 beginnen kann, während ein reines Binary implizit bei Adresse 0 beginnt und nur einen einzigen, in sich zusammenhängenden Speicherblock enthalten kann. Von irgendwelchen Spielereien auf Quell- oder Objektcodeebene wie im Flash abgelegten Daten haben beide Formate keinerlei Information mehr enthalten.
Danke für die Infos, leider erklärt das immer noch nicht warum nun ihex geht und binary nicht. Ich hab den Bootloader zwar mitlerweile auf einen ihex loader umgestellt aber eine Lösung des Problems ist es nicht. Ich erlaube mir mal ein Stück code zu zeigen. Bei welchem es Probleme gibt. Beschreibe ich den Uart mit
1 | void usart_write_str(char *str){ |
2 | |
3 | while (*str){ |
4 | usart_write_char(*str++); |
5 | }
|
6 | }
|
ist alles bestens, aber mit der folgenden Routine werden Zeichen verschluckt.
1 | usart_write("DNS %1i.%1i.%1i.%1i\r\n", dns_server_ip[0], dns_server_ip[1], dns_server_ip[2], dns_server_ip[3]); |
2 | |
3 | #define usart_write(format, args...) usart_write_P(PSTR(format) , ## args)
|
4 | |
5 | void usart_write_P(const char *Buffer,...){ |
6 | |
7 | va_list ap; |
8 | va_start (ap, Buffer); |
9 | |
10 | int format_flag; |
11 | char str_buffer[10]; |
12 | char str_null_buffer[10]; |
13 | char move = 0; |
14 | char Base = 0; |
15 | int tmp = 0; |
16 | char by; |
17 | char *ptr; |
18 | |
19 | //Ausgabe der Zeichen
|
20 | for(;;){ |
21 | by = pgm_read_byte(Buffer++); |
22 | |
23 | if(by==0) break; // end of format string |
24 | |
25 | if (by == '%'){ |
26 | |
27 | by = pgm_read_byte(Buffer++); |
28 | |
29 | if (isdigit(by)>0){ |
30 | str_null_buffer[0] = by; |
31 | str_null_buffer[1] = '\0'; |
32 | move = atoi(str_null_buffer); |
33 | by = pgm_read_byte(Buffer++); |
34 | }
|
35 | |
36 | switch (by){ |
37 | |
38 | case 's': ptr = va_arg(ap,char *); |
39 | while(*ptr) { usart_write_char(*ptr++); } |
40 | break; |
41 | |
42 | case 'b': Base = 2; |
43 | goto ConversionLoop; |
44 | |
45 | case 'c': //Int to char |
46 | format_flag = va_arg(ap,int); |
47 | usart_write_char (format_flag++); |
48 | break; |
49 | |
50 | case 'i': Base = 10; |
51 | goto ConversionLoop; |
52 | |
53 | case 'o': Base = 8; |
54 | goto ConversionLoop; |
55 | |
56 | case 'x': Base = 16; |
57 | //****************************
|
58 | ConversionLoop:
|
59 | //****************************
|
60 | itoa(va_arg(ap,int),str_buffer,Base); |
61 | int b=0; |
62 | while (str_buffer[b++] != 0){}; |
63 | b--; |
64 | if (b<move){ |
65 | move -=b; |
66 | |
67 | for (tmp = 0;tmp<move;tmp++){ |
68 | str_null_buffer[tmp] = '0'; |
69 | }
|
70 | |
71 | //tmp ++;
|
72 | str_null_buffer[tmp] = '\0'; |
73 | strcat(str_null_buffer,str_buffer); |
74 | strcpy(str_buffer,str_null_buffer); |
75 | }
|
76 | |
77 | usart_write_str(str_buffer); |
78 | move =0; |
79 | break; |
80 | }
|
81 | |
82 | }else{ |
83 | usart_write_char( by ); |
84 | }
|
85 | }
|
86 | |
87 | va_end(ap); |
88 | }
|
Es handelt sich um einen Auszug von Ulrich Radigs uart Routine. Gerry
Du könntest Dir im Programm eine CRC über das Flash bzw. einzelne Flashbereiche berechnen und ausgeben lassen. Dann könntest Du Dich damit an das Problem herantasten: Welche Flashbereiche sind tatsächlich unterschiedlich?
Es liegt nicht am flashen selber. Da ich nach feststellung des Problems das Programm direkt mit dem STK500 geflasht habe, also ohne Ethernet Loader. Das Problem bleibt leider das gleiche. Welche Flashbereiche unterschiedlich sind weiss ich nicht. Er kommt aber beim binary nicht mit pgm_read_byte klar.
Dann zeig' doch erstmal beide Files her, damit man sie vergleichen kann.
Gerry L. schrieb: > okay, hier sind sie. Gut, sie stimmen zumindest überein. Du schreibst, dass du sie mit einem Bootloader programmierst. Kann der mit irgendwas in deiner Umgebung ein Problem haben? Beim Intel- Hex-Format kann er ja zumindest rudimentär überprüfen, ob jede Zeile korrekt übertragen worden ist (anhand einer einfachen Prüfsumme) und diese ggf. nochmal neu anfordern. Bei einer reinen Binärdatei geht das nicht.
Hallo Jörg, meine letzten Tests fanden ohne Bootloader statt. Ich habe beide Files direkt mit dem stk500 geflasht und keine Fehler erhalten. Da mein PC gerade ein Upgrade erhält habe ich die hochgeladenen Files mit dem Laptop kompiliert. Sobald ich Zeit habe werde ich alles nochmal am PC durch testen. Schönes WE Gerry
Wenn Du einen Debugger hast, kannst Du den Flash-Inhalt in beiden Fällen auslesen und vergleichen. Oder Du könntest Dir doch CRCs über die Flash-Bereiche berechnen und ausgeben. Ich hab z.B. folgenden Anwendungsfall: Beim PIC24 hab ich sog. "Config Register" (ähnlich Fuses beim AVR) im Hexfile drinn. Diese liegen in einem speziellen Flash-Bereich. Der Debugger programmiert mir alles (inkl. ConfigRegs), mein Bootloader programmiert die ConfigRegs aber explizit nicht (weil er sonst eventuell selber nicht mehr funktioniert). D.h. je nach verwendeter Programmiermethode wird dort ein Flash-Bereich beschrieben oder eben auch nicht.
Hallo, ich habe leider keinen Debugger. Was ich nicht verstehe ist wenn beide Files gleich sind und ich beide files mit dem stk500 (ohne Bootloader also direkt) flashe warum funktioniert das ihex aber das binary nicht. Fakt ist ein
1 | usart_write_char("Test"); |
kommt vollständig an aber ein
1 | usart_write_P(PSTR(format) , ## args) |
nur verstümmelt. Es fehlen die ersten chars. Ich werde mal versuchen das auf einen Atmega64 zu testen. Aber wie Jörg schon sagte sind beide Files gleich. @Jörg Wie hast du das eigentlich getestet das beide Files gleich sind? Gerry
Gerry L. schrieb: > Was ich nicht verstehe ist wenn beide Files gleich sind und ich beide > files mit dem stk500 (ohne Bootloader also direkt) flashe warum > funktioniert das ihex aber das binary nicht. Das ist auch nicht zu verstehen. Möglicherweise hast du noch andere Randbedingungen, die sich zwischen beiden unterscheiden. > Wie hast du das eigentlich getestet das beide Files gleich sind? Das Hexfile mittels avr-objcopy auch noch in ein binäres gewandelt und dann beide mit cmp -l verglichen.
Ich würde dann noch als weiteren Test in beiden Fällen den Inhalt des Flash wieder auslesen und miteinander vergleichen.
Stefan Ernst schrieb: > Ich würde dann noch als weiteren Test in beiden Fällen den Inhalt des > Flash wieder auslesen und miteinander vergleichen. Macht die Programmiersoftware normalerweise aber ohnehin von sich aus (sowohl AVRDUDE als auch die Backends von AVR Studio).
Jörg Wunsch schrieb: > Stefan Ernst schrieb: >> Ich würde dann noch als weiteren Test in beiden Fällen den Inhalt des >> Flash wieder auslesen und miteinander vergleichen. > > Macht die Programmiersoftware normalerweise aber ohnehin von sich > aus (sowohl AVRDUDE als auch die Backends von AVR Studio). Ja, aber bei so einem skurrilen Problem würde ich mich nicht darauf verlassen und es besser selber noch mal kontrollieren. Vielleicht findet ja beim Binary bereits beim Einlesen eine Verfälschung selbigen statt, das würde das automatische Verify dann nicht entdecken.
Stefan Ernst schrieb: > Ja, aber bei so einem skurrilen Problem würde ich mich nicht darauf > verlassen und es besser selber noch mal kontrollieren. Mag er tun, aber ich verwette meine nicht vorhandene Perücke, dass das nichts ergeben wird.
Jörg Wunsch schrieb: > Stefan Ernst schrieb: > >> Ja, aber bei so einem skurrilen Problem würde ich mich nicht darauf >> verlassen und es besser selber noch mal kontrollieren. > > Mag er tun, aber ich verwette meine nicht vorhandene Perücke, dass > das nichts ergeben wird. Wenn ich wetten sollte, dann würde ich auch darauf setzen, dass es nichts ergibt. Trotzdem ... Und einen Alternativ-Vorschlag, was da schief laufen könnte, hast du ja auch nicht. ;-)
Stefan Ernst schrieb: > Und einen Alternativ-Vorschlag, was da schief laufen könnte, hast du ja > auch nicht. ;-) Doch, debuggen. Aber das kann er nicht.
Also, ich habe nun einmal per avrdude das ihex file in den mc geflasht und mit dem Studio4 ausgelesen. Das selbe dan mit dem binary.... Nach dem auslesen beide verglichen und ... sie unterscheiden sich!? Was nun ?
Gerry L. schrieb: > Nach dem auslesen beide verglichen und ... sie unterscheiden sich!? Dann zeig' doch mal bitte, was du ausgelesen hast.
Beide Files im Anhang. Die Unterschiede sind ziemlich am Anfang. Wenn gewünscht kann ich auch gerne das gesamte Projekt hochladen oder vieleicht das Makefile. Es kann gut sein das ich irgendetwas falsch mache. Gerry
Wie wurde denn das binary.hex auf den µC geladen, bzw. wie entstand es ? Ist es dieselbe Quelle ? Der Unterschied besteht darin, dass Progmem-Daten, die unmittelbar vor der Webseite eingebunden werden, Auszug daraus: > Compiliert am Jun 1 2012 um 21:32:12 > System Ready > MAC 0x%2x:0x%2x:0x%2x:0x%2x:0x%2x:0x%2x > RESET - reset the AVR - Controller > REBOOT - reboot from TFTP-Server statt wie im ihex ein 0x0D 0x0A (CR/LF), im binary nur ein 0x0A (LF) enthalten, was zu Darstellungsproblemen führen kann. Der restliche Programmcode scheint gleich zu sein. Delay 62,5ms, ein Timer mit einem Sprung auf 0, ISR's vorhanden aber Interrupts deaktiviert, dafür wird das SPSR gepollt. Kein Schreibzugriff dagegen auf UDR0, so dass man eine fehlerhafte Ausgabe nachvollziehen könnte. Die Übertragungskette um das Programm auf den Controller zu bekommen, wird nicht selektiv ein CR/LF in ein LF verändern. Sicher, dass die richtigen Versionen kompiliert werden (Jun 1) ?
MWS schrieb: > Wie wurde denn das binary.hex auf den µC geladen, bzw. wie entstand es ? > Ist es dieselbe Quelle ? Es wurde per makefile aus dem .elf ein ihex und binary erstellt. Per avrdude erst das ihex geflasht mit atmel studio 4 ausgelesen dann per avrdude das binary geflasht unt mit atmel studio 4 ausgelesen. > Der Unterschied besteht darin, dass Progmem-Daten, die unmittelbar vor > der Webseite eingebunden werden, Auszug daraus: > >> Compiliert am Jun 1 2012 um 21:32:12 >> System Ready >> MAC 0x%2x:0x%2x:0x%2x:0x%2x:0x%2x:0x%2x >> RESET - reset the AVR - Controller >> REBOOT - reboot from TFTP-Server > > statt wie im ihex ein 0x0D 0x0A (CR/LF), im binary nur ein 0x0A (LF) > enthalten, was zu Darstellungsproblemen führen kann. Aber genau das ist doch das Problem es sollte keine Unterschiede geben. > Sicher, dass die > richtigen Versionen kompiliert werden (Jun 1) ? Ja.
Das Binary ggf. per FTP auf einen anderen Rechner transferiert, und dabei den ASCII-Modus benutzt?
Jörg Wunsch schrieb: > Das Binary ggf. per FTP auf einen anderen Rechner transferiert, und > dabei den ASCII-Modus benutzt? Unwahrscheinlich dass dabei lediglich im Bereich bis ungefähr Flashbyte 2000 das CR entfernt wurde, denn ab Beginn der inkludierten Webseite ist alles wieder normal. Oben angehängtes "avr.bin" enthält übrigens die 0D0A Sequenz auch im Bereich bis Byte 2000. Gerry L. schrieb: > Aber genau das ist doch das Problem es sollte keine Unterschiede geben. Wobei Du ja herausfinden möchtest wo der Fehler liegt, bzw. in welchem Teil der Kette eine Verfälschung eintritt. Kannst Du denn mal auch mit AVR-Studio flashen statt mit Avrdude, um dort Fehler auszuschließen ? Auch wäre die inkludierte Datei interessant, welche den von mir geposteten Textauszug enthält, und wie sie im Quellcode eingebunden ist. > Es wurde per makefile aus dem .elf ein ihex und binary erstellt. Mach doch obigen Versuch nochmal und poste nicht nur die runter- sondern auch die hochgeladenen Dateien (bin & hex), das sind dann 4, mach' ein Zip draus und stell's hier ein.
Sieht alles recht mysteriös aus. Habe gerade nochmal nachgesehen, avrdude selbst sollte eigentlich korrekt arbeiten:
1 | #if defined(WIN32NATIVE)
|
2 | /* Open Raw Binary format in binary mode on Windows.*/
|
3 | if(format == FMT_RBIN) |
4 | {
|
5 | if(fio.op == FIO_READ) |
6 | {
|
7 | fio.mode = "rb"; |
8 | }
|
9 | if(fio.op == FIO_WRITE) |
10 | {
|
11 | fio.mode = "wb"; |
12 | }
|
13 | }
|
14 | #endif
|
fio.mode ist, was danach ans fopen() weitergegeben wird als zweiter Parameter. Kannst du ggf. mal statt avrdude ... -U avr.bin schreiben avrdude ... -U flash:w:avr.bin:b Nicht, dass es da noch ein Problem mit der automatischen Erkennung einer binären Datei gibt. Andererseits, wie MWS schon schrieb, wäre es dann wiederum verwunder- lich, warum nur ein Teil der CR-LF-Sequenzen davon betroffen sein sollte.
Ich habe nichts per ftp transferiert. Ein binary geht nicht mit dem stk500 zu flashen soweit mir bekannt ist. Ich habe jetzt das ganze Paket als Zip angehangen. Eventuell kann ja jemand etwas erkennen. Gerry
Angehängte Dateien:
-
hex_bin.png
12 KB
Gerry L. schrieb: > Eventuell kann ja jemand etwas erkennen. Am Code selbst ist nix zu erkennen. Das PNG zeigt den Progmem Teil aus main.c zu: > usart_write("Get PONG: %i.%i.%i.%i\r\n" > usart_write("ERROR\r\n\r\n"); In der bin-Datei steht's richtig drin, nur im ausgelesenen binary.hex nicht mehr. Da das binary.hex älter als avr.bin/hex ist: sind diese alle vom unveränderten Projekt ? Es stellt sich so dar: Im Quellcode ist \r\n drin Im bin, hex und elf ist CR/LF drin AVR-Studio unterschlägt nicht gezielt CR's beim auslesen Der ATM644 wird keine CR's entfernen Wenn man davon ausgeht dass es immer das gleiche Projekt ist, bliebe nur ein fehlerhaftes Programmieren, also avrdude, wurde aber auch schon ausgeschlossen. Gerry L. schrieb: > Ich habe ursprünglich den ethersex Bootloader verwendet Jetzt wär's interessant, ob beim per Bootlader geflashten Code das gleiche CR-Verschwinden auftritt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.