Es hat nichts mit der Batterie zu tun, sondern mit "Tatterich" beim Besaften. (die Batt ist nur für die RTC, - Real Time Clock)
Heutige ARM Microcontroller (bis auf Low Power ARM) haben keinen EEPROM mehr. Wenn man etwas permanent speichern will im Controller, dann muss man das im NAND Speicher tun, wo sich das Programm befindet (ROM). (der MC in JLog 2.x hatte noch einen echten EEPROM)
NAND ist überall (bis auf ein bisschen NOR für spezielle Zwecke in manchen Controllern), - USB Stick, SD Card, eMMC, SSD.
NAND:
- Man kann ein Bit eines Wortes immer nur in eine Richtung kippen. Will man in die andere, muss die ganze Page gelöscht werden.
- Page: NAND ist pagewise organisiert. Die Größe einer Page variiert, in einem ARM Microcontroller wie im S32, gibt es ganz unterschiedliche Page Sizes.
- Will man einen Random Access Speicher (non-volatile), dann muss man einen EEPROM mittels zweier Pages gleicher Size emulieren, dabei auch was gegen wear-out tun. S32 tut das.
In USB Stick, eMMC (solid state SD, sozusagen), SSD gibt es einen Controller, der den gesamten NAND so ansteuert, dass er als ein Stream von Words erscheint, - in einem Microcontroller nicht.
Nun gibt es noch ein spezielles Problem mit NAND, was hier die Ursache dafür ist, wenn ab und an (je nach Setup des Modells und Tatterich des Users beim Batt Anstecken) beim Powerup das Setup flöten geht, was per Terminal via USB und Bootloader im S32 in den emulierten EEPROM im NAND kam:
Man muss wissen, welche Spannung man z.V. hat, wenn man entscheidet
- in welcher Dateneinheit (Byte, 16-bit oder 32-bit Word) und wieviel davon in einem Access
- in welcher Geschwindigkeit
man schreibt.
Da wird es nun lustig, wenn man kein Hellseher ist.
S32 tut etwas, bevor er entscheidet und schreibt, - Spannungsmessung und Delay
Wenn nun doch die Spannung plötzlich dropt, - dann BINGO! Meist ist gleich die ganze NAND Page im Arsch.
S32 macht es dann konsistent, indem er ein leeres Default Setup in den "EEPROM" schreibt, - so, dass ihm kein Müll befohlen wird durch das Setup.
Nun werdet Ihr fragen: Häh? Wieso Schreiben, er soll doch nur Lesen!
Er muss auch schreiben beim Startup. Dieselben beiden Pages für den emulierten EEPROM dienen auch als "toter Briefkasten" zur Kommunikation zwischen zwei Universen, die in unterschiedlichen Zeiten existieren: Bootloader + Application
Was kann man tun?
Analysieren, wo beim Akkuanstecken multible Wackler herkommen, on, off, on, off, on ... Das sollte vermieden werden.
Statistik: Verfasst von dl7uae — 7. Jul 2018, 14:14
]]>