Hallo Forum, ich bin grade dabei auf einem ATmega2560 zu programmieren. Dieser kommuniziert mittels USART über einen FTDI mit dem Rechner (kein eigenes USART programmiert, sondern eingebautes USART0 benutzt). Gleichzeitig spreche ich per SPI mehrere Peripherie geräte an (wieder das eingebaute SPI benutzt, kein eigenes Programmiert). Dies klappt wunderbar und funktioniert ohne Zwischenfall stundenlang. Doch dann setze ich den fast-pwm auf Pin L5 ein (Hardware-PWM), der auch funktioniert (Periodendauer = 8s wie gewünscht), und wir haben das Problem: Nach unvorhersehbaren Zeitabständen zwischen 1s und 2min bricht die USART Kommunikation vorrübergehen zusammen, PuTTY sagt das Lesen am Port funktionierte nicht mehr, MATLAB sagt das gleiche. Dabei ist das globale Interrupt bit deaktiviert. Hatte jemand schonmal so ein Problem?
@Niklas Rpunkt (hobbycoder) >Doch dann setze ich den fast-pwm auf Pin L5 ein (Hardware-PWM), der auch >funktioniert (Periodendauer = 8s wie gewünscht), ACHT Sekunden Periodendauer? Das ist eher ein langsames Blinken als PWM. > und wir haben das >Problem: Nach unvorhersehbaren Zeitabständen zwischen 1s und 2min bricht >die USART Kommunikation vorrübergehen zusammen, PuTTY sagt das Lesen am >Port funktionierte nicht mehr, MATLAB sagt das gleiche. >Dabei ist das globale Interrupt bit deaktiviert. >Hatte jemand schonmal so ein Problem? Nö, aber es ist mit hoher Wahrscheinlichkeit ein Programmierfehler und kein Hardwaredefekt. Poste vollständigen Code als Anhang.
Was soll "Dabei ist das globale Interrupt bit deaktiviert" bedeuten? Steuert ihr alles aus einem Hauptprogramm ohne Interrupts?
Felix A. schrieb: > Was soll "Dabei ist das globale Interrupt bit deaktiviert" bedeuten? > Steuert ihr alles aus einem Hauptprogramm ohne Interrupts? Das bedeutet im SREG ist das Interrupt bit auf 0 gesetzt. Die Kommunikation über USART und die Kommunikation erfolgt beide male via polling. Sprich wir fragen so lange ab, ob wie senden können, bis wir senden können. Beim Empfang das gleiche. Aber da die latenz zwischen Senden und Empfangen via SPI so gering ist, ist dies kein Nachteil. Und USART benutzen wir eh nur unidirektional.
"PuTTY sagt das Lesen am Port funktionierte nicht mehr" Das hört sich eher danach an als ob der FTDI die Grätsche macht.. Ist das USB-Gerät in dem Zustand noch da? Kannst du die USB-Verbindung mal trennen und wieder herstellen? Geht es dann wieder?
Chris schrieb: > "PuTTY sagt das Lesen am Port funktionierte nicht mehr" > Das hört sich eher danach an als ob der FTDI die Grätsche macht.. > Ist das USB-Gerät in dem Zustand noch da? Kannst du die USB-Verbindung > mal trennen und wieder herstellen? Geht es dann wieder? Wenn ich PuTTY direkt wieder öffne, dann empfange ich auch wieder die zu erwartenden Daten. Das geht ein paar Sekunden gut und dann bricht sie wieder zusammen.
Wird in Richtung PC seriell gesendet? Oder sendet ihr mit Putty Richtung uC? In letzterem Fall könnte ich mir vorstellen, dass da vielleicht die Zeichen nicht schnell genug abgeholt und manchmal überschrieben werden.
Ich fürchte, ohne einen Schaltplan und ein Layout kann ich da nicht mehr weiterhelfen. Da der Fehler eher zufällig auftritt, vermute ich eher ein Layoutproblem. Softwareprobleme will ich damit aber nicht prinzipiell ausschließen.
Ich weiß leider nicht, ob ich das Layout rausgeben darf. Ich werde so bald wie möglich die verantwortlichen Leute fragen.
Ohne das Layout rauszugeben, könntest du den Verlauf der Leitung kontrollieren. Läuft diese dicht am USART entlang oder an dessen Leitungen? Oder sehr dicht am FTDI? Was hängt an dieser PWM-Leitung? Hintergrund ist, dass hier steile Flanken auftreten, die eventuell kapazitiv in den USART oder FTDI einkoppeln.
Die beiden USART Leitungen und die Leitung mit PWM laufen so weit auseinander wie irgend möglich auf dem Board :/ Am Ende der PWM Leitung liegt ein Relais das angeblich im worst case max 9mA zieht.
Niklas Rpunkt schrieb: > Am Ende der PWM Leitung liegt ein Relais das angeblich im worst case max > 9mA zieht. Dann ersetze das Relais doch mal durch einen passenden Widerstand ud prüfe nochmals. Deine Fehlerbeschreibung deutet darauf hin, dass auf der seriellen Schnitte Störungen sind, die den Treiber im PC zum Absturz bringen. Und eine Relaisspule, passend beschaltet, kann da durchaus interessante Effekte bringen.
Das stimmt. Gibt es eine Freilaufdiode am Relais? Wird dieses über einen Transistor betrieben oder wirklich direkt über den Pin?
Hast du den TEST-Pin am FTDI beschaltet? Bleibt der offen ergibt sich so ziemlich das gleiche Fehlerbild.
Bauteiltöter schrieb: > Hast du den TEST-Pin am FTDI beschaltet? Bleibt der offen ergibt sich so > ziemlich das gleiche Fehlerbild. TEST ist auf GND Felix A. schrieb: > Gibt es eine Freilaufdiode am Relais? Wird dieses über einen Transistor > betrieben oder wirklich direkt über den Pin? Darüber weiß ich leider nichts, da das relais in einem weiteren Bauteil versteckt ist, über das ich keine großartigen Daten habe außer welchen Pin ich high bzw. low machen muss Georg G. schrieb: > Dann ersetze das Relais doch mal durch einen passenden Widerstand ud > prüfe nochmals. Das werde ich tun, sobald ich den Aufbau entsprechend umgebaut habe.
Könntest du denn die Bauteilbezeichnung des Bauteils mit dem Relais nennen? Über das Datenblatt lässt sich vielleicht auch schon was finden.
Hallo, es scheint ja so, als ob der FTDI kurz "verschwindet". Wie wird der betreiben? Bus-powered? Eigentlich sind die Teile nicht sehr empfindlich. Welche Baudrate wird denn benutzt? Die UART-Leitungen mit Störungen auf dem Weg zum FTDI so zu versauen daß der FTDI sich abmeldet ist garnicht so einfach. Wenn das Relais eine Rolle spielt müßte der Fehler ja zu provozieren sein, der Absturz käme dann beim Schalten des Relais, das sollte doch zu beobachten sein. Wenn es nur bei Einsatz der fastPWM passiert würde ich eher ein Softwareproblem vermuten. Gruß aus Berlin Michael
Was ist denn jetzt mit dem Schaltplan? Fällt der - genauso wie manchmal das Ohmsche Gesetz - unter "STRENG GEHEIM"? Ein Relais mit 9mA kommt mir schon etwas exotisch vor. Handelt es sich vielleicht um ein SSR? Gerne ist auch falsche Sparsamkeit bei Abblockkondensatoren der Grund für solche merkwürdigen Fehler.
Ich hab das mit dem Widerstand statt relais jetzt gemacht. Keine Ausfälle mehr. Ich nehme an dass das relais schuld ist und werde das so weitergeben. Vielen Dank füe eure Hilfe.
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.