ich versuche den MEGA-1284P Xplained über USB mit avrdudue anzusprechen.
Nach Infos in https://ww1.microchip.com/downloads/en/Appnotes/doc8374.pdf
und im Internet sollte das mit der Option -c avr911 -b 57600 gehen.
"The communication port settings (baud rate, parity control etc.) must be set manually before using AVROSP. The needed settings are 57600bps, no parity control and eight data bits."
Das klappt aber nicht. Auch nicht wenn ich Reset und SW0 drücke und SW0 später loslasse um den Bootloader zu aktivieren.
1
~$ lsusb
2
Bus 001 Device 005: ID 03eb:2122 Atmel Corp. XMEGA-A1 Explained evaluation kit
3
4
~$ ls -lah /dev/ttyACM0
5
crw-rw----+ 1 root dialout 166, 0 Dec 10 16:22 /dev/ttyACM0
dafür benötigst du einen Bootloader. Kapitel 5.
Wenn der Controller zwischendurch mittels ISP geflashst wurde ist der Bootloader dabei immer weg und muss neu geflasht werden. Hast du einen Programmer zur Hand?
Welches zip ist denn mit
"5.2 Restoring the bootloader
When the bootloader has been erased it can be restored with any of the previously mentioned programming tools.
The hex file for the bootloader is a part of the application note zip (in the folder named hex) file and is called mega_1284p_xplained_bootloader_and_example.hex" gemeint.
To perform a command, enter command number or command string
25
26
MEGA-1284P Xplained>2
27
28
MEGA-1284P Xplained>3
29
NTC ADC value: 450
Kann ich auch mit minicom und dem bootloader ein hex in den flash schreiben oder braucht es dazu ein Programm wie avrdude? Bisher habe ich ATmegas nur ohne bootloader mit avrdude per ISP programmiert.
probiere einmal ob du einen Kontakt bekommst.
Die Baudrate vom Bootloader ist bekannt? Gff. ändern.
Das wäre unter Windows:
avrdude -c wiring -P COM3 -b 115200 -p m1284p -v
Vielleicht solltest du deinen eigenen Bootloader lieber benutzen. Dieses uralte AVR109/AVR911 Protokoll ist nicht sonderlich toll und offenbar oft noch schlechter implementiert.
1
/* Tell the programmer which part we selected.
2
According to the AVR109 code, this is ignored by the bootloader. As
3
some early versions might not properly ignore it, rather pick up the
4
first device type as reported above than anything out of avrdude.conf,
5
so to avoid a potential conflict. There appears to be no general
6
agreement on AVR910 device IDs beyond the ones from the original
7
appnote 910. */
8
9
buf[0]='T';
10
buf[1]=devtype_1st;
11
12
butterfly_send(pgm,buf,2);
13
if(butterfly_vfy_cmd_sent(pgm,"select device")<0)
14
return-1;
Problem in deinem Falle ist aber, dass der Bootloader ja behauptet, kein einziges device zu unterstützen.
Das ganze Konzept von "device codes" (als einzelne Bytes) in diesem Protokoll ist grottig.
Wenn du irgendwie kannst, such dir irgendeinen Bootloader, der STK500v2-Protokoll spricht, und benutze diesen. Alternativ kannst du dir natürlich auch die Quellen von dem alten Butterfly/AVR911-Bootloader schnappen und schauen, dass er zumindest einen brauchbaren device code produziert. Oder aber du hackst AVRDUDE, dass es gar keinen device code erst aussuchen will – ist ja bei einem Bootloader ohnehin egal, der hat nur genau ein device. (Das Protokoll AVR109 war ursprünglich für einen standalone programmer konzipiert worden.)
Programmer supports buffered memory access with buffersize=256 bytes.
3
avrdude: Send: t [74]
4
5
Programmer supports the following devices:
6
avrdude: Recv: . [00]
7
8
avrdude: Send: T [54] . [00]
9
avrdude: Recv: . [00]
10
avrdude: error: programmer did not respond to command: select device
11
avrdude: initialization failed, rc=-1
12
Double check connections and try again, or use -F to override
13
this check.
14
15
avrdude: Send: L [4c]
16
avrdude: Recv: . [0d]
17
avrdude: Send: E [45]
18
avrdude: Recv: . [0d]
19
20
avrdude done. Thank you.
Das ist wahrscheinlich keine neue Info für Dich. Ich schreibe das nur der Vollständigkeit halber.
P.S. Mich wundert schon etwas, dass ich so wenig im Internet zu dem Problem finde. Das MEGA1284P XPLAINED gibt es ja schon lange und ich kann doch nicht der erste sein, der das mit avrdude und bootloader nutzen möchte.
Naja, das, was ich damals dazu geschrieben habe, haben wir ja dann implementiert. Hilft nur in deinem Falle nicht, weil dein Bootloader ja gleich mal keinen einzigen Code als "supported" zurück gibt.
Ja, das Board gibt es schon lange, aber vermutlich benutzen nur wenige den Bootloader überhaupt. Die Nachfolger des alten XPLAINED hatten dann später auch einen Onboard-Programmer drauf (EDBG oder mEDBG), das mit dem 1284 war eins der ersten, da gab es sowas noch nicht.
Alexander. Nimm mal einen Bootloader von MCUDude. Damit wird alles geflasht was Arduino like mit USB programmiert wird. avrdude Option war dann entweder wiring oder carduino.
Hat auch gleich den Vorteil dass du, wenn damit was nicht funktioniert, bei Hans direkt nachfragen kannst. Er ist einer der drei derzeit sehr aktiven Entwickler im AVRDUDE-Projekt. ;-)
Ich habe das nochmal nachgestellt. Folgende Zeile müsstest du ggf. Linux spezifisch anpassen. Das sollte funktionieren. Also erst Bootloader von MCUdude flashen und dann per USB mit Baudrate vom geflashten Bootloader und avrdude usw.
1
avrdude-v-patmega1284p-curclock-PCOM4-b115200-D
Mir fällt da nochwas ein. Hast du die Resetleitung angepasst? Weil das Resetsignal kommt vom DTR. Sonst kann avrdude den Controller nicht in den Bootloader-Mode versetzen. Siehe ganz unten https://github.com/MCUdude/MightyCore
Also erst Bootloader von
MCUdude flashen und dann per USB mit Baudrate vom geflashten Bootloader
und avrdude usw.
Hallo Veit,
Moment, nicht ganz so schnell.
Wie geschrieben, programmiere ich normalerweise per ISP. Da es für das MEGA1284P XPLAINED einen Bootloader und ein Beispielprogramm von Atmel gibt, wollte ich das einfach mal ausprobieren. Der Empfehlung einen anderen Bootloader auszuprobieren folge ich gerne. Wenn ich aber auf https://github.com/MCUdude/MightyCore lese
"An Arduino core for ATmega8535, ATmega16, ATmega32, ATmega164, ATmega324, ATmega644 and ATmega1284, all running the Urboot bootloader. ..." dann frage ich mich, ob ich nicht nur den Urboot bootloader brauche. Warum soll ich mir das ganze MightyCore Framework installieren?
"... Boards Manager Installation
This installation method requires Arduino IDE version 1.8.0 or greater."
Brauche ich die wirklich nur um einen bootloader zu installieren?
Mir fällt da nochwas ein. Hast du die Resetleitung angepasst? Weil das
Resetsignal kommt vom DTR. Sonst kann avrdude den Controller nicht in
den Bootloader-Mode versetzen. Siehe ganz unten
https://github.com/MCUdude/MightyCore
Ich werde erst einnmal schauen welche optionalen Bootloader es für das MEGA1284P XPLAINED gibt. Ein einzelnes .hex oder der source code dafür und ein bootloader der ohne HW-Modifikationen funktioniert wäre mir lieber.
P.S. Ich werde wahrscheinlich erst am Wochenende dazukommen.
File "/home/alesi/AVR/avr-aosp/avr-aosp.py", line 329, in <module>
18
main()
19
File "/home/a.../AVR/avr-aosp/avr-aosp.py", line 307, in main
20
GetParams( fd )
21
File "/home/a.../AVR/avr-aosp/avr-aosp.py", line 98, in GetParams
22
print (" N =", fd.read(1).decode(), "\t#high fuse bits")
23
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x97 in position 0: invalid start byte
Bei den <> im usage string für start und stop bin ich mir nicht sicher, ob die eingegeben werden sollen. Mit <> kommt aber der gleiche Fehler. Benutzt jemand hier avr-aosp.py ?
Ich kenne das XPLAINED Board nicht. Müßte man den Schaltplan anschauen. Die Frage lautet wie Atmel sich damals gedacht hat den Controller zu reseten damit der Bootloader Mode aktiv wird um überhaupt die Chance zu haben Serial sein Programm zu flashen.
Wenn der Bootloader drauf ist und man möchte per USB ein Programm aufspielen, was am Ende immer auf Serial hinausläuft, dann muss ja irgendwas den Controller reseten können. Der Bootloader ist nach Reset immer nur kurz aktiv, danach startet er sein Programm was drauf ist. Vielleicht verstehst du jetzt den Ablauf besser. Also nur Rx/Tx Leitung am Controller kann dafür nicht ausreichend sein.
löse dich mal von dem Gedanken "Arduino". Nur weil die Bootloader Dateien zu einem Arduino Core Package Projekt gehören kann man die ganz normal ohne Arduino verwenden. Ich dachte nun wirklich das wäre deutlich gewesen.
Bonus: auch wenn Stefan in Großbritannien lebt, er spricht deutsch, falls du Fragen an ihn hast. ;-) Stefan hat von mir die Federführung für AVRDUDE übernommen. Es lohnt sich also durchaus, auch mal eine aktuelle Version davon zu benutzen.
Ich kenne das XPLAINED Board nicht. Müßte man den Schaltplan anschauen.
Die Frage lautet wie Atmel sich damals gedacht hat den Controller zu
reseten damit der Bootloader Mode aktiv wird um überhaupt die Chance zu
haben Serial sein Programm zu flashen.
Es sind drei Taster auf dem Board. Mit SW0 nach Reset loslassen kommt man in den bootloader Modus.
Du sollst nur
einen Bootloader von MCUdude für deinen ATmega1284p verwenden.
Hier ist der korrekte Link dorthin.
Beitrag "Re: MEGA1284P XPLAINED über USB mit avrdudue programmieren"
Weder im AVR370: MEGA-1284P Xplained Getting Started Guide noch im AVR364: MEGA-1284P Xplained Hardware User's Guide finde ich Infos zur Clock des MEGA1284P XPLAINED. avrdude sagt
1
avrdude: safemode: lfuse reads as F7
2
avrdude: safemode: hfuse reads as 9A
3
avrdude: safemode: efuse reads as FF
4
avrdude: safemode: Fuses OK (E:FF, H:9A, L:F7)
und https://www.engbedded.com/fusecalc/ sagt damit "CKDIV8 nicht programmiert".
Das Datenblatt sagt "9.2.1 Default Clock Source The device is shipped with internal RC oscillator at 8.0MHz". Demnach sollte er mit 8 MHz laufen, wenn er keinen externen Quarz hat. Mit 3.3 V kann er bis zu 10MHz.
habe den Board Schaltplan gefunden. Als USB-Serial Wandler sitzt hier eine AT32UC3B1256 drauf. Von dem geht eine Leitung zum ATmega1284P Reset Pin. Der sollte das Arduino like automatisch machen. An dem AT32UC3B1256 fummelst du ja nicht rum und solltest auch nicht daran rum fummeln. Ich sehe das immer noch so das der ATmega1284P den Bootloader benötigt und dann sollte das funktionieren.
Was noch sein kann ist das die Fuse vom ATmega1284P vorher eingestellt werden müssen. Sonst ist der Bootloader wieder weg nach eigentlichen Programm flashen, weil der Speicherbereich nicht reserviert/geschützt wurde. Im Zweifelsfall konfigurierst du die größte Bootloadergröße. Damit verschenkst du nur paar Bytes Flashspeicher, mehr Nachteil hat man dadurch nicht.
Als USB-Serial Wandler sitzt hier eine AT32UC3B1256 drauf.
Dann sollte der doch aber auch direkt den ATmega1284 programmieren können, ohne irgendwelche Bootloader da drauf. Diese UC3 wurden später als EDBG (Embedded Debugger) auf die diversen Xplained* gebaut – ich dachte nur zuerst, dieser Ur-Prototyp eines Xplained hätte den noch nicht gehabt.
Als was für ein Gerät meldet der sich denn am USB?
Die LED an SW0 bzw. an PB0 vom ATmega1284P leuchtet und flackert zwischendurch.
Den bootloader ohne etwas zu programmieren über USB mit avrdude anzusprechen, funktioniert noch nicht. Weder kurz nach Reset noch kurz nach SW0 nach Reset loslassen:
OK, dann hat er zumindest leider noch keine EDBG-Firmware drauf. Die würde sich mit "CMSIS-DAP" im Produktnamen melden.
Aber von dem Teil gehen Leitungen zum SPI des ATmega1284 (und zum I²C und zur UART). Es wäre doch wirklich mehr als seltsam, wenn sie da nicht irgendein Programmier-Interface drin hätten.
ich kenne jetzt nicht den Grundgedanken des AT32UC3B1256 auf dem Xplained Board, wenn das üblicherweise mittels ISP programmiert wird. Aber allein die Verschaltung sieht aus so wie ich das von Arduino kenne. USB-Serial Wandler per Tx/Rx und Reset am eigentlichen Controller gekoppelt. Deswegen benötigt der zu programmierende Controller einen Bootloader, sonst weiß der nicht das die Daten über Serial reinkommen zum flashen.
Oder anders gesagt, der AT32UC3B1256 ist nur der Ersatz für einen FTDI oder CH340. Genauso wie ein ATmega16U2 auf den original Arduinos der Ersatz dafür ist. Wenn das nicht so wäre würde alles keinen Sinn ergeben. Sehe ich jedenfalls aktuell so.
Im Vergleich zur Arduino Schaltung fehlt der R und C in/an der Resetleitung, aber das muss nichts bedeuten. Das kann und wird Atmel im AT32UC3B1256 ganz sicher nur anders in Software gelöst haben um ein kurzes Resetsignal auszugeben.
Per USB am Rechner muss sich der AT32UC3B1256 melden, wenn der passende Treiber installiert ist. Oder gibt einen Standardtreiber dafür? Die genaue Auskunft muss Alexander geben. Ich habe das Board nicht.
Nicht das wir uns falsch verstehen. Ich transferiere mein Wissen wie Arduino-Boards und eigens gebaute Boards funktionieren. Laut meiner Logik bleiben da auch (fast) keine anderen Möglichkeiten. Irgendwas muss den ATmega1284P reseten und damit in den Bootloadermode versetzen. Das kann nur der AT32UC3B1256 machen, zudem die Verbindung vorhanden ist.
EDBG kenne ich vom Arduino Nano Every, da sitzt ein SAMD11 drauf der als EDBG bezeichnet wird. Oder auf den Microchip Curiosity Boards (Atmega4809, AVR128DB48) sitzt ein SAMDxx drauf. Die Grundfunktion (und mehr) ist ein USB-Serial Wandler zu sein. Das sind alles Boards mit Controller die eigentlich per UPDI programmiert werden. Hier haben die eigentlichen Controller keinen Bootloader drauf.
Nun ist die Frage ist der AT32UC3B1256 auf dem Xplained ein "EDBG" oder stellt er nur einen USB-Serial Wandler dar. Bin der Meinung Letzteres. War EDBG zu ATmega1284P Zeiten schon üblich? Im Schaltplan fehlt mir die Bezeichnung EDBG.
Ich lasse mich jedoch gern eines Besseren Belehren. :-)
am avrdude soll es nun nicht scheitern. Ob dir eine aktuelle Version wirklich hilft wird sich zeigen. Jedenfalls ist die aktuellste Version hier zu finden.
https://github.com/mcuee/avrdude/releases/tag/v7.2
bin mir fast sicher das Problem gefunden zu haben. Korrigiert mich wenn ich falsch liege.
Im Schaltplan geht Tx/Rx vom AT32UC3B1256 an UART1 am ATmega1284P. Alex hat den Bootloader verwendet mit folgenden Namen:
optiboot_flash_atmega1284p_UART0_57600_11059200L_B0_BIGBOOT.hex
Also für UART0.
Wenn Alex den für UART1 flasht könnte es klappen.
nachdem ich auf https://github.com/stefanrueger/urboot
"Avrdude (from v7.1 onwards) supports urboot bootloaders with -c urclock"
gelesen habe, habe ich auf einen anderen Rechner mit Debian stable gewechselt. Debian stable hat avrdude: Version 7.1.
Leider funktioniert es mit avrdude: Version 7.1 und -c urclock immer noch nicht:
in den avrdude Option muss man keine bootsize angeben. Das sollte man vorher per Fuse einstellen. Ich habe jedenfalls bis jetzt alles wenn notwendig per Fuse gemacht. Danach nochmal Bootloader flashen.
6.5 Board controller
The Atmel AT32UC3B1256 board controller and the Atmel ATmega1284P are
connected through TWI, SPI, and USART interfaces. All interfaces can be used to communicate between the devices, but only the USART is implemented by default on the board controller. ...
du meinst der AT32UC3B1256 könnte der komplette Programmer Ersatz sein. Ich habe keine Ahnung ob das klappt. Ist aber denkbar wenn du das so schreibst.
Gibt es es jemanden im Forum der das Board oder ähnliches hat und mehr dazu sagen könnte?
du meinst der AT32UC3B1256 könnte der komplette Programmer Ersatz sein.
Ich habe keine Ahnung ob das klappt.
Die späteren Xplained* Boards hatten auch einen UC3, der war aber mit einer EDBG-Firmware. Ich vermute, dass man die leider nicht separat bekommen können wird (um den UC3 selbst damit zu flashen). Diese EDBGs wurden dann auch separat von Atmel/Microchip vermarktet und waren eigentlich die letzte Domäne der UC3 (und damit der AVR32). Mittlerweile sind sie aber auch von SAMD21 abgelöst worden, die auf den neueren Boards als EDBG fungieren.
Die Funktion dieser Chips ist zu großen Teilen von den AtmelICE übernommen worden.
Naja, dieses 1284-Board war wohl vor 15+ Jahren wirklich der erste Versuch in Richtung dieser neueren Devboards.
Die späteren Xplained* Boards hatten auch einen UC3, der war aber mit
einer EDBG-Firmware. Ich vermute, dass man die leider nicht separat
bekommen können wird (um den UC3 selbst damit zu flashen).
...
6.1 Preprogrammed firmware
...
The Atmel AT32UC3B1256 board controller is also pre-programmed with a
bootloader and an USART-to-USB gateway application which can be used to
communicate with the target controller ATmega1284P.
Zu mindestens an die Firmware des AT32UC3B1256 auf dem MEGA1284P XPLAINED müsste man rankommen, oder?
Zu mindestens an die Firmware des AT32UC3B1256 auf dem MEGA1284P
XPLAINED müsste man rankommen, oder?
Naja, über dessen Bootloader kannst du sie aktualisieren. Aber ob es eine neuere dafür gibt, die auch ISP beinhaltet, wage ich zu bezweifeln. Man wird das Teil dann nie wieder angefasst haben.
So toll eingeschlagen, wie man sich das erhofft hatte, ist der ATmega1284P wohl sowieso nicht seinerzeit, und irgendwann ist er dann von den Xmegas überholt worden.
noch ein Nachtrag zu EDBG µC. Falls sich wer sowas selbst bauen möchte. Einfacher wäre sich ein kleines Microchip Curiosity Board zu nehmen und den Programmer-Teil "abzubrechen".
Also, zumindestens für einen SAMD11 passend liegt hier das Programm dafür. Für UPDI Programmierung und USB-Serial Wandler in einem. Ist vom Nano Every Board.
https://github.com/arduino/ArduinoCore-megaavr/tree/master/firmwares/MuxTO
ich habe jetzt zwar den optiboot bootloader erfolgreich auf dem MEGA1284P XPLAINED installiert und kann dann über USB scheinbar erfolgreich das Demoprogramm zum MEGA1284P XPLAINED aufspielen:
delaying chip erase until first -U upload to flash
6
avrdude: reading input file mega_1284p_xplained_example.hex for flash
7
with 9022 bytes in 1 section within [0, 0x233d]
8
using 36 pages and 194 pad bytes
9
avrdude: preparing flash input for device bootloader
10
avrdude: writing 9022 bytes flash ...
11
12
Writing | ################################################## | 100% 101.60 s
13
14
avrdude: 9022 bytes of flash written
15
avrdude: verifying flash memory against mega_1284p_xplained_example.hex
16
17
Reading | ################################################## | 100% 101.60 s
18
19
avrdude: 9022 bytes of flash verified
20
21
avrdude done. Thank you.
Aber das Programm, d.h. der "Terminal Mode" mit minicom, funktioniert nicht. Es funktioniert scheinbar nur wenn ich es mit Atmel ICE per ISP programmiere.
Ich habe jeweils das Board nach dem programmieren neu in die USB-Buchse eingesteckt, minicom mit "$ minicom -D /dev/ttyACM0 -b 57600" aufgerufen und SW1 nach Reset losgelassen um in den "Terminal Mode" zu gehen.
Da du ein Atmel-ICE besitzt: schmeiß doch mal den Debugger an und schau nach, wo es herum hängt. Möglicherweise bleibt der Bootloader ja aktiv und startet das Programm nicht?
(Musst bei der Debug-Sitzung nur schauen, dass die nicht selbst alles nochmal flasht.)
Du kannst den Debugger auch ohne -g benutzen, dann wurschtelst du dich halt durch den Binärcode im Target durch. Du solltest aber zumindest erkennen können, ob er noch im Bootloader hängt (hohe Adressen) oder schon die eigentliche Applikation gestartet hat.
Da im zip nur ein .hex ist, muss ich für den Debugger ja sowieso ein .elf erzeugen. Dann kann ich auch gleich mit -g compilieren. Habe ich zu mindestens gedacht. Aber leider sind im zip nicht alle Quelltexte enthalten um mega_1284p_xplained_example.c zu kompilieren. Die Atmel QTouch Lib fehlt.
AVR/m1284p-xpld-src/init.c:266: undefined reference to `qt_config_data'
4
AVR/m1284p-xpld-src/init.c:266: undefined reference to `qt_config_data'
5
init.o: In function `touch_init':
6
AVR/m1284p-xpld-src/init.c:284: undefined reference to `SNS_array'
7
AVR/m1284p-xpld-src/init.c:284: undefined reference to `SNS_array'
8
AVR/m1284p-xpld-src/init.c:284: undefined reference to `SNSK_array'
9
AVR/m1284p-xpld-src/init.c:284: undefined reference to `SNSK_array'
10
AVR/m1284p-xpld-src/init.c:284: undefined reference to `qt_enable_key'
11
AVR/m1284p-xpld-src/init.c:284: undefined reference to `calc_masks'
12
AVR/m1284p-xpld-src/init.c:284: undefined reference to `calc_masks'
13
AVR/m1284p-xpld-src/init.c:284: undefined reference to `burst_1_2_00_0'
14
AVR/m1284p-xpld-src/init.c:284: undefined reference to `burst_1_2_00_0'
15
AVR/m1284p-xpld-src/init.c:284: undefined reference to `qt_init_sensing_with_burst'
16
AVR/m1284p-xpld-src/init.c:284: undefined reference to `qt_filter_callback'
17
AVR/m1284p-xpld-src/init.c:284: undefined reference to `qt_filter_callback'
18
mega_1284p_xplained_example.o: In function `standby_cmd':
19
AVR/m1284p-xpld-src/mega_1284p_xplained_example.c:546: undefined reference to `qt_measure_sensors'
20
mega_1284p_xplained_example.o: In function `power_down_cmd':
21
AVR/m1284p-xpld-src/mega_1284p_xplained_example.c:535: undefined reference to `qt_measure_data'
22
collect2: error: ld returned 1 exit status
Die Lib finde ich nur als .vsix und die will ich eigentlich auch nicht installieren. Alle Aufrufe der QTouch Lib auszukommentieren ist mir ehrlich gesagt momentan auch zu aufwändig.
P.S. Ohne das Atmel Studio komme ich selbst mit dem .vsix ja nicht an die C-Quelltexte, oder?
Alle Aufrufe der QTouch Lib auszukommentieren ist mir
ehrlich gesagt momentan auch zu aufwändig.
Ich habe jetzt doch damit begonnen. Scheinbar habe ich eine Timer-Routine zu viel auskommentiert. Im Menuepunkt 5 verhält sich das Terminalprogramm abweichend. Der Rest, bis auf QTouch, scheint aber, nach Programmieren mit dem Atmel ICE, zu funktionieren.
Da im zip nur ein .hex ist, muss ich für den Debugger ja sowieso ein
.elf erzeugen.
Musst du nicht. Prinzipiell sollte man einen Debugger auch ganz ohne Objektdatei starten können, er hat ja schließlich den Flash des Targets, den er auslesen kann. Klar, du hast dann keinerlei Symbole, nur Adressen und einen Disassembler.
QTouch gibt es nicht als Sourcecode, solltest du aber trotzdem auch dazu linken können. Dann hast du eben für den Touch-Teil keine Debug-Informationen.
Direkt nach dem Programmieren über USB mit optiboot haben die LEDs auf dem Mega-1284p-xpld nach Loslassen von Taster SW1 nach Reset geblinkt. D.h. sich so verhalten, wie nach dem Programmieren mit dem Atmel ICE. Nach Reset blinken sie nicht mehr. Ist das Programm nach Reset jetzt schon wieder weg?
Klar, irgendwas in der Richtung geht nicht, denn das will auf
Sourcecode-Ebene arbeiten. stepi (kurz: si) geht aber. Dann noch ein
disp/i $pc
und du kannst mit deinen si-Kommandos zumindest verfolgen, wo er lang
wandert.
Irgendwann ein "c" (continue), dann kannst du später mit ^C anhalten und
schauen, wo er jetzt ist.
Ich habe den optiboot bootloader jetzt wieder mit dem Atmel ICE mit dem Demoprogramm überschrieben und avarice und gdb-avr gestartet. D.h. alles ohne optiboot.
Aber die Frage war ja warum oder wo das Programm mit optiboot hängt.
Deshalb müsstest du sowohl optiboot als auch das eigentliche Program drin haben und dann alles im Debugger starten.
Wenn du für optiboot und das Demo nur getrennte Lade-Dateien hast zum Flashen, dann musst du sicherstellen, dass du beim zweiten Flashen nicht alles vorher löschst.
Wenn du für optiboot und das Demo nur getrennte Lade-Dateien hast zum
Flashen, dann musst du sicherstellen, dass du beim zweiten Flashen nicht
alles vorher löschst.
Ich habe jetzt wieder den optiboot bootloader mit dem Atmel ICE in das Mega1284p-xpld geschrieben. Beim Programmieren des Demoprogramms über USB und per optiboot habe ich zusätzlich die avrdude Option -D (Disable auto erase for flash memory) angegeben. Da hatte ich mich vorher schon gefragt, ob die erforderlich ist.:
Nur die Ausführung des mit optiboot programmierten Demoprogramms im Terminal Modus (SW 1 nach Reset loslassen) und Auswahl der Menuefunktionen über minicom funktioniert immer noch nicht.
Wenn ich das Mega1284p-xpld aus- und wieder einstecke, blinken auch die LEDs nicht mehr nach Loslassen von SW1. Aber das Programm ist doch auch mit bootloader im Flash und sollte ohne Strom erhalten bleiben.
hast du jemals die Fuses richtig konfiguriert? Die bootsize Option ist dafür kein Ersatz, falls du das annehmen solltest. Lies einmal die Fuse aus und schau nach ob die BOOT Bits im High Byte korrekt gesetzt sind. Oder prüf gleich alle nochmal. Weil ein Flash Erase vor Neuprogrammierung ist eigentlich normal um keine Bit Leichen zu haben.
Hiermit sollten die Fuses klar angezeigt werden. Das fehlt mir irgendwie in deinen Ausgabetexten von avrdude.
a) Fuse korrekt einstellen
b) Bootloader flashen
c) Programmierung mittels USB
d) irgendwann wieder Programmer angeklemmt, ist b) und c) futsch
Der Bootloader hat laut meines Wissens ca. 1s Wartezeit nach Reset bevor er das eigentliche Programm startet. Ich hatte gedacht/gehofft der AT32UC3B1256 bekommt den Reset zur richtigen Zeit automatisch gebacken.
hast du jemals die Fuses richtig konfiguriert? Die bootsize Option ist
dafür kein Ersatz, falls du das annehmen solltest. Lies einmal die Fuse
aus und schau nach ob die BOOT Bits im High Byte korrekt gesetzt sind.
Oder prüf gleich alle nochmal. Weil ein Flash Erase vor
Neuprogrammierung ist eigentlich normal um keine Bit Leichen zu haben.
Hiermit sollten die Fuses klar angezeigt werden. Das fehlt mir irgendwie
in deinen Ausgabetexten von avrdude.
Hallo Veit,
ich habe das Mega1284p-xpld gebraucht gekauft und nichts an den Fuses geändert. D.h. avrdude nur mit der Option -n oder -U flash:w:file.hex aufgerufen. In meinen ersten Beiträgen hat avrdude die Fuses am Ende ausgegeben. Hier nochmal die Ausgabe aus Beitrag Beitrag "Re: MEGA1284P XPLAINED über USB mit avrdudue programmieren" vom 10.12.2023 17:57
Wenn ich das gleiche hex (das mit dem alten bootloader und Demo Programm zum Mega1284p-xpld von Atmel) jetzt nochmal mit den gleichen Parametern schreibe ist die Dateigröße anders, 9798 bytes ggü. 128192 bytes of flash und die Zeile "safemode: Fuses OK (E:FF, H:9A, L:F7)" fehlt. Wichtig dabei ist, dass ich zu Beginn avrdude: Version 6.3-20171130 verwendet habe und ab Beitrag "Re: MEGA1284P XPLAINED über USB mit avrdudue programmieren" , 12.12.2023 21:29, avrdude: Version 7.1. Hat sich da etwas an der Ausgabe der Fuse-Info geändert? In der man-page steht
1
-s, -u These options used to control the obsolete "safemode" feature which is no longer present. They are silently ignored for backwards compatibility.
Wird die savemode Zeile ab avrdude 7.1 nicht mehr ausgegeben?
Wird die savemode Zeile ab avrdude 7.1 nicht mehr ausgegeben?
Ja, safemode haben wir entfernt. Das hatte seine beste Zeit schon 20 Jahre hinter sich gelassen. :-)
Der Hintergrund von safemode ist, dass in der Anfangszeit AVRs sehr häufig mittels direktem Bit-Bang von einer parallelen Schnittstellen (wer sie noch kennt ;-) vom PC aus programmiert worden sind. Adapter mit eigenen Controllern, wie wir sie heute benutzen, waren damals teuer und eher selten.
Wenn in so einem Aufbau jetzt die Verdrahtung etwas wackelig war, dann konnten sich schnell mal Bitfehler in der Programmierung einschleichen. Da ein Bitfehler in der Programmierung der Fuses unangenehme Konsequenzen haben kann (wenn man sich versehentlich die Taktquelle für die MCU abklemmt), wurde das safemode-Feature eingeführt, welches die Fuses zu Anfang und Ende inklusive gewollter Änderungen vergleicht.
Mit heutigen Programmieradaptern braucht man sowas nicht mehr, das Risiko von Fehlprogrammierung ist viel geringer als damals. Außerdem haben nunmehr bei weitem nicht mehr alle AVRs ein Fuse-Schema wie "low, high, extended".
Natürlich gäbe es trotzdem Wege, die Fuses explizit zu lesen und anzeigen zu lassen, am einfachsten im Terminalmodus mit "r lf", "r hf", "r ef".
Deine Fuses stehen auf full-swing crystal oscillator ohne Vorteiler, maximale (also sehr konservative) Startverzögerung, kein Debugging aktiv (wundert mich, da du ja den Debugger verwendet hast), Bootsize 2048 Worte (also ab 0x1F000 Byte-Adresse), Reset springt zum Bootloader.
Wenn ich das gleiche hex (das mit dem alten bootloader und Demo Programm
zum Mega1284p-xpld von Atmel) jetzt nochmal mit den gleichen Parametern
schreibe ist die Dateigröße anders, 9798 bytes ggü. 128192 bytes of
flash
1
$ ls -l mega_1284p_xplained_*.hex
2
-rw-r--r-- 1 a... a... 27656 Mar 28 2011 mega_1284p_xplained_bootloader_and_example.hex
3
-rw-r--r-- 1 a... a... 25402 Mar 29 2011 mega_1284p_xplained_example.hex
ich arbeite zur Zeit an einem Firmeninternen 1284P Labor Projekt mit "Mighty Core" Unterstützung, wo ein fest eingelöteter TQFP 1284P sitzt. Anhand meiner Dokumentation ging ich wie folgend vor:
1
Bootloader Installation:
2
------------------------------
3
1) Connect ATMEL AVR-ISP via 6-pin standard pinout cable to
4
JP5 with red stripe of cable
5
matching the PIN-1 marking at the JP5 header
6
2) Install and run ATMEL STUDIO V7.0
7
3) Select Tools->Device Programmimg
8
4) Select AVRISP mkII
9
5) Set Device: ATmega1284P
10
6) Press Interface Apply button
11
7) Read Device Signature - should display "0x1E9705"
12
8) Click on FUSES Tab
13
9) Set Extended to "0xFF", High: "0xDC", Low: "0xD7
Naja, die Ausgabe ist nicht korrekt. Es wird da nicht wirklich dokumentiert, wie viele Bytes beschrieben worden sind, sondern die Differenz zwischen der letzten und der ersten Adresse ausgerechnet. Da der Bootloader weit oben ist, bekommst du eine sehr große Zahl.
Naja, die Ausgabe ist nicht korrekt. Es wird da nicht wirklich
dokumentiert, wie viele Bytes beschrieben worden sind, sondern die
Differenz zwischen der letzten und der ersten Adresse ausgerechnet. Da
der Bootloader weit oben ist, bekommst du eine sehr große Zahl.
Im ersten Fall (128192 bytes of flash) war ja vermutlich der "originale" bootloader aus dem Demoprogramm zum Mega1284p-xpld aus der hex-Datei mega_1284p_xplained_bootloader_and_example.hex darauf.
Im zweiten Fall (9798 bytes of flash) hatte ich inzwischen den kleineren optiboot bootloader geflashed. Ich hätte gedacht, dass nach
alles wieder so ist wie vorher. D.h. keine Spuren mehr vom optiboot bootloader vorhanden sind. Gibt es eine Quelle wo die Besonderheiten mit bootloader kurz und prägnant beschrieben werden?
das ist richtig. Fuer mich ist das aber meine eigene (Universal) Umsetzung. D17 hat den Zweck den RESET Eingang vom C41 Überschwinger beim Zurückschalten L->H zu schützen, weil ja dann die gespeicherte Ladung von C41 zur VDD addiert wird und den CMOS Eingang momentan auf Vcc+C41 Spannung aussetzt. R95 ist hier aber nicht notwendig. Bei den ATMEGA328PB ist der allerdings notwendig, weil der RESET Threshold Bereich schmaler ist und der RESET Eingang bei 3.3V USB Serial Adaptern nicht zuverlässig funktioniert (Siehe auch Watterott Kommentare dazu). Der 6-Pin JP1 Header folgt dem der Arduino Pro-Mini Boards und funktioniert mit passenden handelsüblichen USB Serial Adaptern. Es funktioniert alles bei mir einwandfrei. R87 und S6 ist ein Bord RESET Taster.
Die ICSP Beschaltung ist bei mir der Atmel Standard 2x3 Header, passend zu ATMEL AVR-ISP MKII. USB- ist bei mir gebraucht um den USART0 Port umzuschalten, weil der sonst andersweitig verwendet wird und das wird durch die blaue LD1 angezeigt, wenn der BL aktiv ist. Normalerweise ist USART0 an einer anderen Schnittstelle angeschlossen. Ist aber extern unwichtig zu wissen;-)
hast du jemals die Fuses richtig konfiguriert? Die bootsize Option ist
dafür kein Ersatz, falls du das annehmen solltest. Lies einmal die Fuse
aus und schau nach ob die BOOT Bits im High Byte korrekt gesetzt sind.
Oder prüf gleich alle nochmal.
Hallo Veit,
mit
"Boot reset vector enabled (default address=$0000); [BOOTRST=0]"
"Boot flash section size = 2048 words Boot start address=$F800; [BOOTSZ=01]"
Fuse: High / Mask: 0x06
d.h. BOOTSZ1 und BOOTRST enabled.
sollte es doch passen, oder?
wenn ich einmal eine Anregung geben darf. Die Fusezeile fand ich schon praktisch. Zudem die fuses, signatur usw. Angaben in der Tabelle darüber noch nie gestimmt haben. Stehen immer auf 0? Warum hat man die Tabelle nicht korrigiert oder eingekürzt?
Die Fuse Angaben könnte man doch eigentlich Controllerabhängig gestalten.
Alte Controller mit low/high/ext Fuse. Neue mit fuse0...9 oder wie lang auch immer. Meinetwegen zum auslesen mit einem readFuse Kommando, sodass man nicht alles einzeln abfragen muss. Das wäre eine sichtbare Verbesserung. :-)
Übrigens, ich bekomme keine Wertausgabe zu Gesicht mit bspw.
avrdude -c avrispmkII -p m2560 -v -U lf:r:-:h
obwohl es gemeldet wird
avrdude: processing -U hf:r:-:h
avrdude: reading hfuse memory ...
avrdude: writing output file <stdout>
Übrigens, ich bekomme keine Wertausgabe zu Gesicht mit bspw.
avrdude -c avrispmkII -p m2560 -v -U lf:r:-:h
obwohl es gemeldet wird
avrdude: processing -U hf:r:-:h
Warum wird bei "avrdude -U lf:r:-:h" "-U hf:r:-:h" prozessiert? :-)
passt. Der Opti-Bootloader ist 384 Bytes groß. Ein Word sind 2 Byte, passt in 512 Words BootSize locker rein. Man bräuchte demnach auch kein BootSize Bit "setzen". Passt noch in 256 Word rein. Größere BootSize stört aber praktisch nicht, außer man benötigt noch paar Bytes Flash.
Ich weiß nicht was schief läuft.
Edit 2:
was vorhin hier stand war falsch, hatte im Manual die falsche Tabelle erwischt. Also BootSize Einstellung 2048 Words und Start Adresse 0xF800, die Aussagen passen zusammen. Egal, die Fuse muss stimmen.
ich werde die Versuche einen funktionierenden Bootloader auf dem Mega-1284p-XPLD zu installieren vorerst beenden und mich stattdessen dem Programmieren des Mega-1284p-XPLD widmen. Da ich ab und zu zw. zwei Wohnungen pendle, wäre es ganz praktisch gewesen, nur das Mega-1284p-XPLD und ein USB-Kabel und nicht auch noch einen Atmel ICE oder AVR ISP mkII mitnehmen zu müssen. Aber so groß und schwer sind die ja nun auch nicht.
Ich habe jetzt die Fuses auf low 0xF7, high 0x1F, ext 0xFF, d.h. keinen BOOTRST und Boot Flash Section Size 512 gesetzt. Dann habe ich in dem Demoprogramm zum Mega-1284p-XPLD nur das nötigste der QTouch-Routinen auskommentiert, damit ich zu allen Funktionen den Quelltext habe. Dann neu kompiliert. Das hex habe ich mit dem Atmel ICE in den Mega1284p geschrieben:
