01: funktioniert 0003e000 <__ctors_end>: 3e000: 27 9a sbi 0x04, 7 ; 4 0003e002 : 3e002: 1f 9a sbi 0x03, 7 ; 3 3e004: fe cf rjmp .-4 ; 0x3e002 --- 02: funktioniert (erste beiden Flanken schnell, Flanken in der Schleife langsamer) 0003e000 <__ctors_end>: 3e000: 27 9a sbi 0x04, 7 ; 4 3e002: 00 00 nop 3e004: 00 00 nop 3e006: 1f 9a sbi 0x03, 7 ; 3 3e008: 1f 9a sbi 0x03, 7 ; 3 0003e00a : 3e00a: 1f 9a sbi 0x03, 7 ; 3 3e00c: 00 00 nop 3e00e: 00 00 nop 3e010: 00 00 nop 3e012: fb cf rjmp .-10 ; 0x3e00a --- 03: funktioniert (hex-file manuell von 0x3E000 auf 0x2E000 verlegt) Code wie 02 Terminal-Modus von avrdude zeigt auch den Code bei 0x2e000 avrdude -p atmega2560 -c stk500v2 -P /dev/ttyUSB0 -t dump flash 0x2e000 32 --- 04: funktioniert (vor der Schleife ein rjmp) 0003e000 <__ctors_end>: 3e000: 27 9a sbi 0x04, 7 ; 4 3e002: 00 00 nop 3e004: 00 00 nop 3e006: 1f 9a sbi 0x03, 7 ; 3 3e008: 1f 9a sbi 0x03, 7 ; 3 3e00a: 00 c0 rjmp .+0 ; 0x3e00c 0003e00c : 3e00c: 1f 9a sbi 0x03, 7 ; 3 3e00e: 00 00 nop 3e010: 00 00 nop 3e012: 00 00 nop 3e014: fb cf rjmp .-10 ; 0x3e00c --- 05: Überraschung (rjmp durch jmp ersetzt) -> der Initialisierungspuls kommt, danach aber lange Pause von 4,13 ms Annahme: - der Code liegt nicht bei 0x3e000 (sondern bei ???) - nach dem ersten Puls wird nach 0x3e00e gesprungen - dort steht 0xffff im Speicher (ungültiger Befehl) - der Opcode-fetch macht weiter, bis bei 0x????? wieder der Code für den Initialisierungspuls kommt - 16 MHz -> 62,5 ns pro fetch - 4,13 ms / 62,5 ns = 66080 (nahe bei 64 k) - Verdacht: mein Programm liegt im Speicher bei 0x2E000 - Hexfile manuell von 0x3e000 auf 0x2e000 geändert und geflascht, verlängert die Periodendauer von 4,13 ms auf 6,193 ms - Hexfile manuell von 0x3e000 auf 0x1e000 geändert und geflascht, zeigt den schnellen toggler !!! (:020000021000EC statt :020000023000CC) 0003e000 <__ctors_end>: 3e000: 27 9a sbi 0x04, 7 ; 4 3e002: 00 00 nop 3e004: 00 00 nop 3e006: 1f 9a sbi 0x03, 7 ; 3 3e008: 1f 9a sbi 0x03, 7 ; 3 3e00a: 0d 94 07 f0 jmp 0x3e00e ; 0x3e00e 0003e00e : 3e00e: 1f 9a sbi 0x03, 7 ; 3 3e010: 00 00 nop 3e012: 00 00 nop 3e014: 00 00 nop 3e016: fb cf rjmp .-10 ; 0x3e00e --- 06: Mit diesem Wissen kann der ursprüngliche BL wieder programmiert werden und dieser kann die hfuse auslesen: avrdude -p atmega2560 -c stk500v2 -P /dev/ttyUSB0 -V -U flash:w:okboard_hz22prog_mod-to-reprog.hex Reading 64798 bytes for flash from input file okboard_hz22prog_mod-to-reprog.hex Writing 64798 bytes to flash Writing | ################################################## | 100% 6.26 s 64798 bytes of flash written Avrdude done. Thank you. printf " HFUSE = " && avrdude -q -q -p atmega2560 -c stk500v2 -P /dev/ttyUSB0 -U hfuse:r:-:h HFUSE = 0xd8 --- 07: Blink-Programm "test2" für 0x00 übersetzen und mit restauriertem BL flashen: -> tut --- 08: automatischer Textersatz im hex-file -> tut "sed -i 's/^:020000023000CC/:020000021000EC/' $pr.hex" bzw. im makefile_gen: "sed -i 's/^:020000023000CC/:020000021000EC/' $(OBJDIR)/$(TARGET).hex" --- 09: Messung Umlauf im gültigen Adressbereich 0003e000 <__ctors_end>: 3e000: 27 9a sbi 0x04, 7 ; 4 3e002: 1f 9a sbi 0x03, 7 ; 3 3e004: 1f 9a sbi 0x03, 7 ; 3 8275 µs / 0,1258 µs (2 Zyklen) = 65779 -> 128 k Takte für 256 kB Adressraum -> 1 Takt pro OP-Code an gerader Adresse -> passt zur Theorie --- 10: Verhalten bei 0x2e000 -> OK, keine Korrektur notwendig 0002e000 <__ctors_end>: 2e000: 27 9a sbi 0x04, 7 ; 4 2e002: 1f 9a sbi 0x03, 7 ; 3 2e004: 1f 9a sbi 0x03, 7 ; 3 2e006: 0d 94 05 70 jmp 0x2e00a ; 0x2e00a 0002e00a : 2e00a: 1f 9a sbi 0x03, 7 ; 3 ... 2e014: fa cf rjmp .-12 ; 0x2e00a --- 11: Verhalten bei 0x1e000 -> Verhalten niO, Adresskorrektur notwendig, da 4,129 ms zwischen 2 Impulsen liegen -> manuelle Korrektur im hexfile korrigiert den Fehler 0001e000 <__ctors_end>: 1e000: 27 9a sbi 0x04, 7 ; 4 1e002: 1f 9a sbi 0x03, 7 ; 3 1e004: 1f 9a sbi 0x03, 7 ; 3 1e006: 0c 94 05 f0 jmp 0x1e00a ; 0x1e00a 0001e00a : 1e00a: 1f 9a sbi 0x03, 7 ; 3 ... 1e014: fa cf rjmp .-12 ; 0x1e00a ---