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
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.
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
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.
Ü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.
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.
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....
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.
> 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
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
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..
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....
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
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.
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..."
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
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
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.
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
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
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.
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...
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
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.