J-Log.eu - Forum

Hallo,
ich musste leider feststellen, dass zwei S32 (zwei verschiedene Flugmodelle mit eigenem S32) ihre Einstellungen verloren haben.
Das erste Mal trat vor ca. 2 Monaten auf und nach einer Konfiguration ging alles wieder.
Bei der Gelegenheit habe ich auch das neue Kosmik KT Protokoll getestet (Pin beim Kosmikstecker entfernt laut Anleitung) und festgestellt, dass die Drehzahlanzeige (Jeti DS-16) irgendetwas, aber nicht die Drehzahl anzeigt.
Nach dem ich das Protokoll wieder auf Kosmik umgestellt habe (Pin beim Kosmikstecker wieder eingesteckt) ging alles wieder und ich habe mir nicht mehr viel gedacht.
Der S32 war davor für ~3 Monate nicht in Betrieb.

Heute ist mir am Flugplatz wieder das gleiche passiert. (anderes Modell als beim ersten Mal)
Der S32 war für 2-3 Monate nicht in Betrieb und am Flugplatz ging keine Telemetrie.
Zuhause habe ich den S32 am Terminal angesteckt und sämtlich Einstellungen waren wieder weg, nach dem Aufspielen der Konfiguration ging alles wieder.

Wie lange hält die Puffer-Batterie des S32 üblicherweise durch bzw. werden die Einstellungen nicht im EEPROM gespeichert?

Hallo,

ich hatte das Problem auch mal im lzt. Jahr (allerdings nicht wg. langer Lagerung)... der Thread müsste noch zu finden sein. Die Lösung für "auf dem Flugplatz" => Konfig-File im root der Speicherkarte. Die wird vom j-log beim Start gelesen und verarbeitet... funktioniert dann sofort wieder. Ich hab das jetzt sogar permanent drauf. Schadet ja nicht und seither (bei 3 Stk S32) keine Probleme mehr.

Ciao
Michael

Entschuldigung für das Delay.

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.

_________________
Tom