Wie STM32F4 update über SD-Karte machen?

[Peter (Gast)]

Hallo.

Ich bin am bauen von einem Projekt bei dem ein STM32F4XX über eine 
angeschlossende SD-Karte ein Update machen soll.

Es soll halt über die SD Karte gemacht werden weil sie sowieso immer am 
System dran ist für eine Datenerfassung. Die Karte wir zur Auswertung 
raus genommen und wäre somit der ideale Träger für das Update.

Eine Verschlüsselung der Datei wäre auch noch super.

Kennt jemand ein Projekt/Code wo das schon mal umgesetzt wurde?

Viele Grüße, Peter

[W.S. (Gast)]

Peter schrieb:
> Kennt jemand ein Projekt/Code wo das schon mal umgesetzt wurde?

Na klar, hab ich selber schon gemacht....ABER: (Sender Eriwan) es war 
kein ARM Cortex, sondern ein FR2 und es war auch keine SD-Karte, sondern 
via USB.

Also im Klartext: Du mußt dir schon selbst ein System ausdenken.

Soweit ich weiß, gibt es in keinem µC einen Bootlader, der eine Datei 
auf einer SD-Karte frißt. Also mußt du dir schon selber so eine Art 
Miniatur-Betriebssystem ausdenken, das die für so einen Bootlader 
nötigen Ressourcen bringt: den SD-Treiber, das Dateisystem, das UI und 
dazu das Eventsystem.

Und das alles kostet dann doch einen deutlichen Teil des 
Programmspeichers, weswegen du dir Gedanken darüber machen solltest, das 
alles tatsächlich als ein kleines OS zu organisieren und nur deine 
Applikation als updatefähig zu gestalten. Das riecht dann auch nach 
SVC's, für die wiederum der GCC zu doof ist, weswegen du besser den Keil 
nehmen solltest.. und und und.

Frohes Schaffen wünscht
W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Das riecht dann auch nach
> SVC's, für die wiederum der GCC zu doof ist, weswegen du besser den Keil
> nehmen solltest.. und und und.
Wie das? Was geht denn an asm("svc") nicht mehr, seitdem ich das das 
letzte mal erfolgreich mit dem GCC benutzt hab? Und warum braucht man 
überhaupt Multitasking für einen SD-Karten-Zugriff? Mit FatFS geht das 
schon ewig ohne, und auch ohne ein "Betriebssystem". Das muss man "nur" 
mit einem Schreib-Zugriff in den Flash koppeln.

[2B^!2B (Gast)]

Dr. Sommer schrieb:
> W.S. schrieb:
>> Das riecht dann auch nach
>> SVC's, für die wiederum der GCC zu doof ist, weswegen du besser den Keil
>> nehmen solltest.. und und und.
> Wie das? Was geht denn an asm("svc") nicht mehr, seitdem ich das das
> letzte mal erfolgreich mit dem GCC benutzt hab? Und warum braucht man
> überhaupt Multitasking für einen SD-Karten-Zugriff? Mit FatFS geht das
> schon ewig ohne, und auch ohne ein "Betriebssystem". Das muss man "nur"
> mit einem Schreib-Zugriff in den Flash koppeln.

Richtig, was man im Endeffekt braucht ist nur ein SDKarten Treiber, 
einen FAT Treiber (ohne Schreibfähigkeit) und die 
In-Application-Programming Fähigkeit des STMs. Alles ohne Betriebssystem 
und Multitasking.

[Jim M. (turboj)]

W.S. schrieb:
> Und das alles kostet dann doch einen deutlichen Teil des
> Programmspeichers,

Habe ich bei einem LPC176x in einem einzigen 4kByte Flash Sektor 
unterbringen können. PetitFatFS existiert...

[Peter (Gast)]

Habe selber was gefunden, da waren wohl meine Suchbegriffe gestern 
falsch.

https://github.com/akospasztor/stm32-bootloader
https://www.feaser.com/openblt/doku.php?id=homepage
und
http://www.st.com/en/embedded-software/x-cube-iap-sd.html

Wobei ich den Code von ST noch nirgens zum einfachen download gefunden 
habe.

Alle Projekte verspechen das das geht.

Mein Linkerfile muss dafür wohl angepasst werden weil mein Code ja nun 
einige KB weiter  hinten im Speicher steht. Was noch so alles angepasst 
werden muss haben die hoffentlich gut erklärt.

Klar kann man das selber schreiben, aber warum immer wieder was neues 
machen wenn es freien Code gibt und der schon erfolgreich eingesetzt 
wird.

VG, Peter

[Karl (Gast)]

Lizenz beachten ?, je nach Anwendung.

Ich habe das Problem anders gelöst:
Der bootloader hat keinen Zugriff auf die sdkarte.
Die Anwendung kopiert ggf. Ein mit AES verschlüsseltes Image von der 
Karte in den flash, bootloader entschlüsselt, prüft und Flasht. Ich 
wollte weder SD noch Dateisystem im bl haben.

Im Notfall geht klassisch per xcp flashen.

[Peter (Gast)]

Der Bootloader muss aber Zugrif haben und auch den Speicher prüfen 
können.

Klar könnte man sein Programm auch in 2 Varianten (Speicherbereiche) 
ablegen und das Programm entscheidet selber welche Version gerade 
gestartet werden soll.
Es gibt viele Möglichkeiten ein Update sicher zu gestallten und auch 
etliche wege an die Daten ran zu kommen.
Aber in meinem Fall reicht die einfache Variante!


VG, Peter

[W.S. (Gast)]

Dr. Sommer schrieb:
> Wie das? Was geht denn an asm("svc") nicht mehr

Oh mann, du hast die Supervisorcalls offensichtlich noch nie benutzt.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Oh mann, du hast die Supervisorcalls offensichtlich noch nie benutzt.

Danke für die detaillierte Erklärung! Das erläutert auch warum 
existierende RTOS'e unter GCC das mit "int 80h" statt "svc" machen.