ihex vs binary unterschiedlicher Code

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

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.

okay, hier sind sie.

Gerry

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

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 ?

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.

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.

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

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.