www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Anwendungsbereiche für Cortex-M3 flash patching (FPB)


Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich brauche mal Eure Hilfe beim Konstruieren verschiedener 
Anwendungsszenarien.

In embedded devices kommt es gelegentlich vor, dass ein Teil der 
Firmware nicht aktualisiert werden kann (ROM) oder darf (mögliche 
Gründe?). In einigen Firmwares findet man daher dass Funktionsaufrufe 
vorsorglich indirekt über call tables erfolgen, deren Zieladresse dann 
ggf geändert werden kann. Wie häufig ist dieser Fall in der Praxis?

Wer hat sonst noch Bedarf an einem effizienten Mechanismus zum 
"Verbiegen" einer einzelnen Instruktion, bzw. eines Funktionsaufrufs? 
Alberne Vorschläge verbitte ich mir :-)

Hintergrund: Ich schreibe gerade an einem Aufsatz (neudeutsch: Paper) 
über die ARM v7-M (Cortex-M3/M4) Flash Patch und Breakpoint unit und 
würde gerne ein paar realistische Szenarien beschreiben.

Vielen Dank
Marcus

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flash unterteilen für die Bereiche:
- Boot-Loader
- Firmware
- Parameter
- ???

Bootloader ist eigenständiges Programm
Firmware ist eigenständiges Programm
Beide können gegenseitig angesprungen werden
Parameterbereich darf bei FW Update nicht überschrieben werden

Lösbar über Bereichsaufteilung im Linkerscript.

Eine Tabelle für Funktionsaufrufe halte ich für Sinnlos.

Wenn der Kompiller eine Funktion übersetzt, dann weiß man nicht ob der 
immer relative Calls oder absolute Calls macht. Sobald absolute Calls in 
einer Funktion drin sind, kann man dies nicht "frei" verschieben.

Erst ab ARM9 gibt es sowas wie eine MMU, die ein Betriebssystem nutzen 
kann um beliebige Programme an beliebiger Speicherstelle ausführen zu 
können.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will ja nicht undankbar erscheinen,...

Plan schrieb:
> [...]
>
> Lösbar über Bereichsaufteilung im Linkerscript.

aber ich wollte eigentlich kein Fallbeispiel für das man FPB nicht
braucht. ;-)

> Eine Tabelle für Funktionsaufrufe halte ich für Sinnlos.

Na ja, wenn Du ein Firmware ROM(!) hast und entdeckst dort später
einen Fehler kann das im Einzelfall durchaus sinnvoll sein,
vorausgesetzt, die Tabelle befindet sich in einem beschreibbaren
Speicherbereich.

Dummerweise weiß man vorher nicht, welche Funktion betroffen sein
wird. Daher müsste man alle Funktionen (oder wenigstens eine
sorgfältig definierte Untermenge davon) indirekt aufrufen. Das ist
wegen des zusätzlichen Aufwands natürlich unschön. Im Prinzip könnte
man das relativ bequem über den SVC machen, sofern der nicht
anderweitig verwendet wird.

Ich habe einen Kunden, der verwendet call tables für diesen Zweck.

> Wenn der Kompiller eine Funktion übersetzt, dann weiß man nicht ob der
> immer relative Calls oder absolute Calls macht. Sobald absolute Calls in
> einer Funktion drin sind, kann man dies nicht "frei" verschieben.

Ich will ja nicht eine existierende Funktion verschieben, sondern
statt einer Funktion eine andere aufrufen. Absolute, oder relative
Adressierung ist dabei egal.

> Erst ab ARM9 gibt es sowas wie eine MMU, die ein Betriebssystem
> nutzen kann um beliebige Programme an beliebiger Speicherstelle
> ausführen zu können.

Genaugenommen gab es die schon beim ARM7[12]0T aber auch das ist
eigentlich nicht, wonach ich suche.

Vielleicht muss ich mal kurz erklären, was FPB eigentlich macht:

1. Der Prozessor holt sich durch Addressierung seines Speichers
   Instruktionen.

2. Eine dieser vom Prozessor erzeugten Adressen stimmt mit einem
   Vergleichwert überein, der vorher ins FPB programmiert wurde.

3. Dem Prozessor wird vom FPB eine andere Instruktion untergeschoben,
   als die, die im Speicher an dieser Adresse liegt.

Ich kann also beliebige einzelne Instruktionen ersetzen. Wenn das
Sprünge sind, dann kann ich z.B. den Programmlauf verändern. Ich kann
aber auch ganze Funktionen umleiten, wenn ich statt der ersten
Instruktion der Funktion einen weiteren Sprung zurückgebe.

Meine Frage ist nicht wie ich das mache, sondern: Wer kennt
(idealerweise aus eigener Erfahrung) konkrete Anwendungsfälle, die
einen Vorteil von einem solchen Mechanismus hätten?

