Ich versuche, meinen Atmel at91sam3u Cortex-m3-Armchip dazu zu bringen, eine LED blinken zu lassen. Ich habe einen Olimex ARM-USB-OCD-H- JTAG-Programmierer und verwende Open OCD, das unter OS X ausgeführt wird, um meinen Chip zu programmieren. Ich verwende die bereitgestellten Open OCD-Startskripte für den jtag-Programmierer und meinen Chip. Ich habe keine Probleme beim Kompilieren und Linken des Programms, und ich scheine in der Lage zu sein, das Programm erfolgreich auf den Chip zu laden. Allerdings blinkt die LED nur, wenn ich das Programm über gdb starte. Es funktioniert, egal ob ich es durchschreite oder kontinuierlich ausführe.
Damit es in gdb funktioniert, führe ich zuerst 'openocd' und dann in einem anderen Terminal aus (gdb-Feedback weggelassen):
$ arm-none-eabi-gdb blinky/blinky.elf
(gdb) target remote :3333
(gdb) load
(gdb) cont
Dies funktioniert ohne Probleme und die LED blinkt. Wenn ich gdb verlasse, wird das Programm natürlich gestoppt und die LED bleibt in dem Zustand, in dem sie sich zu diesem Zeitpunkt befand. Wenn ich auf die Reset-Taste des Chips klicke, geht die LED in einen neutralen (leicht an) Zustand.
Um zu versuchen, den Chip einfach zu programmieren, führe ich 'openocd' aus und dann in einem anderen Terminal:
$ telnet localhost 4444
> halt
target state: halted
target halted due to debug-request, current mod
xPSR: 0x81000000 pc: 0x00080107 msp: 0x20000598
> flash write_image blinky/blinky.elf
wrote 3044 bytes from file blinky/blinky.elf in 0.314594s (9.449 KiB/s)
> reset run
TAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Es liegen keine Fehler vor, aber die LED blinkt nicht, sie bleibt im neutralen Zustand.
Das Linker-Skript legt fest, dass das Programm (.text) in den Flash0-Speicher gestellt wird. Daher habe ich versucht, gpnvm-Bit 1 zu setzen, da dies das Sram vs. Flash-Boot-Auswahlbit gemäß dem at91sam3-Datenblatt ist. Dies half nicht, und es schien das gdb-Formular daran gehindert zu haben, richtig zu laufen.
Muss ich das Board vielleicht mit einer Art Bootloader flashen, der Programme aus der Flash0-Bank laden kann? Ich bin davon ausgegangen, dass der Chip dabei war.
Ich war noch nicht in der Lage, den .text in sram statt in flash0 zu laden, da ich Probleme hatte, das Linker-Skript zu ändern, das ich dafür tun muss.
Hinweis: Der at91sam3u-Chip befindet sich auf einer benutzerdefinierten Leiterplatte, die im Rahmen eines Studentendesignprojekts entwickelt wurde. Daher ist es möglich, dass beim PCB-Design ein Fehler gemacht wurde ... aber ich würde denken, dass es in diesem Fall auch in gdb nicht richtig laufen würde.
Danke schön.
$ telnet localhost 4444
> halt
target state: halted
target halted due to debug-request, current mod
xPSR: 0x81000000 pc: 0x00080107 msp: 0x20000598
> flash write_image blinky/blinky.elf
Sie benötigen normalerweise reset initvor dem Flashen ein Löschen/Schreiben, das haltmöglicherweise nicht ausreicht. Darin gdbist monitor reset init.
Der Flash muss auch vor dem Schreiben gelöscht werden:flash write_image erase unlock blinky/blinky.elf
reset initin gdb oder über Telnet mache, bekomme ich das: (gdb) monitor reset JTAG tap: sam3.cpu ... \ Halt timed out, wake up GDB \ timed out while waiting for target halted \ TARGET: sam3.cpu - Not halted \ in procedure 'reset'Einzeln funktionieren die Befehle jedoch gut ... Ich bin mir nicht sicher, ob dies ein Problem ist oder einfach reset initzu schnell passiert.reset_configdie tatsächliche Verkabelung der Reset-Leitung(en) nicht übereinstimmt. Du kannst es versuchen reset_config none.Sie haben einen ziemlich großen Hinweis gegeben, als Sie sagten, dass die LED in einem "neutralen" Zustand war. Es gibt keinen "neutralen" Zustand für einen ordnungsgemäß funktionierenden Digitalausgang, also meinten Sie wahrscheinlich, dass die LED schwach leuchtet. Und das bedeutet normalerweise, dass der Pin, der die LED antreibt, so schnell ein- und ausgeschaltet wird, dass Sie das Blinken nicht sehen können. Sie haben Ihren Code nicht gezeigt, sodass wir Ihre Verzögerungsschleife nicht beurteilen können, und es ist möglich, dass Ihr Debugger die Codeausführung so weit verlangsamt hat, dass sie zu funktionieren schien.
Eine andere zu berücksichtigende Sache ist, dass der JTAG-Debugger möglicherweise die Kontrolle über den RESET-Eingang übernommen hat. Wenn dies der Fall ist, müssen Sie den Debugger trennen, um den "normalen" Betrieb zu sehen. Ich gehe davon aus, dass Sie natürlich die richtigen Werte für den anfänglichen Stapelzeiger und den PC-Wert an den Positionen 0x0 und 0x4 geschrieben haben.
Obwohl die Debugging-Session beendet ist, kann es vorkommen, dass Ihr Hardware-Debugger noch die Signalkontrolle des RESET hat.
Eine unelegante Problemumgehung besteht darin, den Debugger von Ihrem Ziel zu trennen und einen Kaltstart durchzuführen (Stromversorgung aus und dann wieder ein).
Chintalagiri Shashank
Connor Wolf