Forum: Mikrocontroller und Digitale Elektronik STM32 und jlink - Daten von STM32 auslesen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ui (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

kurz zu meinen Anwendungsfall: Ich habe einen STM32F4 und daran eine SD 
Karte über SPI verbunden. Als Zugriff für das Dateisystem kommt ein 
FatFS zum Einsatz. Als Debugger nehme ich den Jlink her.
Jetzt zu meiner Frage:
Ich speichere auf der SD Karte Daten ab und möchte diese gern (ohne die 
SD Karte entnehmen zu müssen) auslesen. Ich würde die Daten gerne über 
den Jlink auslesen. Es wäre kein Problem wenn ich ein extra Programm 
dafür auf den STM32 flashen müsste, schön wäre aber auf PC seite (Linux) 
so eine Art Dateibrowser.

Wer hat Ideen? Gibt es vielleicht bereits ähnliche Projekte oder Ideen? 
Hat sowas schonmal jemand umgesetzt?

: Gesperrt durch Moderator
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Irgendwie geht das sicher.
Im ST Link Utility gibt es eine Einstellung External Loader.
Damit ist der Zugriff auf externe Speicherbausteine möglich.

Ich denke damit wird ein kleines Programm in den STM32 Ram geladen und 
ausgeführt.

Gibt auch bestimmt eine AppNote dazu.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Im ST Link Utility gibt es eine Einstellung External Loader.
> Damit ist der Zugriff auf externe Speicherbausteine möglich.

Jaaaaaaa, aber: Das ist für SPI Flash. Zwar kann man SD-Karten auch über 
SPI ansprechen, aber das ist nur das "Low-Level" Interface. SD-Karten 
brauchen halt noch ein wenig "oben drauf". Und dann nochmal das 
Dateisystem drüber.

Letzteres könnte man sich natürlich sparen, wenn man auf PC Seite ein
Filesystem in einer Datei (unter Linux mit 'nem loop-dev.) anlegt und 
dann nur noch die einzelnen Sektoren hin und her kopiert.

Das kopieren einzelner Sektoren von SD-Karte ins RAM des F4 und zurück 
ist sicher noch mit überschaubarem Aufwand über ein kleines Programm, 
dass vom Debugger in RAM geschrieben wird, möglich. Müsste man aber halt 
schreiben.

Ob sich das lohnt, hängt auch von der Größe der Speicherkarte ab. 
Wieviele kByte/s bekommt man über die Leitung (des Debuggers)? Wenn man 
darüber ein paar GByte kopieren will, kommt da keine rechte Freude auf 
...

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
ui schrieb:
> Als Debugger nehme ich den Jlink her.

Dann schau Dir mal Segger RTT an. Der Zugriff mit eigenem Programm ist 
via TCP/IP möglich, Terminal 0 liegt auf Port 19021.

Dateizugriffe könnte man über (X,Y,Z)Modem via Telnet Client (z.B. 
TeraTerm Pro) lösen.

von ui (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Dann schau Dir mal Segger RTT an. Der Zugriff mit eigenem Programm ist
> via TCP/IP möglich, Terminal 0 liegt auf Port 19021.
>
> Dateizugriffe könnte man über (X,Y,Z)Modem via Telnet Client (z.B.
> TeraTerm Pro) lösen.

Danke für den Hinweis, das schaut doch recht interessant und hilfreich 
aus.
Da ich eh ein Betriebssystem habe wäre das quasi eine Möglichkeit:

1) Task anlegen der nicht aktiv wird bis man anfängt irgendein 
Steuerzeichen zum starten zu senden
2) Nur der Task wird aktiv, die restliche Software schläft implizit.
3) Einen kleines Protokoll einbauen, sowas wie "ls" und "cd"
4) Das Unterprogramm auf dem STM gibt Antworten als characters raus
5) Auch Daten können so geladen werden, muss man halt zweimal parsen 
(auf dem STM und am PC)
6) Wenn man die Verbindung löst legt sich der Task wieder schlafen und 
macht seine normalen Dinge.

Hört sich doch nach nem Plan an.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ui schrieb:
> Ich speichere auf der SD Karte Daten ab und möchte diese gern (ohne die
> SD Karte entnehmen zu müssen) auslesen. Ich würde die Daten gerne über
> den Jlink auslesen.

Wieso kommst du bloß auf so eine absonderliche Idee? Weil der Jlink grad 
so bei dir herumliegt? Der ist für so einen Einsatzfall absolut NICHT 
erdacht worden.

Also: bringe deiner Firmware im µC ein USB-CDC bei (Beispiel dafür gibt 
es hier ja genug), dann bringe deiner Firmware ein kleines 
Kommandoprogramm bei und implementiere dort irgend eine Art, deine Datei 
auf der SD-karte anzuzeigen oder per UU zum PC zu schicken. So 
(ungefähr) macht man das. Auf dem PC kannst du dann dein 
Lieblings-Terminalprogramm benutzen - welches, ist relativ egal, es muß 
nur in der Lage sein, den Traffic in irgendeine Datei zu loggen.