Vielen Dank
Marcus

Autor: Juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal, das ist hauptsächlich für Debugger da.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marcus.
Du kannst damit einen Rucksack bauen. Also eine Adresse ueberschreiben 
mit einem Sprung an eine fest vorgegebene Adresse. Dort liegt eine 
"alternative Funktion" zu dem was sonst abgearbeitet wuerde. Aehnlich 
Deinem Beispiel mit Call Table.

Selbst modifizierender Code waere natuerlich eine weitere Anwedung als 
eine Art Sicherheitsmechanismus im Programm gegen auslesen, ist aber 
hoellisch anfaellig gegen Stromunterbrechungen.

Dann natuerlich bei Stromverlust und retten einiger weniger Parameter 
ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der, 
den Du beschrieben hast aber man braucht zur Flash Programmierung 
dasselbe Prinzip.

Vielleicht faellt mir ja noch was ein.

Gruss, Robert

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel schrieb:
> Du kannst damit einen Rucksack bauen. Also eine Adresse ueberschreiben
> mit einem Sprung an eine fest vorgegebene Adresse. Dort liegt eine
> "alternative Funktion" zu dem was sonst abgearbeitet wuerde. Aehnlich
> Deinem Beispiel mit Call Table.

Genau. Das ist ja sozusagen die Standardanwendung (neben Debug
natürlich).

Bisher habe ich nur bei einem einzigen Kunden (entfernte ex-Kollegen
von Dir) die Reaktion gesehen "Super, genau das brauchen wir. Unsere
aktuelle Softwarelösung kann damit abgelöst und die Firmware
vereinfacht werden".

Wer von Euch kann eine ähnliche Aussage treffen und ein Beispiel
nennen? Szenarien, was man damit alles realisieren kann, kann ich mir
selbst ausdenken. Aber wird das auch gemacht?

> Selbst modifizierender Code waere natuerlich eine weitere Anwedung als
> eine Art Sicherheitsmechanismus im Programm gegen auslesen, ist aber
> hoellisch anfaellig gegen Stromunterbrechungen.

Ich fürchte, das ist etwas weit hergeholt.

> Dann natuerlich bei Stromverlust und retten einiger weniger Parameter
> ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der,
> den Du beschrieben hast aber man braucht zur Flash Programmierung
> dasselbe Prinzip.

Wie meinen?

Meine Frage "Wer kennt (idealerweise aus eigener Erfahrung) konkrete
Anwendungsfälle, die einen Vorteil von einem solchen Mechanismus
hätten?" scheint sich indirekt zu beantworten. Im Microcontroller
Bereich scheint diese Eigenschaft des FPB selten bis gar nicht gefragt
zu sein.

Gruß
Marcus

PS: Bist Du nächste Woche auf der EW? Ich werde Mi und Do da sein.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
>> Selbst modifizierender Code waere natuerlich eine weitere Anwedung als
>> eine Art Sicherheitsmechanismus im Programm gegen auslesen, ist aber
>> hoellisch anfaellig gegen Stromunterbrechungen.
>
> Ich fürchte, das ist etwas weit hergeholt.
Alles schon erlebt :-(

>
>> Dann natuerlich bei Stromverlust und retten einiger weniger Parameter
>> ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der,
>> den Du beschrieben hast aber man braucht zur Flash Programmierung
>> dasselbe Prinzip.
>
> Wie meinen?
Anwender braucht eigentlich EEPROM, will es aber nicht extra auf's Board 
machen aus Kostengruenden. Er hat auch noch ein paar KB Flash uebrig und 
moechte dort, wenn das System in Power Down / Power Off  geht ein paar 
Parameter abspeichern. Das ist sehr haeufig der Fall.

> PS: Bist Du nächste Woche auf der EW? Ich werde Mi und Do da sein.
Yeap Mi/Do ich auch

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel schrieb:
>>> Dann natuerlich bei Stromverlust und retten einiger weniger Parameter
>>> ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der,
>>> den Du beschrieben hast aber man braucht zur Flash Programmierung
>>> dasselbe Prinzip.
>>
>> Wie meinen?
> Anwender braucht eigentlich EEPROM, will es aber nicht extra auf's Board
> machen aus Kostengruenden. Er hat auch noch ein paar KB Flash uebrig und
> moechte dort, wenn das System in Power Down / Power Off  geht ein paar
> Parameter abspeichern. Das ist sehr haeufig der Fall.

Und in wiefern würde FPB da helfen?

>> PS: Bist Du nächste Woche auf der EW? Ich werde Mi und Do da sein.
> Yeap Mi/Do ich auch

Prima. Dann sehen wir uns ja vielleicht.

--
Marcus

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.