Hallo,
ich habe leider mir noch kein SWD-Programmer organisiert. Für einen Testaufbau möchte ich den Zero mit dem SAMD21G18A nutzen. Dieser ist weitesgehend kompatibel zum SAMD21E18A, den ich später einsetzen möchte.
Nun habe ich mal wieder das Problem, dass ich den Zero nicht programmieren kann.
Ich habe das USB Kabel in den Programming Port gesteckt,
in der IDE folgende Einstellungen gemacht,
Werkzeuge > Platine: "Arduino Zero(Programming Port)"
Werkzeuge > Port: "COM4 (Arduino Zero (Programming Port))"
Werkzeuge > Programmer: "Atmel EDGB"
Das ganze mit dem Blink-Sketch getestet,
erhalte aber nur folgende Rückmeldung
Der Sketch verwendet 11.060 Bytes (4%) des Programmspeicherplatzes. Das Maximum sind 262.144 Bytes.
Open On-Chip Debugger 0.9.0-gd4b7679 (2015-06-10-22:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 0
adapter speed: 500 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked
Im GeräteManager wird der Zero korrekt erkannt. Auch kann ich diesen im Atmel Studio 7.0 sehen. Unter Device Programming ist das auslesen der Target Voltage und setzen der SWD Clock möglich.
Sobald ich aber ein Programm aufspielen oder aber die Device signature auslesen möchte, erhalte ich ein Timeout. OS ist Win10 x64 Edu
Hallo,
in Atmel Studio kannste keine Device ID auslesen? Dann willst du den aber nicht über USB flashen, sondern direkt mittels Programmer? Das Problem hatte ich letztens als noch ein Display am SPI angeschlossen war. Abgezogen und ich konnte mittels mk-II den Mega flashen.
Hallo Doc, zwischen dem ATSAMD21G18A ist ein Programmer onBoard zwischengeschaltet.
The Zero has been designed in collaboration with ATMEL, and the on-board EDBG can be used through ATMEL Studio to get full access to the microcontroller memories to help debug your code.
Des weiteren haben ich im Getting Started folgendes, für mich etwas verwirrend geschriebenes gefunden
Burn the Bootloader
Using the Zero Programming Port it is possible to burn the booloader used by the Native USB port. To burn the bootloader follow this procedure:
select Tools->Programmer->Atmel EDBG
select Tools->Board->Arduino/Genuino Zero (Programming Port)
select Tools->Burn Bootloader
Das habe ich am Programming Port gemacht, jedoch bekomme ich dort ebenfalls einen Fehler, welöcher wieder auf openocd zurückzuführen ist.
Arduino: 1.6.5 (Windows 8.1), Platine: "Arduino Zero (Programming Port)"
C:\Users\sschu\AppData\Roaming\Arduino15\packages\arduino\tools\openocd\0.9.0-arduino/bin/openocd.exe -d2 -s C:\Users\sschu\AppData\Roaming\Arduino15\packages\arduino\tools\openocd\0.9.0-arduino/share/openocd/scripts/ -f C:\Users\sschu\AppData\Roaming\Arduino15\packages\arduino\hardware\samd\1.6.1/variants/arduino_zero/openocd_scripts/arduino_zero.cfg -c telnet_port disabled; init; halt; at91samd bootloader 0; program {{C:\Users\sschu\AppData\Roaming\Arduino15\packages\arduino\hardware\samd\1.6.1/bootloaders/zero/samd21_sam_ba.bin}} verify reset; shutdown
Open On-Chip Debugger 0.9.0-gd4b7679 (2015-06-10-22:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
Info : only one transport option; autoselect 'swd'
adapter speed: 500 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 02.10.017E
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
in procedure 'init'
in procedure 'ocd_bouncer'
Fehler beim Brennen des Bootloaders.
Hallo,
hmmm, Programme werden also nur am nativen Port geflasht. Leider nein, da kann ich leider nicht helfen, habe keine Ideen dazu. Irgendwelche Jumper setzen?
Auf der openocd.org Seite gibts auch keine FAQ?
Den 500kHz Takt reduzieren?
Also am PC liegt es schon einmal nicht, auf dem Laptop kam es zum selben Fehler. Werd mal schauen, ob ich die STM32 STLink zum laufen bekomme auf meinem Discovery
Er unterstützt aber nur MCU's von ST. NXP, Atmel oder TI lassen sich damit nicht programmieren.
https://www.mikrocontroller.net/articles/STM32#Programmierung
Hat sich somit dann doch erledigt 
So, Problem ist gelöst.
Wieso auch immer, aber es war so, dass Reset nach GND gezogen wurde. Das Board befand sich auf diesen Sparkfun Haltern mit danebenliegenden Breadboard. Alle Schrauben gelöst und sofort änderte sich der Reset Pegel. Kann nun wieder auslesen.
Hallo,
sehr schön. Immer wieder diese fiesen kleinen Pannen. 