SAM4S2A geht nicht zu main()-Breakpoint

Also wenn dein Code läuft, dann sind die GPNVM Bits richtig eingestellt. Das du keine Breakpoints setzen kannst, wird dann wohl ein anderes Problem sein.

GPNVM2 existiert beim SAM4S2 nicht, siehe S.45 oben im Datenblatt.

GPNVM0 ist das Security Bit, das willst du jetzt nicht setzen, sonst kannst du weder auf den µC schreiben noch lesen. Dann bleibt nur ein Erase mit dem Pin.

GPNVM1 sorgt dafür das entweder aus dem Flash gebootet wird oder der SAM-BA aus dem ROM. Steht so auch im DB, S.44.

Alex schrieb:

Was/wo ist das "EEFC User Interface"?

Das sind Register über die man den Flash "steuern" kann oder halt die GPNVM Bits.

Enhanced Embedded Flash Controller (EEFC), S.352. Befehle für das EEFC, S.372. Wie man es verwendet musst du dir im entsprechenden Abschnitt selber mal durchlesen.

Welches Interface nutzt du mit dem ICE3: JTAG?

Also ich nutze den Atmel-ICE

(https://www.microchip.com/en-us/development-tool/atatmel-ice)

mit der SAM4E Serie und habe keine Probleme.

Hast du evtl. im Debug Mode noch die Optimierung aktiv? Siehe Bild.

Project -> Properities -> Toolchain -> ARM/GNU C Compiler -> Optimization: None (-O0)

Danke für deine Antwort.

Adam P. schrieb:

Welches Interface nutzt du mit dem ICE3: JTAG? GPNVM1 sorgt dafür das entweder aus dem Flash gebootet wird oder der SAM-BA aus dem ROM. Steht so auch im DB, S.44.

Ich vermute halt, dass in main() keine Breakpoints möglich sind, kommt daher, dass die Routine die läuft, im ROM steht. Es wird da kein Quellcode angezeigt. Im Device Programming Tool ist nur GPNVM angegeben mit einem Hex-Eingabefeld. Welchen Wert muss ich da schreiben? 0x02 müsste doch dem GPNVM1 = 1 entsprechen?

Alex schrieb:

Welchen Wert muss ich da schreiben? 0x02 müsste doch dem GPNVM1 = 1 entsprechen?

Das lässt du so wie es ist auf 0x02.

Alex schrieb:

Ich vermute halt, dass in main() keine Breakpoints möglich sind, kommt daher, dass die Routine die läuft, im ROM steht.

Da versteh ich nicht was du mir damit sagen möchtest. Im ROM liegt der SAM-BA, der aber bei GPNVM = 0x02 NICHT ausgeführt wird. Somit kannst du das ROM mal voll vernachlässigen.

@ Adam P. Ja, es war -Os eingestellt. Aber auch ohne Optimierung sind Breakpoints in main() ungültig.

Alex schrieb:

Ja, es war -Os eingestellt.

Ich meine aber -O0 und nicht -Os.

Dann setz doch eben mal kurz ein mini Projekt auf und flash das auf den µC und mach dir paar Breakpoints um zu testen.

Alex schrieb:

Aber auch ohne Optimierung sind Breakpoints in main() ungültig.

Sie sind nicht "ungültig". Sie werden nur nicht erreicht.

Lass die Optimierung ruhig an, sonst debuggst du was völlig anderes.

Es wird dir nichts anderes übrig bleiben als zu verstehen, was vor main() alles passiert und warum er in dieser Schleife hängt. Letztlich hast du auch den Sourcecode dafür irgendwo da liegen, der wird zu deinem Projekt gehören. Bei Atmel ist der Startup-Code sogar in C.

Adam P. schrieb:

Im ROM liegt der SAM-BA, der aber bei GPNVM = 0x02 NICHT ausgeführt

wird. Wenn ich den Wert 0x02 schreiben will, kommt aber der ganz zuerst beschriebene Fehler "One or more registers differs". Das bedeutet doch dass er zwar schreibt, aber das nicht klappt? Deshalb vermute ich die ROM-Routine.

[Mod: Zitat korrigiert]

Hast du denn auch Debug eingestellt? Im Release siehst du nämlich wirklich nur das Disassembly und kannst keine Breakpoints setzen.

Also, woran könnte es liegen, dass der Wert 0x02 nicht richtig geschrieben wird? Ich habe doch mit Erase früher schonmal alle Fuses gelöscht?

Alex schrieb:

Danke für deine Antwort.

Bitte benutze die Zitatfunktion des Forum wie vorgesehen: den zu zitierenden Text markieren und dann auf den Link "Markierten Text zitieren" drücken.

Denn deine eigene Art zu zitieren sieht für Mobilnutzer verwirrend aus.

Alex schrieb:

Also, woran könnte es liegen, dass der Wert 0x02 nicht richtig geschrieben wird?

Irrelevant, du bootest offenbar vom Flash, wenn du im Bereich 0x800... landest.

Konzentrier dich auf das eigentliche Problem und lass die GPNVM-Bits in Ruhe.

Adam P. schrieb:

Im Release siehst du nämlich wirklich nur das Disassembly und kannst keine Breakpoints setzen.

Eiderdaus! das wusste ich nicht. Ja habe tatsächlich die Release eingestellt. Bei der Solution Configuration gibt es für Debug die richtige FW-Version gar nicht! Probiere einfach mal die ähnlichste...

Ok, ein kleines Stückchen weiter. Jetzt akzeptiert er die Breakpoints, erreicht sie aber nicht. Wie kann ich nachforschen, wo er im Startup-Code hängt?

Alex schrieb:

Jetzt akzeptiert er die Breakpoints, erreicht sie aber nicht.

Wie hast es denn nun eingestellt? Evtl. reicht es wenn du in deiner Release Konfiguration die Einstellung für Debug Level von "None" auf "Maximum (-g3)" setzt. Dann müsstest du nicht eine neue Konfig. erzeugen.

Alex schrieb:

Wie kann ich nachforschen, wo er im Startup-Code hängt?

Such in deinem Projekt evtl. nach dem

1

void Reset_Handler(void)

und setz da ein Breakpoint und starte dann die Debug-Sitzung.

Also ich verwende die Debug-Konfiguration mit -O3 Einstellung. Breakpoint auf/ innerhalb "void Reset_Handler(void)" wird auch nicht erreicht!

Alex schrieb:

Also ich verwende die Debug-Konfiguration mit -O3 Einstellung. Breakpoint auf/ innerhalb "void Reset_Handler(void)" wird auch nicht erreicht!

Also ich habe bei mir Debug -g3 mit Optimierung -O3 probiert und kann Breakpoints setzen.

Dann gehe jetzt mal her und erstell dir wirklich mal ein neues kleines Projekt um das mal zu testen. Ist wohl das einfachste um Grundsätzlich mal zu schauen ob es evtl. am Projekt liegt oder an deinem ICE.

-O3 ist aber wenig sinnvoll fürs Debugging. Das entrollt massig Schleifen und verursacht vergleichsweise großen (aber schnellen) Code.

Nimm -Os.

Und debugge ab dem Reset-Vektor. Alles Diskutieren hier wird dich kein Stück weiter bringen.

Adam P. schrieb:

Ist wohl das einfachste um Grundsätzlich mal zu schauen ob es evtl. am Projekt liegt oder an deinem ICE.

OK, werde ich machen. Melde mich dann. Aber seit ihr euch ganz sicher, dass ich GPNVM nicht setzen muss?

Alex schrieb:

Aber seit ihr euch ganz sicher, dass ich GPNVM nicht setzen muss?

Ja es sollte auf 0x02 gesetzt sein, sonst bootet er immer aus dem ROM wenn du 0x00 eingestellt hast. Dann wird dein Code nicht erreicht.

Also ich habe ein neues Projekt erstellt. Breakpoints auf main() und void Reset_Handler(void) und void SystemInit( void ). Keiner der Breakpoints wird erreicht. Also ich würde vermuten, dass doch GPNVM gesetzt werden müsste?

Kannst du denn nicht einfach mal ab Reset single steps machen. Dann weißt du, in welchem Adressbereich du herum wuselst.

Jörg W. schrieb:

Kannst du denn nicht einfach mal ab Reset single steps machen. Dann weißt du, in welchem Adressbereich du herum wuselst

Ok ich mache "Start Debugging and Break". Da bleibt er aber auf Status "Running". Wenn ich auf || "Break All" gehe, ist er an Adresse 00800E6A. Und grob in diesem Bereich hängt er dann in einer Endlosschleife. Im Disassembly Fenster wird kein Quelltext angezeigt nur die Assembler-Anweisungen.

Ist dein GPNVM Bit nun gesetzt? Es muss 0x02 sein, sonst bootet er nicht vom Flash.

Alex schrieb:

ist er an Adresse 00800E6A

Ich habe mir das Datenblatt nochmal angesehen und korrigiere mich: ja, diese Adresse liegt im ROM.

Ja, dann musst du sehen, wie du GPNVM1 gesetzt bekommst. Ich würde dafür OpenOCD benutzen, wie das in deiner IDE genau geht, weiß ich leider nicht.

Adam P. schrieb:

Ist dein GPNVM Bit nun gesetzt?

Nein. Weil im Device Programming das Programmieren des Wertes 0x02 einen Fehler bringt - "One or more registers differs". Wenn ich danach lese, steht der Wert wieder auf 0x00. Das ist das Problem.

Öffne cmd und navigier in dein Atmel Install Verzeichnis:

"C:\Program Files (x86)\Atmel\Studio\7.0\atbackend"

Dort kannst du mal versuchen "atprogram" per hand aufzurufen um das bit zu setzen:

"atsam4e16e" musst du noch durch deinen ersetzen.

1

atprogram -t atmelice -i jtag -d atsam4e16e write -fs -o 0 -v --values 02

Sollte dann wie im Bild zu sehen sein.

Also euch allen für eure Hilfe schon mal vielen Dank! im CMD-Fenster: C:\Program Files (x86)\Atmel\Studio\7.0\atbackend>atprogram -t atmelice -i jtag -d atsam4s2A write -fs -o 0 -v --values 02 [ERROR] Failed to connect. Error=0x1001. (TCF Error code: 131103)

Was mich schon gewundert hat, die NRST-Leitung des Prozessors ist auf der Platine gar nicht angeschlossen, geht also nicht zum ICE3... Aber die Platinen sind getestet und da braucht es ja die Firmware drauf. Nur ist da das Secutity gesetzt und ich muss mit ERASE-Pin vorher löschen.

Benutzt du denn auch JTAG oder SWD?

Alex schrieb:

Was mich schon gewundert hat, die NRST-Leitung des Prozessors ist auf der Platine gar nicht angeschlossen, geht also nicht zum ICE3

Muss auch nicht, Reset lässt sich normalerweise auch via JTAG oder SWD auslösen.

Klar, wenn das Security Bit gesetzt ist, musst du ein Erase durchführen, sonst klappt das nicht mit dem Connect bzw. mit Zugriff auf den Controller.

@ Jörg W. Ja, JTAG

@ Adam P. Ja, Erase habe ich schon oft probiert. Nützt nix. Im Device Programming Tool versuche ich zuerst die Device signature auszulesen um damit die Verbindung zu testen. Wenn das geht, weiß ich, dass kein Security gesetzt ist.

Alex schrieb:

@ Adam P. Ja, Erase habe ich schon oft probiert. Nützt nix. Im Device Programming Tool versuche ich zuerst die Device signature auszulesen um damit die Verbindung zu testen. Wenn das geht, weiß ich, dass kein Security gesetzt ist.

Ok gut... und kannst du dann die Firmware flashen? Oder kommt da auch ein Fehler?

Adam P. schrieb:

und kannst du dann die Firmware flashen? Oder kommt da auch ein Fehler?

Wenn ich (Device: Erase Chip) auf Memories Program xyz.elf drücke, kommt da nach einiger Zeit (Fortschrittsbalken fast am Ende) auch ein Fehler: "Verifying Flash...Failed! address=0x400000 expected=0xc0 actual=0xff" Wenn ich aber im Studio auf "Start debugging" drücke, wird das Programm ohne Fehler aufgespielt...

Zur Info: Ich habe jetzt Feierabend. Aber morgen früh schaue ich natürlich erwartungsvoll wieder rein ;-) ....

