Hallo,
Ich habe mit Mikrocontrollern leider keinerlei Erfahrung und wollte das
ändern. Aber im Vordergrund steht für mich erst eine Fehlersuche.
Habe hier mehrere DNA200 Boards, das sind Mikrocontroller gesteuerte
Regelungen für E-Zigaretten. Ich würde gerne versuchen einem in der
Dampfercommunity sehr häufig auftretenden Fehler auf den Grund zu gehen.
Ein fehlerfreies Board reagiert im Normalfall so. Man legt drei Akkus
ein, drückt den Feuerknopf und das Board bootet hoch und ist
Einsatzbereit. Nach 30 Minuten Inaktivität geht das Board in den Standy
Mode. Man muss den Feuerknopf dann erneut drücken, damit das Board
wieder bootet und wieder ist es einsatzbereit. Das ist das normale vom
Hersteller und den Kunden gewünschte Verhalten.
Jetzt habe ich hier drei fehlerhafte Boards.
Diese Verhalten sich so:
Man legt drei Akkus ein und drückt den Feuerknopf und nichts passiert,
das Board bootet nicht und das Display bleibt schwarz. Hier kann man den
Bootvorgang nur einleiten, wenn man während man den letzen Akku einlegt
den Feuerknopf gedrückt hält. Dann bootet das Board normal hoch und ist
einsatzbereit. Lässt man es dann 30 Minuten stehen, geht es in den
Standby und man bekommt nicht mehr per Druck auf den Feuerknopf
gestartet. Dann muss man wieder einen der drei Akkus rausnehmen, den
Feuerknopf beim Einlegen des Akkus gedrückt halten und das Board
startet.
Evtl könnte hier ein Fehler in der Programmierung des Atmel vorliegen.
Da diese Boards auch Benutzereinstellungen speichern, könnte ja
vielleicht hier irgendwas beim Speichern der ein oder anderen
Einstellung passiert sein, dass der Mikrocontroller einfach nicht mehr
den Eingangspin im Standby einlesen will.
Da die Software "Escribe" von Evolv anscheinend einen Bug hat und man
die Werkseinstellung nicht vollkommen wiederherstellen kann, wollte ich
einfach versuchen, mal den Atmel eines meiner funktionierenden Boards
auszulesen und auf fehlerhaftes Board zu kopieren.
Meine Frage wäre, was brauche ich dafür um dies auf dem einfachsten Wege
zu probieren ? Da ich nicht weiß ob im Atmel die Fuses aktiv sind, wäre
erstmal der einfachste Weg das Beste. Am Löten soll es natürlich nicht
scheitern, das bekomme ich sicher hin, weil ich auch schon die ein oder
andere Micro USB Buchse an diversen E-Zigaretten erfolgreich gelötet
habe.
Wäre super, wenn mir da jemand ein paar Tips geben könnte :-)
Viele Grüße,
Christian
Kommt drauf an ob die SWD Ports nach draußen gelegt wurden?
Möglicherweise ist die Routine zum schlafen legen fehlerhaft. Es gibt
glaube ich nur 1 oder 2 Pins womit über den PMC das aufwachen realisiert
wird.
Woran erkenne ich ob die Ports nach aussen gelegt wurden ?
Was bräuchte ich an Hardware um auf den Atmel zugreifen zu können ?
Ich gehe davon aus, dass irgendwas mit dem Bootloader des Boardes ist.
Anders kann ich mir das nicht vorstellen, weil das Board Anfangs ohne
Probleme funktioniert hat und aufeinmal dieses wake-up Problem
aufgetreten ist. Am Feuertaster an sich kann es auch nicht liegen, weil
dieser ja tadellos funktioniert, wenn man das Board mit dem Akkutrick
starten konnte.
Ich vermute mal das sie nicht nach außen legt wurden. Mach mal eine Foto
von vor und Rückseite.
Um den SWD zu nutzen benötigst du einen Debugger der das Device
unterstützt. Atmel ICE oder ein J-link.
Hör lieber auf zu Rauchen und Vorsicht beim anstecken an den PC aus soll
schon vorgekommen sein das in Lampen und solchen Dingen Viren
eingeschleust wurden.
Oben ist ein Bild von der Vorderseite angehängt. Auf der Rückseite ist
nichts brauchbares, weil direkt hinter dem Atmel 2 Leistungsspulen sind
und dort keine Pads erreichbar wären.
Ich könnte nur versuchen entweder direkt am Atmel, an umliegenden
Bauteilen und an Platinendurchführungen zu löten.
Das hat mit Rauchen genausoviel zu tun wie Cola mit Biertrinken......
Auf den aufgebauschten Schwachsinn aus den Medien gebe ich nicht
wirklich viel, vorallem weil der DNA200 von einem renomierten Hersteller
kommt und ich sonst keine China Billig "E-Zigaretten" habe sondern nur
hochwertige Mods ala SX-Mini M, Dicodes No6, DNA200 und zahllose
Mechmods die keinen USB haben ;-)
Ich habe mir das Board mal nochmal genauer angesehen und man kann PA30,
PA31 und RESET ohne große Probleme erreichen. Bei einem Pin muss ich
lediglich den Lack von der Platine kratzen um das Durchführungspad zu
erreichen :-)
Soweit ich das in dem Datenblatt zu dem Controller verstanden habe,
brauche ich nur diese 3 Pins ?
Wäre dann dieser Debugger den ich zum versuchsweise Auslesen verwenden
könnte ?
http://www.ebay.de/itm/like/291576648448?lpid=106&chn=ps&ul_noapp=true
Soweit ich erkennen kann, hat dieser die 5 Leitungen von denen eine
ohnehin optional auf einigen Devices ist (SWO)
Das würde dann in meinem Verständnis von der Materie bedeuten, dass ich
Pin 26 (Reset), Pin 30 (VDDIN), Pin 31 (PA30) und Pin 32 (PA31) mit dem
Debugger verbinden müsste um den Atmel auszulesen.
Das ganze würde sich dann eigentlich nur auf der linken Seite des
Controllers auf dem Foto abspielen.
Und eine externe Spannungsversorgung ist bei diesem Vorgang dann nicht
von Nöten.
Soweit waren jetzt meine Recherchen laut meines Verständnisses, ich habe
versucht, es selbst herauszufinden, weil ich nicht einfach nur fragen
will um dann auf vorgekaute Antworten zu warten und in der Zeit faul
herumzusitzen :-D
Jetzt brauche ich nur noch eine Bestätigung meiner Theorie und die
Hardware Seite wäre schonmal erledigt ;-)
Christian M. schrieb:> Soweit ich das in dem Datenblatt zu dem Controller verstanden habe,> brauche ich nur diese 3 Pins ?
Ja, so sollte es sein.
Ist natürlich die Frage, ob die Firmware überhaupt auslesbar ist,
es ist durchaus wahrscheinlich, dass man den Ausleseschutz
aktiviert hat.
> Wäre dann dieser Debugger den ich zum versuchsweise Auslesen verwenden> könnte ?
Kan sein, muss nicht sein. Keine Erfahrung hier mit so einem
Billigteil.
Das preiswerteste offizielle Atmel-Board zum Programmieren und
Debuggen wäre dieses hier:
http://shop.myavr.de/Systemboards%20und%20Programmer/Atmel%20ICE%20Programmerboard%20%28ATATMEL%20ICE%20PCBA%29.htm?sp=article.sp.php&artID=200142
Mit OpenOCD wiederum wirst du so ziemlich alles zum Laufen bekommen,
was einen ARM per SWD programmieren kann, aber es könnte auf ein
wenig (Software-/Konfigurations-)Gebastel hinauslaufen.
> Und eine externe Spannungsversorgung ist bei diesem Vorgang dann nicht> von Nöten.
Diesen Satz verstehe ich nicht; ich würde mich an deiner Stelle
nie auf irgendwelche Spannungsversorgung aus einem Debugger heraus
verlassen, sondern immer die originale des Geräts benutzen. Du
weißt sonst nicht, was auf dem Board alles noch passiert. Es gibt
Spannungsregler, die es einem übel nehmen, wann man sie „von hinten“
befeuert.
> Jetzt brauche ich nur noch eine Bestätigung meiner Theorie und die> Hardware Seite wäre schonmal erledigt ;-)
Naja, wie geschrieben, das größte Risiko ist es, dass der Chip
lesegeschützt sein dürfte (nennt sich "Security Bit" im Datenblatt).
20160606_182535.jpg
(210 KB)
