Forum: Mikrocontroller und Digitale Elektronik Re - Programmierung eines Cortex M0


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 Daniel D. (daniel1976d)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Guten Tag,

Vielleicht kann mir ja jemand helfen.

Mit unserem Zulieferer in China entwickeln wir ein Geraet. Dieses Geraet 
verwendet einen Cortex-M0 Prozessor. Der Prozessor wird duch ein ESLink 
II Programmiergeraet programmiert. Dieses basiert auf ISP/IAP mit zwei 
Leitungen, aehnlich I2C und der Prozessor hat einen Flash Speicher.

Waehrend der Produktion muss dieses Geraet kalibriert werden. Diese 
Werte sollen permanent im Geraet bleiben. Nun behauptet der Zulieferer 
das wenn wir das Geraet updaten (neues Programm) dann wird automatisch 
der komplette Speicher geloescht und somit auch die Kalibrierungswerte. 
Ich denke jedoch das es moeglich sein sollte die Kalibrierungswerte 
permanent zu schuetzen.

Ich habe mal das Datenblatt drangehangen.


Leider habe ich nicht viel Vertrauen in die Kuenste unseres Zulieferers. 
Der wollte schon mal ein neues PCB designen weil er versehentlich das 
LCD andersherum designed hat, statt einfach zwei kleine Bits im LCD 
Kontroller zu setzen.

Liebe Gruesse

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
Dazu müsste man jetzt euer Programm kennen.

Wenn man diese Kalibrierwerte im Programm/Flash speichert, werden diese 
natürlich zusammen mit dem Rest des alten Programms beim neu flashen 
gelöscht.

Ansonsten habe ich vom Cortex M0 speziell jetzt nicht die große Ahnung, 
aber da gibts so viele Wege, wie man das Problem lösen könnte...

1. Speichern der Werte im EEPROM, welches beim Programm neu flashen 
nicht gelöscht wird.

2. Speichern der Werte in einem Bereich des Flash, der beim neu flashen 
nicht gelöscht wird (z.B. Bootloader).

3. Das Update-Programm liest die Werte erst aus, schreibt dann das neue 
Programm und anschließend die alten Werte zurück bzw. passt die alten 
Werte gleich ins neue Programm ein.

4. Manchmal ist ein externes I2C oder sonstewas-EEPROM vorhanden, in 
diesem könnte man die Werte ebenfalls so ablegen, daß sie bei einem 
Neuflashen des Controllers nicht gelöscht werden.

von Daniel D. (daniel1976d)


Bewertung
-1 lesenswert
nicht lesenswert
Danke erstmal...

Leider haben wir kein externes EEPROM.

No. 3 hoert sich nicht schlecht an. Aber wie realiert man das wenn der 
Programmierer ein hex file bekommt? Wuerden diese Werte immer wieder an 
der gleichen Stelle sein?
LG

