Hallo alle zusammen,
ich kämpfe gerade mit einem eigenen AVR32-Board (UC3A1256). Die Hardware
funktioniert, und der Bootloader soweit auch. Zumindest unter Windows
mit dem batchisp.
Da ich aber eigentlich unter Linux arbeite, muss es auch dort
funktionieren. Macht es aber leider nicht.
Der Code basiert auf den Makefiles der Beispiele (GPIO-Sample) und macht
wie gesagt unter Windows keine Probleme. Ein
1
make program
funktioniert aber nicht, da avr32program scheinbar kein DFU
unterstützt. Mit dem JTAG ICE mkII bricht er mit der nachfolgenden
berüchtigten Fehlermeldung ab.
1
Connected to JTAGICE mkII version 6.6, 6.6 at USB.
Warning: Flash page or region at 0x80000000 could not be erased (LOCKE set).
4
Program may be corrupted.
Ich habe dann noch den Linux-FLIP versucht, der aber eine DLL vermisst
(klar, unter Linux). Dann habe ich mich noch mit dfu-programmer(.sf.net)
aus dem SVN ausgetobt. Alles ohne Erfolg.
avr32program geht nur, wenn ich zuvor ein "chiperase" mache, was aber
leider auch den Bootloader löscht.
Wie kann ich den AVR32 mit DFU unter Linux flashen. Das kann doch alles
nicht so schwer sein...
>avr32program geht nur, wenn ich zuvor ein "chiperase" mache, was aber>leider auch den Bootloader löscht.
Tja ist doch klar,der bootloader sitzt im Speicher ab 0x80000000 -
0x80002000. Und dieser Berreich ist mit Lockbits gesperrt. Beim
Chiperase wird dieser Bereich mitgelöscht und wieder Freigegeben.
Du musst also dafür sorgen, dass dein Programm erst ab 0x80002000
anfängt und dein Jtag auch erst ab da Flasht.
Gruß
Zippi schrieb:
> Tja ist doch klar,der bootloader sitzt im Speicher ab 0x80000000 -> 0x80002000. Und dieser Berreich ist mit Lockbits gesperrt. Beim> Chiperase wird dieser Bereich mitgelöscht und wieder Freigegeben.
Ich weiß. Nur leider sind die Beispiele im Framework entweder mit
Bootloader oder mit Trampoline. Unter Windows wird der Trampoline-Code
dann übersprungen. Zumindest von Batchisp.
> Du musst also dafür sorgen, dass dein Programm erst ab 0x80002000> anfängt und dein Jtag auch erst ab da Flasht.
Wie soll das gehen? Dann müsste der Linker das Binary ja direkt für
diesen Offset erzeugen. Dazu habe ich im Makefile (config.mak) aber
nichts gefunden. Hast Du einen Tip?
Und läuft bei Dir der Bootloader unter Linux? Der Weg über den
JTAG-Adapter wäre eigentlich nicht meine bevorzugte Lösung.
Ich selber nutze den bootloader nicht unter linux.
Bei mir hab ich einfach die linker scripts geändert. Dann muss ich mich
um nix mehr kümmern. Das Programm ist dann automatisch ab 0x80002000 und
der Jtag flasht es dann auch dahin.
Welches AVR32 Studio hast du genau? Und welches Toolchain? Ich kann ja
mal die Geänderten scripts für den at32uc3a1256 online stellen.
Gruß
Zippi schrieb:
> Ich selber nutze den bootloader nicht unter linux.
OK. Ist aber eine nette Sache, da man die teuren JTAG-Adapter nicht
braucht.
> Bei mir hab ich einfach die linker scripts geändert. Dann muss ich mich> um nix mehr kümmern. Das Programm ist dann automatisch ab 0x80002000 und> der Jtag flasht es dann auch dahin.
Gute Idee. Ich frage mich dann nur, warum die bei Atmel das nicht gleich
anbieten. Ich meine, das Überspringen des Bootloader ist doch der
Regelfall. Warum dann der Quatsch mit "Trampoline"?
Der USB-Bootloader Batchisp ignoriert den Bootloader einfach, sofern
dieser Bereich gelockt ist. Mit JTAG macht er das auch unter Windwos
nicht.
Ich bin wirklich sehr entäuscht, dass der ganze Kram unter Linux nicht
so wirklich funktioniert.
> Welches AVR32 Studio hast du genau? Und welches Toolchain? Ich kann ja> mal die Geänderten scripts für den at32uc3a1256 online stellen.AVR32-Studio nutze ich nur unter Windows. Und zwar die aktuelle.
Das mit den Scripten wäre wirklich nett. Muss man dann sonst noch was
ändern?
Naja,
eigentlich brauch ich dann deine Aktuellen scripts, da ich nicht weiß
welche du genau hast. Sonst öffne einfach mal deine scripts mit dem
Hex-editor, und änder alle werte wo 0x80000000 steht zu 0x80002000. Dann
sollte es gehen.
Zusätzlich musst du sonst nichts mehr machen.
Gruß
Sorry, bin leider erkrankt und kann nur kurz antworten...
Ich habe jetzt die Installation nicht vorliegen, aber die Files stammen
aus dem Framework 1.6.1.
Alles weitere aus dem Gedächtnis....
Wenn ich nun im Linkerscript den Offset anpasse, was passiert dann mit
den Interruptvektoren. Liegen die nicht auch "dort unten"? Oder ist der
Offset nur für das Codesegment eingetragen? wie gesagt, ich habe das
Ganze momentan nicht im Zugriff.
In den Makefiles ist die Flashgrenze 0x80000000 auch angegeben. Muss ich
dass dann auch dort nach oben "verbiegen"?
Ich finde das schon recht seltsam, dass Atmel da nichts im Framework
"vorbereitet" hat. Es wird ja sicherlich mehr User geben, die den
Bootloader nicht überschreiben wollen.
PS: mal was anderes. Wie siehst Du die "Gefahr", das Atmel nach dem
AP7000 auch die UC3-Familie beerdigt?
Also die Interrupt Vektoren haben keine fessten Adresse nur einen
Bereich in dem sie Liegen müssen. Vielleicht reicht es ja wenn du es im
Makefile änderst. Ich nutze nur das AVR32 Studio.
Die/Der/Das Trampoline ist ja im Framwork um den Bootloader zu
Überspringen.
>PS: mal was anderes. Wie siehst Du die "Gefahr", das Atmel nach dem>AP7000 auch die UC3-Familie beerdigt?
Naja die AP7000 sind ja noch nicht beerdigt. Kenne sogar Firmen die neue
AP7000 Projekte machen.
Dazu hat Atmel auf der Embedded World bekannt gegeben, dass sie jetzt
auch UC3 mit FPU bauen wollen.
Gruß
> Ich nutze nur das AVR32 Studio.
Unter Linux oder Windows? Wie verträgt es sich eigentlich mit einem
originalen Eclipse? Ich mag das ja garnicht, wenn jeder Hersteller "sein
Ecplise" zusammen baut, statt einfach nur ein plugin für das
Origianl-Ecplise anzubieten. Wenn man von allen Anbietern die IDEs
installiert, dann hätte man am Ende Ecplise 3-4 mal drauf. :-(
> Die/Der/Das Trampoline ist ja im Framwork um den Bootloader zu> Überspringen.
Jaein. Ich habe das so verstanden, das man entweder den Bootloader dazu
linkt, oder Trampoline. Nur warum sie dann nicht einfach den
Trampoline-Code beim Flashen ignorieren, das ist mir ein Rätsel.
> Naja die AP7000 sind ja noch nicht beerdigt. Kenne sogar Firmen die neue> AP7000 Projekte machen.
Auf der Homepage sind sie mit dem Label "nicht in neuen Projekten
einsetzen" markiert. Und das ohne Ersatztypen. Auf avrfreaks wurde eine
Mail von Atmel gequotet, die besagt, das die AP7000 noch 5 jahre
geliefert werden. Thats it. Als Ersatz werden die UC3 und die ARMs
genannt.
Ich hatte halt die Hoffnung, das der AVR32-Core mal eine Lösung ist, die
einem den Weg vom Stand-Alone-System bis zum Linux-System mit einem Core
erlaubt. Die ARMs haben wir zu viel verschiedene Peripherie drumherum.
Da backt jeder sein Süppchen -- es gibt von ARM ja nicht mal einen
definierten Interrupt-Controller. Egal, das sprengt IMO diesen Thread.
;-)
Hi,
Also zurzeit nur auf Windows, hatte aber auch mal auf meinen Linux
Notebook laufen.
>Jaein. Ich habe das so verstanden, das man entweder den Bootloader dazu>linkt, oder Trampoline. Nur warum sie dann nicht einfach den>Trampoline-Code beim Flashen ignorieren, das ist mir ein Rätsel.
Naja normalerweise wird das dann eben gemacht. Also der Trampoline code
wird nicht richtig geflasht, da der bereich gesichert ist. Und da der
Bereich gesichert ist beleibt der Bootloader drauf. Aber finde das auch
nicht so toll. Ich mach das einfach mit den geänderten Linkerscripts und
dann muss ich mich um nichts mehr kümmern. Debuggen mit jetag und so
funktioniert alles unverändert. Und der Bootloader bleibt auch drauf.
>Ich hatte halt die Hoffnung, das der AVR32-Core mal eine Lösung ist, die>einem den Weg vom Stand-Alone*-System bis zum Linux-System mit einem Core>erlaubt. Die ARMs haben wir zu viel verschiedene Peripherie drumherum.>Da backt jeder sein Süppchen -- es gibt von ARM ja nicht mal einen>definierten Interrupt-Controller. Egal, das sprengt IMO diesen Thread.>;-)
Jop ich finde das geht mit den AP7000 auch wunderbar. Du kannst da
ganznormal für Programmieren, ist auch nicht komplexer als für die UC3,
und Linux läuft auch drauf.
Naja, wer weiß was die noch alles mit den UC3 machen
Gruß
Phil S. schrieb:
> Ich mach das einfach mit den geänderten Linkerscripts und> dann muss ich mich um nichts mehr kümmern.
So, ichhabe das gerade mal probiert. Ich habe in config.mk den Anfang
des FLASH auf 0x80002000 verlegt. Das wird zum Programmierung benutzt.
Im Linkerscript habe ich das auch gemacht. Dort habe ich auch gleich die
Länge angepaßt.
Lasse ich Trampoline drinnen, so beginnt Trampoline (!) nun ab *2000 und
der Programmstart liegt bei *4000. Linke ich Trampoline nicht mit, kommt
eine "cannot fint entry symbol _trampoline". Wer referenziert den auf
Trampoline?
> Jop ich finde das geht mit den AP7000 auch wunderbar. Du kannst da> ganznormal für Programmieren, ist auch nicht komplexer als für die UC3,> und Linux läuft auch drauf.
Da hast Du mich falsch verstanden. Die AP7000-Familie sollte für mich
ein "Weg nach oben" sein, der aber nun von Atmel eingestellt wurde.
Übrig bleibt UC3, und die sind ja nicht Linux-tauglich. Also ist diese
Migration innerhalb einer "COre-Familie" weg.
> Naja, wer weiß was die noch alles mit den UC3 machen
Ich habe nur bedenken, dass sie nach dem AP7000 auch die UC3
einstampfen. Kleine ARMs hat Atmel ja auch..... Wie beim AP7000, da
empfehlen sie ja auch ihre ARMs.
Sorry, ich habe im config.mk dieses Linkerflag übersehen:
1
-Wl,-e,_trampoline
Danach klappt das Linken, und der Code fängt nun auch richtig an.
Witzigerweise sind die Symbole nun anders arrangiert. Aber egal.
Was nicht geht ist das Flashen! Ein "make program" ruft avr32program
auf, dass dann aber sofort den Geist aufgibt, da für 0x80002000
angeblich die LOCKE bits gesetzt sind. dfu-programmer läuft auch nicht.
Unter Windows ging es Flashen.
Dummerweise will aber AVR32-Studio die Fuses nicht auslesen.
Hast Du noch eine Idee?
>Witzigerweise sind die Symbole nun anders arrangiert.
Welche Symbole?
>Was nicht geht ist das Flashen! Ein "make program" ruft avr32program>auf, dass dann aber sofort den Geist aufgibt, da für 0x80002000>angeblich die LOCKE bits gesetzt sind. dfu-programmer läuft auch nicht.
Hmmm komisch. Versuch mal den Bootloader im AVR32 Stuio neu drauf zu
flashen. Also aufs Jtag rechtsklick und dann "Program Bootloader...".
Gruß
Phil S. schrieb:
> Welche Symbole?
Die in der .sym Datei...
1
...
2
80002000 T _start
3
80002008 t _unhandled_interrupt
4
80002010 T _get_interrupt_handler
5
8000208c T INTC_init_interrupts
6
8000211c t INTC_init_evba
7
80002130 T INTC_register_interrupt
8
80002198 t pm_set_osc0_mode
9
...
> Hmmm komisch. Versuch mal den Bootloader im AVR32 Stuio neu drauf zu> flashen. Also aufs Jtag rechtsklick und dann "Program Bootloader...".
Das geht. Ich hatte den Booloader schon mal bei meinen Gehversuchen
unter Linux gekillt. Aktuell ist der 1.0.3 drauf.
Aber wie gesagt, das geht nur unter Windows. Unter Linux läuft nix. Da
schlägt schon der Erase mit JTAG fehl....
Eigentlich sollte gerade der JTAGICE gut funktionieren. Ich weiß nur
nicht, was das AVR32-Studio unter Windows anders macht. Das
Eclipse-plugin dort sollte auch avr32program (CLI-Tool) aufrufen.
Genauso wie es batchisp3 für die DFU/ISP Programmierung nutzt.
Es ist ziemlich nervig, wie holprig das Ganze unter Linux funktioniert.
Leider findet sich im Internet ziemlich wenig Brauchbares zum AVR32. Was
mich ziemlich überrascht. Der Erfahrungsaustausch ist ziemlich dünn. Die
Distris sagten immer, dass Atmel den AVR32-Kern ziemlich pusht. Da war
der "eigene" Kernel-Port für Linux immer das Aushängeschild. Naja, das
haben sie ziemlich schnell wieder abgehängt. :-(
Kannst Du dich noch erinnern, wie Du die AVR32 unter Linux geflasht
hast?
Ich habe mir heute den Rest gegeben und unter Ubuntu Karmic AVR32-Studio
installiert. Ich wollte einfach mal sehen, ob das Flashen damit klappt.
Nichts klappt. Nach dem Start werden Targets gesucht und der JTAGICE
wird gefunden. Dann soll aber gleich ein Firmware-Update erzwungen
werden. Der Dialog "Wollen Sie updaten" bietet nur OK! Das Update von
V6.6 auf V6.6 (!) geht natürlich schief. Aber dafür kommt es nach jedem
Scan. Da hilft nur JTAG abziehen und nachher wieder dranstecken. Unter
Windows konnte das vermeindliche Update dann durchlaufen.
Auf jeden Fall konnte ich mit AVR32-Studio noch nicht mal ein
Beispielprojekt mit dem Wizard anlegen. Der letzte Schritt klappte nicht
-- manchmal sogar das "Next" nicht. Ich konnte alles auswählen, dann
blieb zumindest das "Finish" immer ohne Reaktion. Als wenn man es nicht
angeklickt hätte (3D-Effekte für button down gab es, auch der Fokus
wurde gewechselt).
Das Gleiche passierte beim Versuch ein bestehendes HEX/ELF-File zu
flashen. Der Dialog des Programmers kam, aber das OK bleib ohne Aktion.
Mit JTAGICE lässt sich nicht mal z.B. die CPUINFO auslesen. Es kommt zu
einer nichtssagenden Fehlermeldung. Der avr32program Aufruf verwendet
Parameter zur Angabe des Programmers, der in der Shell nachgestellt
offenbart, das avr32program aus dem letzten Paket der Toolchain dies
garnicht kennt.
Das Gute ist aber, dass aus mir nicht ersichtlichen Gründen avr32program
mit JTAG plötzlich geht. Ein "make program" flasht nun die Firmware.
Zu Guter letzt habe ich auch noch den Batchisp aus dem FLIP-Paket zum
Laufen bekommen. Das Paket ist leider nicht richtig Linux tauglich und
hat noch einen alten Fehler. Nach dem Umbiegen von /sys/usb/bus/ auf
/dev/bus/usb/ verrichtet auch batchisp seinen Dienst. Wenn auch nur mit
absoluten Pfaden. ;-)
Am Ende muss ich leider sagen, dass das alles den Eindruck hinterlässt,
als wäre es "mit der heißen Nadel gestrickt". Die Tipps und Workarounds
zu FLIP stammen aus dem Jahr 2008!
Thread beobachten
Seitenaufteilung abschalten