Atmel flashen unter Mac OS X über USB

Unter Mac OS X wollte das flashen des Atmel erst nicht klappen. Für alle, die das gleiche Problem – sei es unter Linux, als auch unter Mac OS X – auch schon einmal hatten, hier nun die Lösung. Zum flashen über USB wurde das USB AVR Lab mit der Standardfirmware (ab Werk) von www.ullihome.de genutzt. Beim Nutzen des avrdude zum flashen (hier installiert via Macports), stellte sich heraus dass dieser nicht aktuell genug war, auch meinen Atmel Atmega 2560 zu unterstützen. Der avrdude wurde also wieder per Macports wieder entfernt. Komfortabel wurde nun die sehr aktuelle Version des avrdude (zurzeit V5.10-1) (mit ebenfalls aktuellerem avr-gcc) mittels des CrossPack Paketes auf dem Mac installiert.

Zum Programmieren (flashen) über den USB-Port ist nun folgender Befehl nötig:

avrdude -p m2560 -c usbasp -P usb -e -U flash:w:FILENAME.hex

 

Der manuelle compile und link Vorgang für ein C-Programm für den Atmega sieht übrigens wie folgt aus. Konfortabler geht dieses natürlich per Makefile.

avr-gcc FILENAME.c -c -o FILENAME.o -Os -g -mmcu=atmega2560

avr-gcc FILENAME.o -o FILENAME.elf -mmcu=atmega2560

avr-objcopy -j .text -j .data -O ihex FILENAME.elf FILENAME.hex

 

Sollte folgende Fehlermeldung erscheinen:
 
avrdude: Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc
 
muss das Ganze als root ausgeführt werden. also per "su" oder "sudo" bzw. "sudo -s".
 

 

Zwei Tage flashen und keine Funktion des neuen RN-MEGA 2560 Moduls…

Nach dem Tod des alten und ersten Atmel-Boards und 60 EUR später,  von robotikhardware.de sollte nun einfach das neu gelieferte Board geflasht und ein den Roboter eingesetzt werden…

Interessanterweise lies sich das Board zwar einwandfrei flashen und wurde auch am USB-Port sauber erkannt (auch das mitgelieferte Testprogramm lief beim ersten Einschalten einwandfrei), aber leider lief danach scheinbar gar nichts mehr.

Konkret lief das flashen zwar einwandfrei durch (einschließlich vorigem Löschen und anschließendem verify), das Atmel-Board bzw. die geflashte Firmware "lief" danach aber nie. Selbst ein Testprogramm welches nur ein Bit setzte um die onBoard-LED zu aktivieren lief nicht.

Um das Ganze nicht noch spannender zu machen: Ursache war ein vom Lieferanten falsch gesetztes Fuse-Bit! Nur unter größter Unterstützung eines Forum-Mitgliedes des Forums RoboterNetz.de, wurde diese Ursache gefunden (Danke an Sven Arnold).

Entgegen der Anleitung auf der mitgelieferten CD war das betreffende Fuse-Bit M nicht wie folgt gesetzt:

Quelle: http://www.robotikhardware.de/download/rnmega2560.pdf

 

Statt dessen war das Bit auf "Bootloader" gesetzt. Dieser stand jedoch gemäß beiliegender CD gar nicht zur Verfügung, sondern war in Planung. [Update: Mittlweile verfügbar] Damit war klar, dass der Atmel per Bootloader starten wollte und nicht sofort das geflashte Programm startete. Kleine Ursache, große Wirkung. Am Ende der zwei Tage leuchte dann auch wieder die LED und das alte, unveränderte Atmel-Progamm lief natürlich auch wieder anstandslos:

   

:-)

Ruhe in Frieden – RN-MEGA 2560 Modul…

Was so passiert, wenn man einen Stecker falsch beschriftet und leichtfertig sich auf die (falsche) Beschriftung verlässt sieht man in den nachfolgenden Bildern. Leider wurden hier für einige (Schreck)Sekunden 12V auf das Atmel-Board gegeben, auf welches nur 5V verträgt. Das Ergebnis sieht dann (nach einen kleinen, aber feinen Rauchwolke so aus:

   

Für diejenigen, die den Atmel von so nah noch nie gesehen haben: Der Hügel sollte dort auf dem Bild nicht zu sehen sein…

Ein paar Tests (und Drahtbrücken) später…

…stellte sich erfreulicherweise heraus, dass die beiden nachgelagerten Motorcontrol-Boards keinen Schaden erlitten haben… Glück gehabt.