Hallo. Ich habe eine Platine mit einem CH32V003F4P6 . Jetzt ist bei einigen aufgefallen das das Programm nicht mehr da war. Ob jetzt nur ein Bit umgekippt ist oder ob der Flash komplett leer war habe ich nicht geprüft. Jedenfalls nach dem neu Programmieren geht alles wieder. Bei der nächsten Platine wo der Prozessor aussteigt werde ich als erstes mal den Flash runter laden und vergleichen. Hat jemand schon mal so was gehabt? Wie kann so etwas überhaupt passieren?
> Wie kann so etwas überhaupt passieren?
1. Der Hersteller hat Murks geliefert
2. Der Programmieralgorythmus ist nicht korrekt
3. Die Betriebspannung ist beim programmieren nicht korrekt.
Passiert oefters als man denkt weil viele Device dabei kurz
mehr Strom ziehen.
4. Der Baustein hat einen Bug der in kombination mit falscher
beschaltung beim Anwender, zu langsamen hochfahren der
Spannungsversorgung mit ungenuegenden Reset dazu fuehrt
das er interne Loeschroutinen startet.
Vanye
Also die Schaltung ist sozusagen eine Standardbeschaltung. 4MHz 3,3v regler, ein paar Taster, 3 * ad und ein pwm Ausgang. Programmiert wird mit dem original Debugger und der passenden Software. Das bei dem Preis mal einer defekt ist kann ich mir vorstellen, aber die wollen ja Massen davon verkaufen und wenn es nur probleme gibt kauf die keiner mehr. Das der eine interne löschroutine hat die man so einfach startet wäre mir neu. Da braucht man wohl noch etwas mehr.
> Also die Schaltung ist sozusagen eine Standardbeschaltung. Das sagen sie alle. :) Ausreichend Kondensatoren am Chip? > Das der eine interne löschroutine hat die man so einfach > startet wäre mir neu. Das erzaehlt dir der Hersteller auch nicht. Aber die Teile lassen sich ja ueber ein serielles Protokoll programmieren. Da ist also ein Programm drin welches die Faehigkeiten hat sein Flash zu loeschen. Wenn das aufgrund eines nicht korrekten Resets aufgerufen wird dann kann das zu sowas fuehren. Ich hatte mal so ein Problem mit einem MCS51 Derivat wo Rueckspeisung ueber einen Gleichstrommotor die Spannung langsam angehoben hat und zu Alzheimer gefuehrt hat. Wenn du sowas nochmal hast dann lies den mal aus. Hast du eine defekte oder halb defekte Bank dann war das die Loeschroutine im Chip. Hast du nur hier und da mal ein defektes Bit, eventuell bei jedem Lesen warm/kalt oder mit leicht unterschiedlicher Spannung dann ist beim flashen selber was schief gelaufen. Vanye
Dirk E. schrieb: > Hat jemand schon mal so was gehabt? > Wie kann so etwas überhaupt passieren? Ja. Wir hatten die Brown Out Detection nicht aktiviert. Bei jedem power down durchlief der Chip den Bereich in dem einige Gatter noch kippen, andere schon nicht mehr. Das führt zu zufälligen Befehlen, Parametern und Adressen. In den paar ms die das anhält schafft die MCU erstaunlich viele Befehle abzuarbeiten. Und irgendwann war dann auch was dabei was einen Schreibvorgang im Flash auslöste. BOD gesetzt, nie wieder Probleme gehabt.
Das mit der Rückspeisung könnte sogar passieren. Auch wenn das dann extrem kompliziert wird damit am Prozessor was ankommt. Das muß ich mir mal genauer anschauen. War das mit dem BOD bei diesem Prozessor? Werde ich kontrollieren, der sollte aber an sein genauso wie der WD.
Achso klar hat der Prozessor intern eine löschfunktion,wie jeder der Flash hat und kein otp ist. Aber die ruft man nicht mal so eben auf.
Dirk E. schrieb: > War das mit dem BOD bei diesem Prozessor? Nö, ATmega128. Das Prinzip sollte das gleiche sein, sofern der CH32V00 self programming kann. Schau Dir den Flash an und vergleiche. Weit häufiger sind aber dumme Sachen die man selber macht. Wird irgendwas dauerhaft gespeichert, das das Bootverhalten beeinflussen kann? Kann die Applikation auf den Bootloader zugreifen oder ist der gesperrt? 'Läuft nicht' bedeutet was genau? Kannst Du noch einen Takt messen oder wackelt irgendein Debug Pin der signalisiert das die MCU auf ein Ereignis wartet das nie mehr eintritt? Kommst Du mit dem Debugger noch rann und kannst Register auslesen? Kann ein externes Ereigniss eine Spannung über ungeschützte Port einspeisen die die VCC anhebt? Schaltplan zeigen, Umgebung beschreiben. Ist Dir vielleicht verboten, aber dann diskutiere das mit Kollegen. Bisher waren es noch immer eigene Fehler und noch niemals das ein Baustein eine zugesicherte Eigenschaft nicht eingehalten hätte, wenn es nicht grad ein gefakter aus der Teilebörse war. Konzentrier Dich auf eigene Fehler. Wäre das ein WCH Problem gäbe es bereits dramatische Szenen bei den hochvolumigen Kunden, die das Teil längst einsetzen.
Dirk E. schrieb: > Also die Schaltung ist sozusagen eine Standardbeschaltung. 4MHz 3,3v > regler, ein paar Taster, 3 * ad und ein pwm Ausgang. > Programmiert wird mit dem original Debugger und der passenden Software. Leider sagt das nichts zur Stromversorgung, die hier der kritische Punkt ist. > Das der eine interne löschroutine hat die man so einfach startet > wäre mir neu. Da braucht man wohl noch etwas mehr. Nach meinem Kenntnisstand können Mikrocontroller im Flash Speicher und EEPROM auch Daten verlieren, wenn beim Lesezugriff die Versorgungsspannung instabil ist. Mir ist das mal mit einem AVR Mikrocontroller reproduzierbar passiert.
:
Bearbeitet durch User
Michael schrieb: > Bei jedem power down durchlief der Chip den Bereich in dem einige Gatter > noch kippen, andere schon nicht mehr. > Das führt zu zufälligen Befehlen, Parametern und Adressen. Und irgendwann > war dann auch was dabei was einen Schreibvorgang im Flash auslöste. Das ist wie tausend Affen, die zufällig auch mal einen vollständigen Paragraphen des Grundgesetzes tippen: sehr unwahrscheinlich. Und bei der hier beobachteten Häufigkeit ist es sogar sehr, sehr unwahrscheinlich. Steve van de Grens schrieb: > Mir ist das mal mit einem AVR Mikrocontroller reproduzierbar passiert. Beim AVR-EEPROM war es damals(tm) so, dass ohne Brownout-Fuse beim Abfallen der Versorgungsspannung jedesmal (!! also nicht nur dann, wenn man zufällig in einer Schreibroutine war) die Löschspannungsladungspumpe eingeschaltet wurde. Und dann zufällig alle die EEPROM-Zellen ein wenig "gelöscht" wurden, auf die der langsam auf 0 abfallende EEPROM-Pointer zeigte. Am meisten erwischte es die Speicherzelle 0. Das ging so weit, dass einige Bibliotheken das Byte 0 im EEPROM gar nicht verwendeten. - https://www.avrfreaks.net/s/topic/a5C3l000000TyniEAC/t009190 - https://www.eevblog.com/forum/microcontrollers/eeprom-corruption-on-avr/msg5373428/#msg5373428
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und bei der hier beobachteten Häufigkeit ist es sogar sehr, sehr > unwahrscheinlich. Komisch, genau das sagten unsere Programmierer auch lange. Und zwar so lange bis der Kunde kurz davor war uns einen Schlägertrupp vorbeizuschicken. Dann haben sie die BOD aktiviert und das Problem war weg. Ich finde es also müssig darüber zu diskutieren. Wenn man die MCU weiterlaufen lässt wenn die Spannung nicht mehr ausreicht um den bei der Taktfrequenz sicher zu betreiben, ist das Murks. Da kann man über Wahrscheinlichkeiten diskutieren und flipcharts malen oder man kann das mit zwei Handgriffen ändern. Klären kann das letzlich nur der TO indem er den Flash ausliest und vergleicht.
Wenn ich wieder eine Platinen mit diesem Problem habe, werde ich den auslesen, hatte ich aber schon geschrieben. Ich greife nur lesend auf den Speicher, da wird nix geschrieben. Nunja genug Kondensatoren sind da schon dran, wobei der Ch32v003 auch nur 2 pins für die Spannung hat. Und die sind recht gut angebunden, der Regler Sitz auch nur 2cm daneben. Intern hat der eine Spannungs Überprüfung, die ist nicht abschaltbar!
> Leider sagt das nichts zur Stromversorgung, die hier der kritische Punkt > ist. Genau, vermutlich werden hier viele rot wenn man sie fragt wie stark denn der Stromverbrauch ihrer MCU ansteigt sobald der Flash beschrieben wird. :-D Vanye (und jetzt nicht hektisch im Datenblatt blaettern)
Dirk E. schrieb: > Ich greife nur lesend auf den Speicher, da wird nix geschrieben. Es spielt keine Rolle, was dein Programm mit Absicht tut. Wenn die Stromversorgung unzureichend ist, dann macht es auch unbeabsichtige Dinge.
Michael schrieb: > Dann haben sie die BOD aktiviert und das Problem war weg. Ja, ich sage ja: ohne Brownout passiert das sehr oft. Nur wirkt es sich nicht jedesmal gleich aus. Und zwar "gleich" im Sinne von "ebenso" und auch im Sinne von "sofort". Dirk E. schrieb: > Ich greife nur lesend auf den Speicher, da wird nix geschrieben. Das interessiert die Ladungspumpe nicht, wenn die "aus Versehen" bei schwankender Versorgung eingeschaltet wird. > Nunja genug Kondensatoren sind da schon dran Auch richtig?
Der Ch32v003 hat Power up und Down Überwachung eingebaut. Das kann man auch nicht abstellen. Wenn es dadurch passieren sollte hat wch ein großes Problem. Bei den Kondensatoren kann man nicht wirklich was falsch machen. Das ist kein hochleistungs Prozessor wo man am besten zwischen die pins einen setzen sollte.
Dirk E. schrieb: > Der Ch32v003 hat Power up und Down Überwachung eingebaut. > Das kann man auch nicht abstellen. In addition, the system is equipped with a programmable voltage monitor (PVD), which needs to be turned on by software to compare the voltage of VDD power supply with the set threshold VPVD. D.H. Du hast nur den 2,7V BOR aktiv und der ADC braucht min 2,8V. Die VCC kann auch ganz locker weit über die 3,3V angehoben werden wenn Du die Ports schlecht vor dem Rest der Schaltung geschützt hast. Fokussier dich nicht auf WCH. Das Problem liegt zu 99,9% zwischen Deinen Ohren oder darin was unbekanntes passierte als der Chip die Funktion einstellte. Check auch den Einbauort. Liegt was in der Nähe das heftige Felder produziert? 4Mhz ist auch die minimum Resonator Frequenz. Ist meist eine schlechte Idee Dinge an den Grenzen zu betreiben.
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.