Alex schrieb:

address=0x400000 expected=0xc0 actual=0xff

Das bedeutet, dass da nichts programmiert worden ist (0xff = Löschmuster).

Das könnte natürlich auch gut ein Grund sein dafür, dass er in den ROM-Bootloader springt, denn die illegale Vektortabelle ist leicht zu erkennen.

Chip kaputt?

Jörg W. schrieb:

Chip kaputt?

Ja das habe ich mir auch schon gedacht.

Was ich auch ab & zu hatte:

• Falsche JTAG Clock könnte das auch verursachen
• Wackelkontakt in den JTAG Leitungen zwischen (ICE <-> Controller)

Oder ist evtl. an den Datenleitungen irgendeine Peripherie angeschlossen, die man erst per jumper oder sonstiges abkoppeln muss?

P.S. Wer ist denn mal wieder die Witzfigur hier, die alles mit -1 bewertet? Du musst ja ein ganz schlauer sein...katastrophe.

Adam P. schrieb:

Was ich auch ab & zu hatte:

• Falsche JTAG Clock könnte das auch verursachen

Naja, JTAG wird normalerweise mit einem eigenen Takt betrieben, solange du den nicht völlig überziehst, muss zumindest eine Verbindung gehen. (Stärkere Restriktionen kann es ggf. beim Debuggen geben.)

