Tracedaten eines Cortex-M3 selber auswerten

[Pete J. (redhead)]

Hallo zusammen,

Ich möchte versuchen die Tracedaten eines Cortex-M3 (ETM Port) selber 
auswerten.

Dabei stehen mir 2 MCB1700 Evulationbords jeweils mit Cortex-M3 
(LPC1768) mit 100Mhz getacktet zur Verfügung.

Ich entwickle meine Software auf Modellebene mit dem MDD Tool Rhapsody / 
EA.

Ich will in meinem Projekt das Verhalten eines Programmes beobachten 
ohne das Laufzeitverhalten einzuschränken. Das heist es darf kein 
instrumentierten Code verwendet werden indem ich beispielsweise Daten 
über die serielle Schnittstelle versende.  Ich greife dabei auf die Data 
and Watchpoint unit zurück, um eine Variable zu beobachten welche den 
Programmablauf nicht beeinflusst.

Die Anfallenden Daten sind dabei nicht viel, jedoch stellt das Interface 
dabei ein Problem. Die Daten werden seriell mit 100 Mhz auf einem Pin 
(SWO) ausgegeben. Als Zweite Quelle steht eine zugehörige Clock (auch 
100 Mhz) zur Verfügung. Es werden alle Schreibzugriffe auf die Variable 
mitgeloggt und bei jedem Schreibzugriff jeweils ein Paket mit 5 byte (1 
Header, 4 payload) erstellt und verschickt. Die Daten sind Manchaster 
Codiert.

Ich hab mir jetzt überlegt, auf dem einem eval board das zu testende 
Programm laufen zu lassen und mit dem anderen die anfallenden Daten 
mitzuscheiden und über USB / LAN an den PC weiterzugeben, wo sie dann 
ausgewertet werden.

Die SPI-Schnittstelle des Cortex-M3 scheidet schon einmal aus, da sie 
nur bis 12,5 Mhz arbeitet.

Ich habe mir einen Ansatz überlegt, bei dem ich die Daten durch 
Schieberegister parallelisiere, und dann ein ganzes Paket auf einmal 
Abfrage. Sind ja nur 40 bit pro Datenpaket und der Cortex hat genügend 
IO-Pins. Würde bedeuten, dass ich über einen externen Interrupt jeweils 
ein Paket auslesen kann. Wenn dann nichts zu tun ist, kann ich die Daten 
an den Host weiter verschicken.

Frage: Wenn nun 2 Pakete nacheinander kommen, habe ich grade mal 40 
Ticks Zeit zwischen 2 Interrupts. Das kommt mir zu wenig vor. Kann mir 
da jemand sagen ob das reicht um die Daten ersteinmal in einem internen 
Buffer zwischen zu speichern?

Hat sonst noch jemand eine Idee, wie man die Tracedaten in den PC / 
Cortex bekommen könnte?
Ich habe noch einen UlinkPro hier, womit ich die Tracedaten auch 
auslesen kann. Möchte aber ungerne drauf zurückgreifen, da ich gerne 
eine eigene unabhängige Lösung haben möchte.

Weiterhin möchte ich ungerne auf ein FPGA / CPLD zurück greifen, da ich 
da noch nicht ganz so viel Erfahrung gemacht habe :)

Ich hoffe ich habe das Problem einigermaßen anschaulich rüber gebracht 
:)
Danke schonmal für eure Hilfe,

Redhead

[Microman (Gast)]

Hallo Redhead,

beim Lesen deines Projektes kann mir als erstes der Gedanke einen FPGA 
zu verwenden. Ich dachte da an einen Smartfusion von Actel, der schon 
einen CortexM3 in Hardware drin hat und mit dem Du deine 
Kommunikations-Software zum PC erwickeln kannst.
Du möchtest zwar keinen FPGA, aber ich denke dieser wäre für die Aufgabe 
recht passend. Die Tools werden auch immer besser und bieten vielleicht 
schon einen sehr gute Unterstützung ohne einen FPGA schon genau kennen 
zu müssen. Vielleicht ein Lösungsansatz für dein Problem, vorrausgesetzt 
der FPGA ist mit 100MHZ Clock/Data nicht überfordert.


Gruß Microman

[Marcus H. (mharnisch)]

Du könntest den traceport im asynchronen Modus betreiben und mit dem 
Prescaler die Datenrate verringern.

--
Marcus

[Pete J. (redhead)]

Erst einmal vielen Dank für eure Antworten!
@Microman: FPGA sollte wirklich meine letzte Lösung sein, werde aber 
notfalls darauf zurückgreifen. Habe mir jetzt erst einmal von Farnell 
diese Schieberegister besorgt: SN74AHC594N

http://de.farnell.com/jsp/search/productdetail.jsp?id=1750221&Ntt=SN74AHC594N

um die Daten erst einmal zu parallelisieren. Ich hoffe dabei, dass die 
Register schnell genug sind. Dabei handelt es sich um 8 bit register, 
welche ich hintereinander schalten möchte um auf 32 bit zu kommen.

Heute kommen die Register via Post und ich werde sie direkt einmal 
austesten und posten ob es was gebracht hat oder nicht.

Weiterhin habe ich mir das Signal mal auf dem ossi angeschaut. Habe 
davon ein paar Screenshots gemacht und als Datei mit angehängt, damit 
ihr auch wisst wie das Signal / Paket aussieht :)

Es handelt sich dabei um einen Manchaster Code. Ich hoffe das macht mir 
dabei keinen Stricht durch die Rechnung, sollte aber kein Problem 
darstellen.

Interessant dabei ist, dass es scheinbar nur 50 Mhz sind und keine 100 
wie es im Datenblatt steht. Scheinbar arbeite ich da schon im asynchron 
Modus. Ich habe es mir im Datenblatt schon einmal angeschaut, kann mir 
aber leider keinen Reim draus machen bzw. alle Versuche den Takt zu 
beeinflussen sind gescheitert. Verantwortlich sind dann denk ich 
Register ITM_TCR zum setzen des Bit 4 (SWOENA) und dem Register 
TPIU_ACPR (Asynchronous Clock Prescaler Register).

@Marcus: kannst du mir sagen, welche Bits in welchen Registern ich noch 
setzen muss?

[sepp (Gast)]

>Ich habe noch einen UlinkPro hier, womit ich die Tracedaten auch
>auslesen kann. Möchte aber ungerne drauf zurückgreifen, da ich gerne
>eine eigene unabhängige Lösung haben möchte.

Warum kompliziert, wenn es auch einfach geht?

[Marcus H. (mharnisch)]

Pete Jork schrieb:
> Interessant dabei ist, dass es scheinbar nur 50 Mhz sind und keine 100
> wie es im Datenblatt steht. Scheinbar arbeite ich da schon im asynchron
> Modus.

Der Traceport arbeitet mit double data rate. Aber Du wolltest ja den SWO 
verwenden. Der hat mit TRACECLK nichts zu tun und wird nur aus Gründen 
der einfachen Implementierung zufällig aus der selben Taktquelle 
gespeist.

> @Marcus: kannst du mir sagen, welche Bits in welchen Registern ich noch
> setzen muss?

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337i/BABBIFBG.html

Gruß
Marcus