Go Down

Topic: Arduino Nano reset durch EMV? (Read 249 times) previous topic - next topic

niggi_five

Hey,

ich nutze einen Arduino Nano V3 Klon für die Steuerung meines Eigenbau Pedelec / Ebikes.
Der Nano dient dazu Pedalieren zu sensieren, Taster/Schalter auszuwerten und über UART einen VESC (Motorcontroller) anzusteuern der wiederum einen BLDC-Nabenmotor ansteuert.
Mein Problem ist, dass bei höheren Motorströmen (ich habe mehrere Unterstützungsstufen, bei der höchsten fordere ich 30A Motorstrom vom VESC) sich der Nano sporadisch resettet. Das äußert sich darin, dass die Unterstützung kurz aussetzt und dann wieder mit der niedrigsten Stufe (die per default beim Einschalten aktiv ist) wieder einsetzt.

Das Verhalten entspricht allerdings nicht exakt dem, wenn ich einfach auf den reset-Knopf drücke. Das merke ich daran, dass dann auch der Scheinwerfer, den ich mit einem Ausgang schalte sich kurz aus- und dann wieder anschaltet. Das passiert bei den sporadischen Aussetzern nicht. Allerdings kann ich mir das Zurückstellen auf den default-Wert nur durch einen Reset erklären.

Da das nur bei hohen Motorströmen auftritt, vermute ich, dass die Ursache EMV vom Motorcontroller ist die auf den Nano einkoppelt.

Meine Frage wäre jetzt, wodurch überhaupt ein Reset herbeigeführt werden kann und wie ich es beheben könnte. Mein erster Gedanke wäre, einen Kondensator vom Reset-Pin nach GND einzubauen aber vielleicht gibt es noch andere Stellen an denen ich ansetzen könnte.

Mit einem Oszi die Signale anzuschauen ist leider nicht so einfach, da das Problem ja nur im Betrieb bei voller Unterstützung auftritt, ich den Fehler also nicht so ohne weiteres auf dem Schreibtisch nachstellen kann.


Grüße
Niklas

combie

#1
Mar 20, 2020, 04:44 pm Last Edit: Mar 20, 2020, 04:49 pm by combie
Die Resetquellen sind im Datenblatt beschrieben.
Und wenn du den Bootloader entfernst, kannst du sogar feststellen, welche da am Werke war.


Zudem glaube ich nicht  dass dir die EMV (ElektoMagnetischeVerträglichkeit) Probleme macht.
Eher die Abwesenheit dieser Verträglichkeit.
Unsichtbar wird der Wahnsinn, wenn er genügend große Ausmaße angenommen hat.
(Berthold Brecht)

niggi_five

#2
Mar 20, 2020, 05:02 pm Last Edit: Mar 20, 2020, 05:03 pm by niggi_five
Hi,
danke für die schnelle Antwort!

Laut Datenblatt gibt es 4 Reset-Quellen:
Power-On-Reset
External Reset
Watch-Dog
Brown-Out

Den Watch-Dog würde ich eigentlich ausschließen, da ich ihn nicht aktiviert habe und er, soweit ich weiß, auch nur aktiv ist wenn man ihn explizit einschaltet.

Bleiben also External und Brown-Out. Das mit dem Kondensator an den Reset-Pins werde ich auf jeden Fall mal probieren. Wenn es nichts hilft muss ich weiterschauen.

Hältst du es denn für plausibel, dass sich der vermeintliche Reset anders verhält als wenn ich den Knopf drücke?

Grüße
Niklas

EDIT: Mit der Abwesenheit von EMV hast du natürlich recht ;)

combie

Quote
Hältst du es denn für plausibel, dass sich der vermeintliche Reset anders verhält als wenn ich den Knopf drücke?
Natürlich wertet der Bootloader die Resetquelle aus!
Unsichtbar wird der Wahnsinn, wenn er genügend große Ausmaße angenommen hat.
(Berthold Brecht)

niggi_five

Wie meinst du das?
Also, dass bei einem Brown Out der µC schneller wieder bereit ist wie nach einem externen Reset?

michael_x

Beim Wiederanlauf "weiß" der Controller noch, ob er aus der Spannungswiederkehr kommt, oder ob nur RESET einen Flankenwechsel hatte.
Wie "komplette Spannungswiederkehr" und "Ende der BOD" zusammenhängen, weiß ich nicht, da würde ich bei Interesse das Datenblatt studieren. und das evtl. ausprobieren.

Kannst ja auch mal den Bootloader-Code ansehen und mit dem Datenblatt vergleichen.



Ich habe EMV immer als "Elekto Magnetische Verwirrung" gelesen. :) Gab immer Sinn.

EMV-Probleme
EMV-Schutz
EMV-Maßnahmen