• Wackelkontakt in den JTAG Leitungen zwischen (ICE <-> Controller)

Dafür sind die 10-Pin-Kabel des AtmelICE leider recht anfällig. Die dünne Litze hat nur wenige Drähte, und wenn man zu viel Kraft beim Ziehen der Stecker anwendet, reißt da schnell mal was ab.

Oder ist evtl. an den Datenleitungen irgendeine Peripherie angeschlossen, die man erst per jumper oder sonstiges abkoppeln muss?

Normalerweise macht man sowas nicht, aber das müsste dir der Schaltplan des uns unbekannten Geräts verraten.

P.S. Wer ist denn mal wieder die Witzfigur hier, die alles mit -1 bewertet?

Irgendjemand gefällt sich darin, dass er es geschafft hat, einen Bot zu zimmern, der sowas querbeet macht. Wenn man halt mit seiner Energie sonst nichts anfangen kann, kann man sich an so einem Quatsch sicher erfreuen.

Jörg W. schrieb:

Was ich auch ab & zu hatte:

• Falsche JTAG Clock könnte das auch verursachen

Naja, JTAG wird normalerweise mit einem eigenen Takt betrieben, solange du den nicht völlig überziehst, muss zumindest eine Verbindung gehen.

Ja, aber manchmal war echt der Wurm drin.