von Wolfgang (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Wenn man diese Kalibrierwerte im Programm/Flash speichert, werden diese
> natürlich zusammen mit dem Rest des alten Programms beim neu flashen
> gelöscht.

Mmmh ...
Der Prozessor unterstützt IAP und es gibt den Speicherbereich im Flash, 
der über das FWPEB Bit im CFG_WORD1 schreibgeschützt werden kann. In 
diesem geschützten Speicherbereich würde normalerweise der Boot-Loader 
liegen, mit dem man per IAP ohne besondere Programmierschnittstelle das 
Programm aktualisiert und der nicht überschrieben wird.

von Max H. (nilsp)


Bewertung
-1 lesenswert
nicht lesenswert
Über IAP geht auch Page Erase. Man könnte die Kalibrierwerte in die 
letzten Flash-Pages packen und das Linker-Script so anpassen, das dort 
kein Code landet.

Ob die Toolchain zum Flashen so schlau ist die Pages dann nicht zu 
überschreiben muss man rausfinden. Zur Not muss der Teil dann halt 
geändert werden. Ist zwar Arbeit, aber keine Raketenwissenschaft.

von Peter D. (peda)


Bewertung
-1 lesenswert
nicht lesenswert
Daniel D. schrieb:
> Ich habe mal das Datenblatt drangehangen.

Da steht doch drin, daß ein Page-Erase unterstützt wird.
Im Programmer muß man auswählen, daß nur benutzte Pages gelöscht werden 
und es darf kein Schreibschutz gesetzt sein. Ein Schreibschutz läßt sich 
nur mit einem Full-Erase löschen, sonst wäre er ja sinnlos.
Im Hex-File muß dann die Kalibrierpage unbenutzt sein, d.h. es darf 
keine Vorbelegung erfolgen.

Bei den AVRs geht das einfacher. Da kann man mit einem Fusebit 
auswählen, daß der Data-EEPROM nicht gelöscht wird.

von A. F. (artur-f) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Daniel D. schrieb:
> Ich denke jedoch das es moeglich sein sollte die Kalibrierungswerte
> permanent zu schuetzen.

Es ist schon blöd, dass Ihr einen China uC eindesigned. Gibt anständige 
und bekannte Firmen, bei denen ein M0  ~1$ kostet...

Also wenn Flash-write nicht unterstützt wird evtl zweitprojet mit extra 
section für die Kalibrierwerte und am ende nur diesen Bereich 
flashen....

von Random .. (thorstendb) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Bei den AVRs geht das einfacher. Da kann man mit einem Fusebit
> auswählen, daß der Data-EEPROM nicht gelöscht wird.

Das hat aber nichts mit einfachen AVR oder komplizierten Cortex-M zu 
tun, sondern damit, das Atmel den AVRs ein kleines EEPROM als Peripheral 
spendiert hat, welches vom Flash völlig getrennt liegt.

Normalerweise unterteilt man so eine Firmware in zwei oder drei 
getrennte Bereiche, und deaktiviert nach dem initialem Flashen das Debug 
Interface vom Bootloader (oder der Firmware) aus:
- Bootloader mit Firmwareupdater, ggf. Crypto für FW (falls gewünscht)
- Firmware
- Config Area / Gerätespezifische Fixdaten

So kann man z.B. die Firmware updaten, ohne den Bootloader zu löschen, 
oder eben eine Config Area neu schreiben.

von Olaf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Es ist schon blöd, dass Ihr einen China uC eindesigned.

Ne, das hat mit Klug zu tun weil solche Controller in China besser 
erhaeltlich sind.

Olaf

von Daniel D. (daniel1976d)


Bewertung
-1 lesenswert
nicht lesenswert
Danke fuer die Antworten,

Sorry ich bin mir immer noch nicht wirkoich sicher wie man so etwas 
machen kann.
Unser Zulieferer sagt das man das definitiv nicht machen kann...

Das Flashen / Programmieren wird zur Zeit mit einem Programmiergeraet 
durchgefuehrt welches von der Mikrocontroller Firma (East Soft) 
geliefert wird. Die Pinne deuten auf eine Art I2C und dann gibt es noch 
5V, GND und einen Pin der HIGH oder LOW geschaltet wird. Die Bedienung 
des Programmiergeraetes wird von einer Software durchgefuehrt welche 
auch von EastSoft kommt.

Wahrscheinlich eine doofe Frage. Im Datenblatt gibt es ein Flowchart 
(IAP Programming Flowchart) welches das Seitenweise schreiben und 
loeschen beschreibt. Waere es moeglich wenn das EastSoft Programm das 
nicht unterstuetzt das selber zu programmieren? Zum Beispiel koennte man 
ein Arduino nehmen, I2C kann der ja....

Wird mit dem hex file noch irgendetwas gemacht? Oder wird das 1:1 
hineingeschrieben... Sorry wahrscheinlich bin ich jetzt zu naiv.

LG

von softwerker (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Daniel D. schrieb:
> Die Pinne deuten auf eine Art I2C ..

Es ist wie bei (fast?) allen M0s SWD.

Die Programmiersoftware muss den Chip kennen.
OpenOCD kennt ihn wohl nicht..

von A. F. (artur-f) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Olaf schrieb:
>> Es ist schon blöd, dass Ihr einen China uC eindesigned.
>
> Ne, das hat mit Klug zu tun weil solche Controller in China besser
> erhaeltlich sind.
>
> Olaf

Die uC's von ST, NXP, TI, Silabs sind in China genau so leicht zu 
bekommen wie in DE, dazu auch noch ein wenig günstiger. Hat also nichts 
mit der Klugheit zu tun. Man erkauft sich durch die Ersparnis von 
einigen Cent viel Ärger am Ende....

von Wegstaben V. (wegstabenverbuchsler)


Bewertung
-1 lesenswert
nicht lesenswert
hat denn dein "Gerät" eine externe Schnittstelle (für welchen Zweck auch 
immer)?  Vielleicht liesse sich ja darüber ein backup&restore der 
Kalibrierwerte (bei einem notwendigen Software-Update) abbilden.

Übrigens: Wer aktualisiert denn eigentlich die Software? Ihr oder der 
Kunde?

Und was passiert, wenn die Kalibrierwerte futsch sind? Geht die 
neu-Kalibrierung nur "bei euch" in einem kontrollierten (Produktions?-) 
Prozess? Oder lässt sich eine solche Kalibrierung auch durch den Kunden 
durch irgendeinen Mechanismus durchführen?

Was passiert, wenn das Gerät falsche/initiale Kalibrierwerte verwendet?

Vielleicht ist es ja tatsächlich eine "gute" (im Sinne von: zweckmäßig 
und verargumentierbare) Lösung, das neue Software (und eine 
anschließenede Neu-Kalibrierung) nur ausschließlich bei euch 
durchgeführt wird?

: Bearbeitet durch User
von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Das Datenblatt sagt ja eindeutig dass für IAP eine SWD Schnittstelle 
verwendet wird... Das Ding hat ja sogar 2 mal SWD. Wenn der Lieferant 
sagt es ist nicht möglich einen Teil des Flashs als cfg Speicher zu 
verwenden, kann das nur daran liegen dass der komplette Speicher mit 
Erase All gelöscht wird. Ihr müsst also eine Flasher Software schreiben 
die nur den Page Erase verwendet und die Kuh ist vom Eis.
Es wird ja vom Chiphersteller wohl eine API und Beispiele geben wie man 
das macht. Viel Spass mit den dem Übersetzen aus dem Chinesischen. 
Obwohl Google Translate ist mittlerweile recht gut.

von Andreas M. (amesser)


Bewertung
-1 lesenswert
nicht lesenswert
Lol! Eure Firma hat entschieden die Entwicklung billigst auszulagen und 
bekommt nun eben die Rechnung. Jetzt solls das Forum richten. Aber euer 
Zulieferer hat vermutlich recht, mit dem proprietären ISP-Protokoll geht 
vermutlich (*) nur ein voller Chip-Erase. laut Datenblatt des Mikros 
gibt es drei, naja eigentlich zwei Möglichkeiten wie der Mikro 
programmiert werden kann:

- Mit den IAP Registern/Unit (flashcontroller) aus dem laufenden Program 
heraus, wobei hier klar steht, das keine Codeausführung aus dem Flash 
währendessen möglich ist. Hier kann man selektiv 1kB Seiten löschen

- Über das SWD interface indem man die gleich IAP Unit wie oben 
anspricht. Hier könnte man ebenfalls selektiv 1kB Seiten löschen

- Über das propriätäre ISP-Protokoll des Herstellers, welches die 
gleichen Leitungen wie SWD benutzt aber I2C ist. Dazu gibts bis auf den 
Flowchart nicht viel Info (*), aber nach dem Flow-Chart könnte man 
erahnen, dass es da nur einen Chip-Erase gibt.

Damit bleiben für euch zwei Möglichkeiten: Update über einen echten SWD 
Debugger oder einen echten IAP Mechanismus, der natürlich in der 
Firmware/Bootloader selbst implementiert sein muss.

(*) Nennt man wohl Security by obscurity, das ISP protokoll nicht genau 
zu spezifizieren. "With the company authorized ISP programmer..."

von Daniel D. (daniel1976d)


Bewertung
-1 lesenswert
nicht lesenswert
Danke fuer die vielen Antworten.

So wie es aussieht kann der IC nur komplett durch ein vorheriges Erase 
All neu geflasht werden. Mehr kann dieser firmeneigene Programmierer 
nicht.

Die Kalibrierung selber ist zur Zeit Bestandteil des Hauptprogramms. Um 
diese durchzufuehren muss waehrend des Starts ein bestimmter Pin auf GND 
liegen.

Ich bin morgen oder uebermorgen im Labor dann kann ich vielleicht mehr 
sagen.

: Bearbeitet durch User
von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
A. F. schrieb:
> Es ist schon blöd, dass Ihr einen China uC eindesigned.

Nee, es ist eher blöd, daß ihr anscheinend Scrum oder ähnliches für die 
Software, aber nicht für die Hardware anwendet. Manchmal ist es doch 
sinnvoll, sich über die Anforderungen vorher Gedanken zu machen, und 
nicht einfach nur lustig drauflos zu entwickeln.

Oliver

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Ihr könnt ja Euren China-Entwickler beauftragen, einen Bootloader zu 
schreiben. Die IAP-Funktionen sind ja offengelegt.
Der Bootloader kann dann alles, was man implementiert hat, z.B. das 
seitenweise Löschen und das Firmwareupdate.

von Daniel D. (daniel1976d)


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ihr könnt ja Euren China-Entwickler beauftragen, einen Bootloader zu
> schreiben. Die IAP-Funktionen sind ja offengelegt.
> Der Bootloader kann dann alles, was man implementiert hat, z.B. das
> seitenweise Löschen und das Firmwareupdate.

OK, das waere das Beste und wahrscheinlich auch das Einfachste.

Jedoch befinde ich mich in der misslichen Lage das die komplette 
Entwicklung vom Zulieferer getragen wird und diese im Produktpreis 
verrechnet sind. Daher versucht der Zulieferer diese Kosten natuerlich 
klein zu halten... Daher bekommen wir oft zu hoeren... oh das ist nicht 
moeglich, usw.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Daniel D. schrieb:
> Jedoch befinde ich mich in der misslichen Lage das die komplette
> Entwicklung vom Zulieferer getragen wird und diese im Produktpreis
> verrechnet sind.

Ja, externe Entwicklung wird oft teurer, als intern. Jede Erweiterung, 
jede Fehlerkorrektur kostet extra. Und gerade µc-Produkte sind oft grüne 
Bananen und müssen erst mit der Zeit reifen. Das Problem sind oft die 
Spezifikationen, sie sind zu ungenau, d.h. der Auftraggeber weiß selber 
nicht genau, was er zum Schluß eigentlich haben will.

Daher machen wir die Entwicklung selber und behalten das Know-how im 
Hause. Nur die Fertigung erfolgt extern.

: Bearbeitet durch User
von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Nun irgendwie verstehe ich das Problem nicht so ganz.
Es scheint ja wohl so zu sein, dass keine Updates beim Kunden möglich 
sein werden, da die Firmware mit einem dezidierten Programmer inhouse 
durchgeführt werden muss.

Dann muss die Kalibrierung halt nach einem Update neu gemacht werden. 
Die Kalibrierdaten werden wohl ins Ram kopiert oder ist eure Firmware in 
der Lage diese im Flash zu ändern?

Irgendwie scheint Ihr ein ernstes Defizit im Software Design zu haben.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Im Update-Prozess die alte Firmware inklusive Kalibrierungsdaten 
auslesen, die Kalibrierungsdaten in die neue Firmware eintragen und dann 
mit der herstellereigenen Updatesoftware flashen.

Verbietet natürlich den Einsatz vom Ausleseschutz, aber das Auslesen 
kann man ja die Firmware selbst machen. Möglicherweise auch nur von den 
Kalibrierungsdaten...

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Ja das wäre ein Weg. Im wesentlichen hat Ben weiter oben genau diese 
Vorgehensweise beschrieben. Als Vorbereitung wäre es dann hilfreich die 
Kalibrierdaten an einer festen Pos. zu haben. Damit wird das 
postprocessing des Hex Files einfacher. Wenn das nicht gegeben ist, muss 
man sich immer durch die Mapfiles kämpfen und das natürlich für jede 
Version.
Das kann ziemlich eklig werden.

Für konkrete Strategien müsste aber erst klar sein wie der Update 
Prozess funktionieren soll.

: Bearbeitet durch User
von Daniel D. (daniel1976d)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Sorry fuer die spaete Antwort.

Habe am Wochenende mal geschaut was der Programmierer so kann.

Das Ding kann den Prozessor auslesen und als hex file speichern. Habe 
das mal nach dem Flashen und nach der Kalibrierung gemacht. Die zwei 
Files mit einem Texteditor verglichen und dann bekam ich herraus wo die 
Unterschiede sind. Dort muessen ja die Kalibrierungsdaten liegen.

Werde nun mal schauen ob es einen hex file Editor gibt.

Das Programmiergeraet erlaubt jedenfalls im Speicher zu editieren.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Dir ist aber schon klar dass du das mit jeder Variante erneut machen 
musst, wenn die Positionen nicht fix sind.
Was machst du wenn du von v1 auf v3 aktualisierst?
Kannst du sicherstellen dass die Kalibrierdaten immer das gleiche Format 
haben?
Zusätzlich gebe ich zu bedenken dass ev im Hex des Lieferanten Lücken im 
Hexfile sein werden. Solche Lücken hast du nicht wenn du mit dem 
Programmer ausliest.
Ansonsten ist es recht einfach ein entsprechendes Tool zu schreiben. 
Sowas ist grob geschätzt in 2..3 Stunden programmiert.

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]
  • [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.

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