Erinnert mich an den Apotheker-Spruch "Haben Sie was für Halsschmerzen?" - "Nein, nur dagegen"

combie

Wie meinst du das?
Also, dass bei einem Brown Out der µC schneller wieder bereit ist wie nach einem externen Reset?
Der Bootloader Code liegt auf deinem Rechner.
Also kannst du da selber rein schauen!

Offensichtlich ist doch, dass der Bootloader nur an der Seriellen horchen muss, wenn der externe Reset erfolgt ist.
Also startet er nach einem Brown Out oder WDT Reset viel schneller durch.

Das ist nur logisch, nachvollziehbar und der Bootloaderprogrammierer hätte einen hinter die Löffel verdient, wenn ihm das nicht in den Sinn gekommen wäre.


Aber das ist alles Kakao, Träume und Schäume, solange du nicht prüfst, was da WIRKLICH passiert.


Unsichtbar wird der Wahnsinn, wenn er genügend große Ausmaße angenommen hat.
(Berthold Brecht)

Deltaflyer

Wie wird denn der Nano gespiesen? Vlt. brauchst du da auch nur einen Stützelko über den Spannungsversorgungseingängen des Nanos, der dir solche sporadischen Mikrospannungseinbrüche auffängt.

LG Stefan

michael_x

Quote
der Bootloaderprogrammierer hätte einen hinter die Löffel verdient, wenn ihm das nicht in den Sinn gekommen wäre.
Auf jeden Fall muss der Bootloaderprogrammierer aufpassen, dass der Code klein genug bleibt um in den kleinstmöglichen Booloader-Bereich zu passen. -> Optiboot sollte man bei Interesse auch auf die Nano-Klone "mit altem Bootloader" packen.

skyfox60

Da dir ja die Meßmethode "Oszi" beim Fahren nicht zur Verfügung steht, hier mal ein Tip.

In die Plus Leitung des Arduino eine Diode hängen ( am besten eine Schottky ). Dann einen Elko von ca. 3300µf - 4700µf von Plus nach Minus.

Dann noch mal probieren, und BITTE berichten.

In meinen Hubschraubermodellen hat sich diese Methode seit Jahren bestens gegen Brownouts bewährt, und das bei Strömen von 100A und mehr, die da mehr oder weniger abrupt abgesaugt werden aus dem Akku.
Der leckerste Fisch ist immer noch der Rumpsteak.

niggi_five

Hi,

sorry für die späte Antwort.

Was ich mittlerweile herausgefunden habe:
Ein 100nF Kondensator von Reset nach GND hat nichts geändert, außer, dass ich den Nano nicht mehr über USB programmieren konnte während er in meiner Platine war. Habe ich also wieder ausgebaut.

Die Resetquelle kann ich jetzt auslesen. Dazu musste ich erst Optiboot statt dem original Bootloader brennen, da der Originale scheinbar das Reset-Flag-Register zurücksetzt.
Code zum auslesen der Resetquelle habe ich hier: https://forum.arduino.cc/index.php?topic=246359.0 gefunden.

Vermutlich lag mein Problem aber an einem RAM-Überlauf. Durch etwas sparsamere Programmierweise habe ich etwa 150 Bytes RAM eingespart und damit läuft es bis jetzt stabil.

Falls ich doch wieder Aufhänger bekomme werde ich mir die Resetquelle auch nochmal genauer anschauen.

Die Idee mit dem Stützelko habe ich erstmal nicht probiert, da ich so ein großes Bauteil nicht so einfach auf meine Platine bekomme und mir daher Softwareänderungen erstmal bequemer erschienen.

Grüße
Niklas

uwefed

Was hast Du denn programmiert daß 2kByte RAM nicht ausreichen?
Grüße Uwe

niggi_five

Im Wesentlichen rede ich mit einem VESC über UART. Dazu verwende ich das VescUartControl-Projekt von RollingGecko: https://github.com/RollingGecko/VescUartControl
Dann steuere ich ein 0,96" 128x64 OLED Display über I2C an. Dazu nutze ich die U8x8 Bibliothek: https://github.com/olikraus/u8g2/wiki/u8x8reference (Strings zum Anzeigen habe ich schon mit dem F() Makro in den Programmspeicher geschoben).

Dazu noch ein paar Globale Variablen mit Structs, Tasterauswertung und Interrupt, um zu erkennen ob pedaliert wird.

Ich hatte selbst auch nicht damit gerechnet, dass es knapp werden könnte. Allerdings benötigen die beiden Libraries fuer Display und VESC schon jew. wenige hundert Bytes, eine float-Variable allein braucht 4 Bytes, da kommt dann schon einiges zusammen.
Wenn ich dazu komme mache ich mal eine genaue Aufstellung was wie viel RAM benötigt.

Gruß Niklas

Go Up