W.S.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Also: bringe deiner Firmware im µC ein USB-CDC bei
Also wenn schon mit richtigem USB, dann kann man doch gleich MSC 
implementieren, oder einfach einen SD-Karten-Leser. Dann kann man direkt 
per Windows Explorer zugreifen...
PS: Ist nicht der Hauptgrund für die Nutzung von SD-Karten, dass man die 
einfach herausnehmen und in den PC stecken kann...?

von ui (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem daran: Ich will die Kommunikation über den JLink USB-Port 
machen, ohne Dinge an der Hardware ändern zu müssen.
Gibts denn bessere Vorschläge?

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist, ob das irgendeinen Sinn macht. SD-Karten nimmt man, 
wenn's um ein großes Datenvolumen geht (bis mehrere GByte).

Und so etwas bekommt man nicht in erträglicher Zeit über USB-FS (12 
MBit/s physikalisch). Selbst mit einem SD-Kartenleser am PC, der nur 
USB-FS kann, wird heutzutage niemand mehr so richtig glücklich.

Und JLink mit SWD oder JTAG knabbert davon noch krätig was ab. Mein 
JLink (naja, etwas älter) mag's nur bis 4 MHz SWD Takt (allerdings nicht 
nachgemessen ...).
Noch etwas Protokoll-Overhead abgezogen und schon ist man bei sehr 
optimistisch max. vielleicht 300 kByte/s. Verzeichnisse browsen ok, aber 
Dateitransfer??? Ein paar kBytes gut, aber spätestens bei MBytes ist 
Schluss.

Via USB-HS als Mass-Storage-Device wär natürlich eine Alternative, da 
braucht's auf PC-Seite nicht einmal extra Software. Auf Controllerseite 
sollten sich in den Beispielen von ST etwas dazu finden lassen.
Aber ohne externen USB-HS-Phy geht's dann nicht (außer STM32F723, der 
hat einen an Bord).

Wenn es um ein kleineres Datenvolumen gehen sollte (leider gab's dazu 
keine Info außer "Ich würde die Daten gerne über den Jlink auslesen"), 
würde man eher einen SPI-Flash nehmen, z. Z. so etwa bis 64 MByte 
bezahlbar.
Aber die Problematik mit dem gemächlichen Transfer bleibt natürlich, man 
erspart sich zumindest die SD-Schicht ...

Deshalb: Erst genau über die Anforderungen, dann über die möglichen 
Optionen zur Realisierung nachdenken!

Da SD-Handling und Filesystem ja offenbar schon "stehen" geht's doch 
offenbar nur noch um den Transport. Via JLink m. E. einfach 
unrealistisch bei größerem Dateiumfang ...

