OnurKayikci Geschrieben November 23, 2012 at 15:05 Geschrieben November 23, 2012 at 15:05 Hallo, ich würde gerne Treiber-Software ändern und debuggen können. Die geänderte Software habe ich bereits in AtmelStudio oder Eclipse kompilieren können (durch CMAKE). Zum Debuggen habe ich SAM-ICE Debugger Tool von Atmel gekauft. Jedoch kann SAM-ICE leider keine Verbindung mit dem Master-Brick herstellen. Es kann die Spannung messen und anzeigen aber verbinden kann es nicht. Hat jemand vielleicht Ahnung woran es liegen mag? Schöne Grüsse Onur Zitieren
borg Geschrieben November 23, 2012 at 16:29 Geschrieben November 23, 2012 at 16:29 Standardmäßig ist JTAG aus, da die JTAG Pinne verwendet werden. Du kannst JTAG aktivieren, indem du in der config.h die "#define DISABLE_JTAG_ON_STARTUP" Zeile auskommentierst. Zitieren
OnurKayikci Geschrieben November 26, 2012 at 11:50 Autor Geschrieben November 26, 2012 at 11:50 Vielen Dank Borg, ich hätte noch eine Frage und zwar, nach Compilieren bekomme ich ein *.elf file statt *.bin im /build Folder. Woran mag es liegen? Sollte ich was bei MakeFile ändern? Gruss Onur Zitieren
OnurKayikci Geschrieben November 26, 2012 at 13:07 Autor Geschrieben November 26, 2012 at 13:07 Hallo Borg, die Hardware Files von Debug-Brick sind nicht mehr aktuell. Ich habe die Hardware Version 1.1 bekommen. Könnt ihr bitte die KiCad Dateien im Netz dem entsprechend aktualisieren? Gruss Onur Zitieren
borg Geschrieben November 26, 2012 at 23:33 Geschrieben November 26, 2012 at 23:33 Mh, probier nochmal das "generate_makefile" Script auszuführen und ruf dann nochmal make auf. Aus irgendwelchen Gründen findet cmake manchmal arm-none-eabi-objcopy nicht, deswegen wird dann keine .bin erzeugt. Ich konnte aber noch nie herausfinden was da wirklich Sache ist, beim zweiten mal geht es aber dann für gewöhnlich. Ich glaube das sich am Debug Brick nichts am Layout geändert hat zwischen 1.0 und 1.1 (nur am Silkscreen). Bin ich mir aber nicht sicher, da muss Bastian morgen was zu sagen. Zitieren
OnurKayikci Geschrieben November 27, 2012 at 10:48 Autor Geschrieben November 27, 2012 at 10:48 Vielen Dank Borg, "generate_makefile" hat geklappt, ich habe die *.bin Datei flashen können und schliesslich habe ich erstmal die Kommunikation über das SAM-ICE Debugger Tool erstellen können. Grüsse, Onur Zitieren
batti Geschrieben November 27, 2012 at 11:07 Geschrieben November 27, 2012 at 11:07 Beim Debug Brick hat sich nichts geändert. Grüße Zitieren
OnurKayikci Geschrieben February 11, 2013 at 17:01 Autor Geschrieben February 11, 2013 at 17:01 Kann jemand vielleicht zusammenfassen wie ich die Firmware debuggen kann? Wie kann ich die Firmware unter Eclipse kompilieren? Welche Kompiler-Tools brauche ich? Soll ich ein MakeFile selber erstellen? Zitieren
borg Geschrieben February 12, 2013 at 10:05 Geschrieben February 12, 2013 at 10:05 Also, ich benutze hier Eclipse + CDT + OpenOCD + CodeSourcery GCC zum debuggen: Meine openocd.cfg sieht wie folgt aus: source [find interface/jlink.cfg] source [find board/atmel_sam3s_ek.cfg] Ich starte mit openocd -f openocd.cfg Dann brauchst du das CDT Eclipse Plugin mit GDB Hardware Debugging: https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/getting-hardware-debuging-working-with-eclipse-and-code-sourcey Als Debug Einstellung dann Use remote target, JTAG Device = Generic TCP/IP. host name = localhost und port number = 3333 verwenden. Das ist zumindest meine Konfiguration. Dazu die Toolchain von CodeSourcery: https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription?@template=lite In Eclipse hab ich unter C/C++ Build -> Build Variables -> Builder Settings einfach "make -C ${ProjDirPath}/build" eingestellt, um direkt das Makefile zu nutzen. Zitieren
Mark Geschrieben February 26, 2013 at 21:52 Geschrieben February 26, 2013 at 21:52 Hallo, könnt ihr mir helfen? Ich verzweifle langsam Ich habe ebenfalls versucht, den Master-Brick mit SAM-ICE zu debuggen. Mein Aufbau ist folgender: - Master-Brick mit aufgesetztem Debug-Brick - Spannungsversorgung über USB (Master-Brick ist dauerhaft über USB mit dem PC verbunden) - SAM-ICE ist über ein JTAG-Kabel mit dem Debug-Brick verbunden - SAM-ICE wird über Atmel Studio 6.0 angesprochen Da JTAG in der normalen Firmware deaktiviert ist, habe ich eine Firmware gebaut, in der "#define DISABLE_JTAG_ON_STARTUP" auskommentiert worden ist. Diese habe ich erfolgreich auf die Master-Brick geflashed (Mit Brickv). Die Brick verhielt sich mit der neuen Firmware wie gewohnt. Mit SAM-ICE und Atmel Studio kann ich mit diesem Aufbau die Target-Spannung auslesen (3.3V). Sobald ich jedoch versuche, z.B. die Device-Informationen auszulesen, fällt die Target-Spannung auf 0.3V ab und bleibt auch nach mehrfachem Auslesen der Spannung konstant auf 0.3V. Abgesehen von dem Auslesen der Target-Spannung sind alle JTAG-Funktionen daraufhin nicht verwendbar. Außerdem gehen auf dem Master-Brick sämtliche LEDs aus (Direkt, nachdem ich eine JTAG-Funktion verwende (z.B. auslesen der Device-Information)). Wenn ich das JTAG Kabel abnehme, startet das Master-Brick oft neu (zu erkennen an den LEDs) oder bleibt hängen und kommt erst wieder hoch, wenn ich das USB Kabel ab- und wieder anstecke. Daraufhin habe ich eine Test-Firmware gebaut (Anschalten von zwei LEDs + Endlosschleife). Hier führt alleine schon das Anstecken des JTAG-Kabels dazu, dass die LEDs ausgehen. Sobald ich das JTAG-Kabel abnehme, gehen die LEDs wieder an. Wenn ich die "normale" Firmware des Master-Bricks verwende, kann ich die Target-Spannung normal auslesen. Wenn ich versuche, die Device-Information auszulesen, zeigt mir Atmel Studio an, dass keine Verbindung aufgebaut werden konnte. Die Target-Spannung bleibt in diesem Fall jedoch konstant bei 3.3V und auch die LEDs auf des Master-Bricks leuchten noch. Habt ihr eine Idee, woran das liegen kann? Viele Grüße Zitieren
borg Geschrieben February 27, 2013 at 10:32 Geschrieben February 27, 2013 at 10:32 Ohje, das liegt am Master Brick 2.0 . Vermutlich hat OnurKayikci die gleichen Probleme. Wir haben im Master Brick 2.0 einen Transistor eingebaut, mit dem die Stack Spannung nach oben hin getrennt und hergestellt werden kann. Vorher lief das über eine Diode, durch das neue vorgehen haben wir bessere 3.3V im Stack. Das führt jetzt allerdings dazu, dass direkt beim Startup keine 3.3V anliegen. JTAG bringt nun den Microcontroller in den Reset-Zustand, wodurch dann die 3.3V nicht mehr anliegen. Ich debugge hier immer mit meinem alten Master Brick 1.1 daher war das noch nie aufgefallen. Es gibt da jetzt mehrere Möglichkeiten das zu fixen: Unter den Master Brick 2.0 einen Master Brick 1.1 oder einen der anderen Bricks (Servo, Stepper, DC, IMU) stecken. Die versorgen über eine Diode mit 3.3V.Oben am JTAG-Stecker zusätzlich 3.3V extern über ein Labornetzgerät o.ä. einspeisen (dabei dann natürlich auch GND verbinden).Einen Debugger verwenden dem man fest eine Spannung einstellen kann die er verwenden soll (geht mit SAM-ICE soweit ich weiß nicht ).Den Pulldown Widerstand vom Master 2.0 runterlöten, der dafür sorgt das beim Startup der Transistor nicht geschalten wird (siehe Anhang). Wenn ein Lötkolben vorhanden ist, ist letzteres vermutlich die einfachste Möglichkeit. Mit einer großen Spitze den kompletten Widerstand warm machen und nach oben rechts rausziehen. An dieser Stelle erstmal Entschuldigung für die verschwendete Zeit und Danke für den Hinweis mit den Spannungen, dadurch bin ich erst darauf gekommen dass es dieses Problem geben könnte. Zitieren
Mark Geschrieben February 27, 2013 at 17:44 Geschrieben February 27, 2013 at 17:44 Danke für die schnelle Hilfe! Das Auslöten des Widerstandes hat das Problem scheinbar behoben. Ich konnte jedenfalls erfolgreich die Device-Informationen auslesen. Zitieren
Mark Geschrieben February 27, 2013 at 17:56 Geschrieben February 27, 2013 at 17:56 Debuggen und Flashen aus Atmel Studio heraus funktioniert auch! Alles wunderbar Zitieren
AuronX Geschrieben February 27, 2013 at 18:38 Geschrieben February 27, 2013 at 18:38 Auch wenn das für mich vermutlich nie relevant sein wird noch meine Bonusfrage: Welche Nebenwirkungen hat das runterlöten dieses Widerstandes? Zitieren
borg Geschrieben February 27, 2013 at 21:42 Geschrieben February 27, 2013 at 21:42 Wenn mehrere Master Bricks ohne den Widerstand gleichzeitig im Stack starten, speisen sie kurzzeitig (für ein paar µs bis die main() aufgerufen wird) alle gleichzeitig die 3.3V ein. Das wird keinerlei Nebenwirkungen haben. Warum das Probleme machen kann wenn das Langfristig so läuft (also wenn gar kein Transistor und keine Diode da wären) muss Batti beantworten, da reicht mein Etechnik-Halbwissen nicht aus um das zu erklären . Zitieren
AuronX Geschrieben March 18, 2013 at 10:45 Geschrieben March 18, 2013 at 10:45 Warum das Probleme machen kann wenn das Langfristig so läuft (also wenn gar kein Transistor und keine Diode da wären) muss Batti beantworten, da reicht mein Etechnik-Halbwissen nicht aus um das zu erklären . @Batti: Wäre cool, wenn du die Zeit dafür finden würdest Zitieren
batti Geschrieben March 18, 2013 at 12:09 Geschrieben March 18, 2013 at 12:09 Wir setzen auf dem Master Brick 2.0 einen Schalter ein, der aktiv die 3.3V durchschaltet. Dies wird von einem IC namens RT9701 übernommen. Im Vergleich zu der zuvor genutzten Dioden Lösung ist der Spannungsabfall hier minimal und es kommen wirkliche 3.3V im Stack an. Ist der Prozessor noch am Booten oder im Bootloader, so würde dieser Schalter durchschalten. Daher ist ein Pulldown bestückt der in diesem Fall dafür sorgt, dass der Schalter nicht schaltet. Problematisch hierbei ist, dass der Schalter wirklich bidirektional genutzt werden kann. Sprich ist die Spannung im Stack größer wie die 3.3V auf dem Board, so fließt der Strom in umgekehrte Richtung. Dies kann dazu führen, dass die Stromversorgung auf dem jeweiligen Brick aus dem Takt kommt oder im Worst Case irgendwann kaputt ist. Da eine vernünftige Aussage zu machen ist allerdings sehr schwierig. Z.B. ist bei den Stromversorgungs ICs die wir einsetzen nicht dokumentiert was in dem Fall passiert. Dauerhaft sollten also nicht mehrere Schalter in einem Stack geschalten haben. Dann ist man denk ich auf der sicheren Seite. Zitieren
davidkoch Geschrieben May 22, 2013 at 12:15 Geschrieben May 22, 2013 at 12:15 @borg: kannst du mir von den debug configurations ein paar screenshots machen? Ich bekomm den debugger nicht richtig zum laufen. Gruß David Zitieren
davidkoch Geschrieben June 3, 2013 at 06:53 Geschrieben June 3, 2013 at 06:53 Hallo, mittlerweile hab ich den debugger status erreicht. komme auf den chip und hatte ihn zwischenzeitlich am laufen. problem momentan, ist das er sofort in die ResetException() springt und garnicht bis zur main funktion kommt. Habt ihr ne idee warum? (Versuche das masterbrick zu debuggen) Gruß dAvid Zitieren
photron Geschrieben June 3, 2013 at 15:12 Geschrieben June 3, 2013 at 15:12 Laut borg ist das normal. Die ResetException() ist das was als erstes ausgeführt wird. main() wird von ResetException() ausgerufen. Du musst dann einfach im Debugger auf Continue oder so klicken denke ich. Zitieren
FloB Geschrieben August 14, 2013 at 07:09 Geschrieben August 14, 2013 at 07:09 Hallo ich hab noch ein Problem beim debuggen. Ich verwende Eclipse 4.3 (Kepler) mit dem Plug-in "CDT" unter Windows 7. Ich verwende einen ATMEL SAM-ICE JLINK Debugger. Eine Verbindung steht, aber ich bekomme Fehler beim debuggen mit Eclipse, bevor er mit komplett abbricht. symbol-file C:\\Users\\admin\\Desktop\\eclipse\\workspace\\master\\build\\master-brick.elf monitor flash device = AT91SAM3S4C monitor flash download = 1 monitor flash breakpoints = 1 monitor speed 1000 break main Breakpoint 12 at 0x419ce6: file C:\Users\admin\Desktop\eclipse\workspace\master\src\main.c, line 93. continue Program received signal SIGTRAP, Trace/breakpoint trap. 0x004047b4 in low_level_init () at C:\Users\admin\Desktop\eclipse\workspace\master\src\bricklib\drivers\board\board_lowlevel.c:88 88 } kill Zusätzlich bekomme ich folgendes angezeigt: Description Resource Path Location Type Symbol 'IRAM_SIZE' could not be resolved board_cstartup_gnu.c /master/src/bricklib/drivers/board line 180 Semantic Error Weiß irgend jemand, was ich hier machen kann? Gruß FLORIAN Zitieren
borg Geschrieben August 14, 2013 at 08:20 Geschrieben August 14, 2013 at 08:20 IRAM_SIZE ist in SAM3S.h definiert: #if defined sam3s1 #define IFLASH_SIZE 0x10000 #define IFLASH_PAGE_SIZE (256) /* Internal FLASH 0 Page Size: 256 bytes */ #define IFLASH_LOCK_REGION_SIZE (16384) /* Internal FLASH 0 Lock Region Size: 16 Kbytes */ #define IFLASH_NB_OF_PAGES (256) /* Internal FLASH 0 Number of Pages: 256 */ #define IFLASH_NB_OF_LOCK_BITS (4) /* Internal FLASH 0 Number of Lock Bits: 4 */ #define IRAM_SIZE 0x4000 #elif defined sam3s2 #define IFLASH_SIZE 0x20000 #define IFLASH_PAGE_SIZE (256) /* Internal FLASH 0 Page Size: 256 bytes */ #define IFLASH_LOCK_REGION_SIZE (16384) /* Internal FLASH 0 Lock Region Size: 16 Kbytes */ #define IFLASH_NB_OF_PAGES (512) /* Internal FLASH 0 Number of Pages: 512 */ #define IFLASH_NB_OF_LOCK_BITS ( /* Internal FLASH 0 Number of Lock Bits: 8 */ #define IRAM_SIZE 0x8000 #elif defined sam3s4 #define IFLASH_SIZE 0x40000 #define IFLASH_PAGE_SIZE (256) /* Internal FLASH 0 Page Size: 256 bytes */ #define IFLASH_LOCK_REGION_SIZE (16384) /* Internal FLASH 0 Lock Region Size: 16 Kbytes */ #define IFLASH_NB_OF_PAGES (1024) /* Internal FLASH 0 Number of Pages: 1024 */ #define IFLASH_NB_OF_LOCK_BITS (16) /* Internal FLASH 0 Number of Lock Bits: 16 */ #define IRAM_SIZE 0xC000 #else #error Library does not support the specified device. #endif Fehlt da dem Debugger vielleicht irgendwie das define? Normalerweise wird der Microcontroller-Typ im Makefile mit übergeben, mit "-Dsam3s4" im Falle des Master Bricks. Du könntest zum testen einfach mal ein #ifndef sam3s4 #define sam3s4 #endif über den Block setzen. Zitieren
FloB Geschrieben August 14, 2013 at 12:11 Geschrieben August 14, 2013 at 12:11 Danke borg In dem Makefile finde ich den Eintrag nicht. Hab dann deinen Code vor den Block gesetzt, das hat das Problem aber auch nicht gelöst. Der Fehler ist nach wie vor da. Ich hatte aber noch einen anderen Fehler, warum das Debuggen nicht funktioniert hatte. Ich hatte den Master Brick im "Bootloader"-Modus gestartet. So konnte er ja nie in die main des Hauptprogrammes gelangen. Hab ihn dann normal gestartet und anschließend den ATMEL SAM-ICE. Jetzt funktioniert das Debuggen, aber der Fehler ist noch da. Danke nochmal. Zitieren
FloB Geschrieben August 19, 2013 at 14:39 Geschrieben August 19, 2013 at 14:39 Hallo, ich bins nochmal Ich hab ein neues Projekt angefangen und wollte dieses Debuggen. Ich hab die "config.h" Datei geändert und hab in der Datei "CMakeLists.txt" die Debuginformationen hinzugefügt: SET(OPTIMIZATION_LEVEL 0) SET(DEBUG "-g -ggdb") Trotzdem bekomme ich diese Fehlermeldung. No source available for "main()" Hab ich jetzt noch was vergessen? Zitieren
FloB Geschrieben August 26, 2013 at 10:20 Geschrieben August 26, 2013 at 10:20 Hi, hab das Problem jetzt selber lösen können. Für alle, die das selbe Problem haben, hier mal meine Lösung: Bei mir hat er die "alten" Daten/Verweise zum Kompilieren genommen. Ich musste in dem Eclipse Projektordner in dem Ordner "build" alle Dateien und Ordner löschen, außer "CMakeFiles". In diesem Ordner musste ich auch wieder alle Dateien und Ordner löschen, außer den Ordner, der wie die Versionsnummer von CMake heißt. Jetzt das Projekt neu kompilieren (generate_makefile.bat). In Eclipse das Projekt "cleanen" und dann das Debuggen neu beginnen. Dann hat es, bei mir zumindest, funktioniert. Ich hoffe ich konnte dem, der demnächst das Problem hat helfen. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.