Programmierfehler bei 0x3E000 im ATmega2560, wenn mySmartUSBlight per ISP verwendet

Hallo zusammen, ich hatte ein Problem im Bootloader-Bereich des ATmega2560 beim Programmieren über die ISP-Schnittstelle mit dem Programmieradapter mySmartUSBlight. Ich konnte eine Umgehungslösung ausarbeiten und möchte die Lösung hier im Forum "zur Info" teilen. Ein Firmware-Update des Adapters (V1.19_b1947 vom 14.1.2020) brachte keine Abhilfe. Am Ende meiner Untersuchung steht die Erkenntnis, dass der Programmieradapter die Adressbereiche 0x10000 und 0x30000 über Kreuz vertauscht. Das Ganze so konsequent, dass beim zurücklesen des Speichers der Rücktausch erfolgt und man den Eindruck bekommt, die Programmierung sei iO. Wer nur Programme in den ersten 64 kB behandelt, dürfte den Fehler nicht bemerken.

Der Programmierfehler lässt sich kompensieren, in dem man im "Extended Segment Address Record" des erzeugten hex-files vor dem Programmieren die oben genannten Adressbereiche tauscht (sofern Programmcode für mindestens einen der Bereiche generiert wurde). Im makefile kann die Korrektur so aussehen:

1

   program: $(OBJDIR)/$(TARGET).hex

2

      @# mitigate wrong access from mySmartUSBlight to bootloader flash sector in mega2560:

3

      sed -i 's/^:020000021000EC/:TEMP/' $(OBJDIR)/$(TARGET).hex

4

      sed -i 's/^:020000023000CC/:020000021000EC/' $(OBJDIR)/$(TARGET).hex

5

      sed -i 's/^:TEMP/:020000023000CC/' $(OBJDIR)/$(TARGET).hex

6

      $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH)

Wer den Nachweis des Fehlers verstehen möchte, kann hier tiefer einsteigen: Mein Programm an der Adresse 0x3E000 des mega2560 wollte nicht funktionieren. Ich reduzierte die Funktion schrittweise bis auf einen Port-Toggler und einen Sprung. Es schien anfangs unlogisch, weil ein relativer Sprung funktionierte, aber ein absoluter Sprung nicht im Adressbereich 0x3E000, aber sehr wohl im Adressbereich 0x00000. Stattdessen startete das Programm nach etwa 4ms scheinbar neu. Das untermauerte die Theorie, dass das Programm an anderer Stelle im Speicher liegt, von dort an eine Adresse im Bereich 0x3E000 springt, dort keinen ausführbaren Programmcode vorfindet und weiter rennt, bis wieder das geflashte Programm erreicht ist. Die gemessenen Zeiten passen zur Quartfrequenz von 16 MHz.

Anbei noch meine Test-Dateien. Der Ziel-Adressbereich kann in "test9" mit dem Befehl "-Ttext=0x3E000" eingestellt werden. Der Aufruf dieser Datei erzeugt ein hex-file und flasht dieses. Test9.s enthält den Assembler-Code. Ich arbeite mit Linux und hoffe, diese Info hilft.