[C/C++] JTAG und SAMICE

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

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.

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

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

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.

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

Beim Debug Brick hat sich nichts geändert.

Grüße

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?

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.

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

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.

Danke für die schnelle Hilfe!

Das Auslöten des Widerstandes hat das Problem scheinbar behoben. Ich konnte jedenfalls erfolgreich die Device-Informationen auslesen.

Debuggen und Flashen aus Atmel Studio heraus funktioniert auch! Alles wunderbar

Auch wenn das für mich vermutlich nie relevant sein wird noch meine Bonusfrage:

Welche Nebenwirkungen hat das runterlöten dieses Widerstandes?

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 .

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

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.

@borg: kannst du mir von den debug configurations ein paar screenshots machen? Ich bekomm den debugger nicht richtig zum laufen.

Gruß

David

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

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.

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

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.

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.

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?

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.