Jörg W. schrieb:

• Wackelkontakt in den JTAG Leitungen zwischen (ICE <-> Controller)

Dafür sind die 10-Pin-Kabel des AtmelICE leider recht anfällig.

Ja aber auch mit anderen Adaptern vom Segger ICE auf 10Pin JTAG mit Litzen, irgendwann sind sie durch.

Jörg W. schrieb:

Wenn man halt mit seiner Energie sonst nichts anfangen kann

Tja, Leute gibts...anstatt mal ein kreativen Beitrag zu leisten. Aber hey, nicht wir werden dumm sterben :-D

Adam P. schrieb:

Oder ist evtl. an den Datenleitungen irgendeine Peripherie angeschlossen, die man erst per jumper oder sonstiges abkoppeln muss?

An allen 4 Leitungen sind 10k gegen Ground - also SWCLK, SWDIO, SWO, TDI. Das sollte kein Problem sein, denn andere, gleiche Platinen lassen sich ja mit dem Serienprogrammierer beschreiben. Habe jetzt auch die 1,2V VDDCORE geprüft - sind in Ordnung. Der Programmierstecker auf der Platine ist problematisch. Werde jetzt einzelne JTAG-Leitungen direkt anlöten, eine 10pol-Wannenstiftleiste dran machen und mein funktionierendes Standardkabel verwenden. Was ich mich halt frage ist, wenn ich die Device ID auslesen kann, müsste doch die Verbindung zum Debugger OK sein? Mit einem Erase lösche ich doch auch alle Fuses auf ihren Standardwert? PS: Ich habe auch schon den JTAG-Clock auf 100kHz herabgesetzt. Bringt nichts.

