www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR32UC3: flashen unter Linux funktioniert nicht!


Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
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.
Connected to JTAGICE mkII version 6.6, 6.6 at USB.
     Unlocking flash: ================================================== 100.0%
Warning: Flash page or region at 0x80000000 could not be erased (LOCKE set).
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...

Autor: Zippi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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ß

Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zippi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Zippi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: joede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Phil S. (zippi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: joede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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. 
;-)

Autor: Phil S. (zippi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
MEMORY
{
  FLASH (rxai!w) : ORIGIN = 0x80002000, LENGTH = 0x0003E000

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.

Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, ich habe im config.mk dieses Linkerflag übersehen:
-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?

Autor: Phil S. (zippi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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ß

Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil S. schrieb:

> Welche Symbole?

Die in der .sym Datei...
...
80002000 T _start
80002008 t _unhandled_interrupt
80002010 T _get_interrupt_handler
8000208c T INTC_init_interrupts
8000211c t INTC_init_evba
80002130 T INTC_register_interrupt
80002198 t pm_set_osc0_mode
...


> 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....

Autor: Phil S. (zippi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso ok. Was geht denn Überhaupt mit dem Jtag unter Linux? Ich weiß 
garnet ob ich damals das Jtag unter Linux benutzt hatte.

Gruß

Autor: joede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Joerg Desch (jdesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.