von ui (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> Da SD-Handling und Filesystem ja offenbar schon "stehen" geht's doch
> offenbar nur noch um den Transport. Via JLink m. E. einfach
> unrealistisch bei größerem Dateiumfang ...

Zum Datenumfang:
Es wird sich um einzelne *.txt Dateien handeln. Das größte der Gefühle 
werden wohl vielleicht mal kleiner Bilder (max. ca. 300kB) sein.
Es wird sich eigentlisch ausschließlich um log Dateien und/oder 
Kalibrierungsdaten handeln, nicht mehr.
Der SD-Karten Anschluss ist zwar verfügbar, warum ich das gerne 
vermeiden wollen würde:
Es handelt sich um ein Projekt bei dem Schüler/Studenten bisserl 
programmieren lernen sollen. Nicht alle unsere PCs haben SD-Karten 
anschluss, sodass es dann einfach frickelig und nicht schön handhabbar 
ist. Deswegen die Idee das über den Debug USB zu handhaben. Es ist auch 
kein Problem wenn das mal 1-2 Minuten dauert.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn's was fertiges sein soll, fällt mir außer dem RTT auch nichts ein. 
Etwas ähnliches selber machen, sollte allerdings auch nicht schwer sein:
Zwei Software-FIFOs, die Zugriffssteuerung geht implizit über die 
Schreib-/Lesezeiger (automatisch atomar), über den Debug-Adapter hat man 
ja transparent Zugriff aufs RAM des Controllers, ohne dem in die Quere 
zu kommen. Das ist auch der übliche Weg, wie man z. B. das Flash übers 
Debug-Interface programmiert. Zum Nachlesen: In openocd gibt's 
"target_run_flash_async_algorithm", das genau (die Host-Seite) von so 
einem FIFO implementiert. Zwar nur Host->Target, aber das ganze kann man 
natürlich auch gleichzeitig in beide Richtungen machen.

Einziges potenzielles Problem: Wenn ohnehin schon größere Applikation, 
dann noch die RTT-Lib und X-/Y-/Z-Modem, könnte es je nach Flash-Größe 
eng werden. Und ständig "umflashen", nur um auf die SD-Karte zugreifen 
zu können, ist ja auch nicht so toll.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
ui schrieb:
> Es handelt sich um ein Projekt bei dem Schüler/Studenten bisserl
> programmieren lernen sollen.

MAL EIN BISSEL HERUMPROGRAMMIEREN?

Und da denkst du dir etwas derart ungewöhnliches aus, siehst dich selber 
obendrein außerstande, es selbst zu realisieren - und willst damit 
Pädagogik betreiben?

Also mein Lieber, denke dir besser etwas wirklich pädagogisch sinnvolles 
aus, als da wäre:
- planvolles Herangehen an ein Gerätekonzept mit einem Mikrocontroller
- sinnvolle Konzepte für low-level Treiber im Controller, angefangen 
beim simplen UART-In und -Out mit Zwischenpuffern und Entkopplung von 
Zugriffen und tatsächlichem Datenverkehr auf dem Übertragungsweg - bis 
hin zu selbigem, aber intern eben paketeweise per USB. Ein Gleiches dann 
auch für Dinge wie graqfische Displays, also Displaytreiber zur Hardware 
hin und GDI zu den Anwendungen hin. Und und und.. Sinn des Ganzen ist 
es, zu lernen, in der Firmware mit einer Art Schichtenmodell zu 
arbeiten, also die Algorithmen und die Ablaufgestaltung und die 
Lowlevel-Dienste voneinander zu trennen, damit nicht alles wie Kraut und 
Rüben durcheinander geht.

Ich unterstelle mal, daß du den Schülern/Studenten tatsächlich Wissen 
und Können BEIBRINGEN willst - und dazu solltest du wenigstens etwas 
Ahnung nicht nur haben, sondern auch weitergeben können.

Ich habe vor Jahren die "Lernbetty" für derartige Zwecke konzipiert und 
zusammen mit einigen (wenigen) anderen ist damals auch etwas draus 
geworden. Also versuche du mal, dein Thema, was du dir so vorgestellt 
hast, zu allererst in so ein (ähnliches) Dokument zu fassen. Jaja, für 
ein klares Konzept sollte man es möglichst frühzeitig in ein 
einigermaßen förmliches Dokument fassen, das sich lesen und diskutieren 
läßt. Zumeist merkt man beim Verfassen recht bald selber, wo man noch 
schwammig gedacht hat und hat dann Gelegenkeit, sich selber zu 
konkretisieren. Bei mir hat sich diese Verfahrensweise seit vielen 
langen Jahren als Geräteentwickler sehr bewährt, denn sie hält einen 
davon ab, in unausgegorene Spinnereien zu verfallen.

W.S.

von ui (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
W.S. schrieb:
> MAL EIN BISSEL HERUMPROGRAMMIEREN?
>
> Und da denkst du dir etwas derart ungewöhnliches aus, siehst dich selber
> obendrein außerstande, es selbst zu realisieren - und willst damit
> Pädagogik betreiben?
>
> Also mein Lieber, denke dir besser etwas wirklich pädagogisch sinnvolles
> aus, als da wäre:
> - planvolles Herangehen an ein Gerätekonzept mit einem Mikrocontroller
> - sinnvolle Konzepte für low-level Treiber im Controller, angefangen
> beim simplen UART-In und -Out mit Zwischenpuffern und Entkopplung von ...
> läßt. Zumeist merkt man beim Verfassen recht bald selber, wo man noch
> schwammig gedacht hat und hat dann Gelegenkeit, sich selber zu
> konkretisieren. Bei mir hat sich diese Verfahrensweise seit vielen
> langen Jahren als Geräteentwickler sehr bewährt, denn sie hält einen
> davon ab, in unausgegorene Spinnereien zu verfallen.
>
> W.S.

Vielleicht war es von mir etwas salopp ausgedrückt, aber schon (wie so 
oft) landen wir hier im forum bei Besserwisserei. Ja ich weiß, ich habe 
wenig über mein Projekt geschrieben, aber ich glaube ich konnte sehr 
klar in Worte fassen was das Problem ist und was ich gerne hätte. Es 
kamen auch ein paar gute Vorschläge, und jetzt kommst du und meinst 
alles besser zu wissen.

Das Projekt ist schon ziemlich weit fortgeschritten, es geht auch gar 
nicht darum das Schüler die Welt der low-level Treiber kennenlernen. 
Macht manchmal Sinn, oft auch nicht. Also: leck mich.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
ui schrieb:
> Also: leck mich.

Derartige Umgangsformen brauchen wir hier nicht.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.