Alex schrieb:

Was ich mich halt frage ist, wenn ich die Device ID auslesen kann, müsste doch die Verbindung zum Debugger OK sein?

Würde ich so nicht unterschreiben. Ja sollte, eigentlich.

Aber nicht nur 1x hatte ich das gleiche Problem, dass er mitten im Schreibvorgang abgebrochen hat.

Ja die Widerstände sollten OK sein.

Also entweder hat der Controller ein Fehler (defekt) oder deine Verbindung ist "wackelig". (viele Möglichkeiten bleiben da nicht mehr)

Alex schrieb:

SWCLK, SWDIO, SWO, TDI.

Ähm, also irgendwie passt das nicht.

Du sagtest du verwendest JTAG. Bis auf das TDI ist es aber SWD.

JTAG hätte folgende Pins: TDI, TMS, TCK, TDO

Irgendwas ist da durcheinander.

Adam P. schrieb:

Irgendwas ist da durcheinander

Äh, ja. Ich habe bisher JTAG nicht benutzt, deshalb bin ich da nicht firm drin. Danke für den Hinweis wie die benutzten JTAG-Leitungen heißen - TDI, TMS, TCK, TDO. TMS -> (SWDIO),TDO->(SWO), etc. Den Knoten verursachenden Horror finde ich die falsche Belegung der Debugger-Buchse, deren Pinnummern nicht den Standard-Wannenleisten entsprechen. Zum Glück gibt es im Inet gute Bilder dazu.

Alex schrieb:

Den Knoten verursachenden Horror finde ich die falsche Belegung der Debugger-Buchse, deren Pinnummern nicht den Standard-Wannenleisten entsprechen.

Pah.

Eigentlich gibt es bei Cortex-M zwei Belegungen (alt, 20polig, 2,54 mm Raster und neu, 10polig, 1,27 mm Raster), aber noch was anderes als das sollte man nicht erfinden.

Prinzipiell stimme ich dir zu, dass das Auslesen der Signatur ausreichen Beweis für die Verbindung zum JTAG sein müsste, aber irgendwas ist halt foul.

Du könntest natürlich noch einen Logicanalysator bemühen und schauen, was da auf dem JTAG passiert, wenn du das GPNVM1 setzen willst.

Jörg W. schrieb:

Du könntest natürlich noch einen Logicanalysator bemühen und schauen, was da auf dem JTAG passiert, wenn du das GPNVM1 setzen willst

Uff, von diesem Protokoll habe ich keinerlei Ahnung. Ich habe das hauseigene Debug-Kabel geprüft. Das ist in Ordnung.

Habe mittlerweile eine neuere Platine mit höherer Version bekommen und da funktioniert das GPNVM und das Programm flashen.

Die einzige Möglichkeit, die ich noch sehe ist, dass tatsächlich der SAM eine Macke hat. Muss also ausschließlich den Flash betreffen. Tja, Sachen gibt's.

Jedenfalls bedanke ich mich nochmal bei euch für eure geduldige Unterstützung und schließe meine Anfrage damit ab. Schönen Tag noch.

Alex schrieb:

Die einzige Möglichkeit, die ich noch sehe ist, dass tatsächlich der SAM eine Macke hat.

Das nächste mal, teste direkt erstmal eine andere Platine ;)

Aber ich hatte auch schon SAM Controller die irgendwann einfach nicht mehr zu flashen waren.

Somit viel Spaß noch.