Hallo,
ich wollte mal fragen ob vielleicht jemand von euch weiß ob der
Cortex-M3 auch eine Möglichkeit besitzt mit dem laufenden Core über
Serial Wire Debug Schnittstelle zu kommunizieren. Bei den alten ARM7 und
ARM9 gibt es ein Debug Communication Channel über das ich das machen
kann. Jetzt hab ich schon raus gefunden das der Cortex-M3 gar kein
Coprozessoren unterstützt und es also nicht so gehen kann wie bei den
alten. Aber wie dann, ich find einfach nix in den ganzen TRM Dokumenten.
Schonmal Danke für sachdienliche Hinweise.
Christoph
Cortex-M3 hat keinen DCC. Stattdessen gibt es für die Ausgabe vom Core
das ITM. Um Daten an den Core zu schicken kann man sich auf eine
Variable (Speicheradresse) einigen, über die der Datenaustausch
stattfindet. Siehe als Beispiel die Funktion ITM_ReceiveChar() im CMSIS.
Gruß
Marcus
Hallo,
ich hab mit das mit dem ITM angeschaut. Das ist eigentlich das was ich
brauche aber da gibt es Probleme mit meiner Hardware (und den Leuten die
diese gebaut haben ;-) und zwar brauch ich um das ITM zu nutzen den
zusätzlichen Viewer Pin SWO, dies ist aber bei mir nicht möglich. Nun
die Frage gibt es noch eine Möglichkeit mit dem Cortex-M3 im Running
Zustand zu kommunizieren ohne SWO und ohne den Core anhalten zu müssen
(Breakpoint usw.) oder gibt es das einfach nicht bei diesem Cortex-M3.
Vielen Dank für eure Hilfe
So ich habs nun selbst heraus gefunden und da ich es immer hasse wenn
ich Beiträge ohne Lösung finde, hier die Lösung.
Läuft der Cortex-M3 mit einem Userprogramm so muss man folgendes tun um
Daten auszutauschen. Diese Lösung benutzt kein Trace Port und auch kein
SWO Pin.
Auf der Debugger Seite muss man nach dem der Core gestartet wurde das
C_DEBUGEN (Bit0) im Debug Halting Control and Status Register (DHCSR)
setzen. Und danach kann man über das Debug Core Register Data Register
(DCRDR) Daten mit dem Core austauschen.
Auf der Coreseite muss man nix weiter machen, man kann das DCRDR
Register sofort beschreiben und lesen.
Aber Vorsicht, ich arbeite mich gerade in den Cortex-M3 / SWD ein und
gebe keine Garantie auf Vollständigkeit und Richtigkeit. Wäre schön wenn
sich ein Experte nochmal dazu äußern könnte. Danke.
So Wochenende gerettet, schönen Gruß
Christoph
Hört sich doch gut an. Hast Du das alles schon ausprobiert?
> und zwar brauch ich um das ITM zu nutzen den zusätzlichen Viewer Pin> SWO, dies ist aber bei mir nicht möglich.
Au weia. Hoffentlich gab es gute Gründe dafür. SWO ist ja auch für
andere Dinge äußerst nützlich.
Viel Spaß
Marcus
Hallo Marcus, Hallo Martin,
Marcus Harnisch schrieb:> Hört sich doch gut an. Hast Du das alles schon ausprobiert?
Ja hab ich schon ausprobiert, nur noch kleine Probleme mit dem
Handshake. Hab erstmal Bit31 und Bit30 des Daten Registers dafür
mißbraucht.. :-)
>> und zwar brauch ich um das ITM zu nutzen den zusätzlichen Viewer Pin>> SWO, dies ist aber bei mir nicht möglich.>> Au weia. Hoffentlich gab es gute Gründe dafür. SWO ist ja auch für> andere Dinge äußerst nützlich.
Ja das geht nicht anders ein weiters no go für die hardware ist das swo
asynchron zu tck ist, oder hab ich das falsch verstanden?
Martin Thomas schrieb:> In diesem Zusammenhang mglw. nützlich:> http://repo.or.cz/w/openocd.git/tree/master:/contrib/libdcc> (ist im Grund eine Implementierung der im Beitrag 24.09.2010 15:09> beschriebenen Vorgehensweise)
Das muss ich gleich mal anschauen, vielen dank.
Christoph Loohß schrieb:> Ja das geht nicht anders ein weiters no go für die hardware ist das swo> asynchron zu tck ist, oder hab ich das falsch verstanden?
Wessen HW? Des Debug Adapters oder Deines Boards? Warum? Erzähl doch
mal über Dein System. Warum sind das alles so harte Einschränkungen?
SWV ist ein serielles interface, dessen Arbeitstakt sowohl intern
(asynchron zu TCK) als auch extern erzeugt werden kann, soweit
letzteres in einem µC implementiert wurde.
Wegen Deiner Lösung mit dem DCRDR: Je nachdem wieviel Kontrolle Du
über das System hast, kann es passieren (eigene Erfahrung), dass die
manuelle Nutzung der Debug Resourcen sich mit der Nutzung durch das
Debug Tool überschneidet.
Gruß
Marcus
Hallo Marcus,
Marcus Harnisch schrieb:> Wessen HW? Des Debug Adapters oder Deines Boards? Warum? Erzähl doch> mal über Dein System. Warum sind das alles so harte Einschränkungen?
Die Hardware ist ein Boundary Scan System der Firma GÖPEL electronic und
wir nutzen die Debugschnittstellen der diversen Prozessoren um diese
trotz fehlendem Boundary Scan mit in den Test zu integrieren.
(Verbindungstests, Firmware programmiern, Funktionstests)
> Wegen Deiner Lösung mit dem DCRDR: Je nachdem wieviel Kontrolle Du> über das System hast, kann es passieren (eigene Erfahrung), dass die> manuelle Nutzung der Debug Resourcen sich mit der Nutzung durch das> Debug Tool überschneidet.
Da kein Debug Tool da ist und ich die Schnittstelle für mich alleine
habe sollte das kein Problem sein.
Grüße,
Christoph
Hallo nochmal,
irgendwie kann man den Text nicht nochmal bearbeiten.. dann halt noch
nen Nachtrag.
Diese Einschränkungen sind nur wegen der frühen Entwicklungsphase.
Später soll das System auch alle Funktionen des jeweiligen Interfaces
(JTAG (schon vorhanden), BDM, SWD, usw.) können. Aber man muss ein
Interface erstmal kennen um zu sagen was es braucht. Ich finde es auch
besser wenn man nur wenig Daten (Statuswerte) überträgt, das die Lösung
nur mit SWDIO und SCK auskommt. Ein Nadel weniger im Testadapter :-)
Christoph Loohß schrieb:> Die Hardware ist ein Boundary Scan System der Firma GÖPEL electronic und> wir nutzen die Debugschnittstellen der diversen Prozessoren um diese> trotz fehlendem Boundary Scan mit in den Test zu integrieren.
Das erklärt natürlich einiges. Die meisten Daten sollten sich doch über
direkten Speicherzugriff austauschen lassen, oder?
Viel Erfolg
Marcus
> Das erklärt natürlich einiges. Die meisten Daten sollten sich doch über> direkten Speicherzugriff austauschen lassen, oder?
Ja, so gehts einfach am schnellsten, einfach adresse und increment bit
setzen und danach die daten. Danke für die Tips, ist so fast fertig nur
noch ein wenig optimieren.
Grüße,
Christoph
