Guten Tag, ich habe eine über RS485 ansteuerbare LED-Matrix mit dem SAMD21 aufgebaut. 4 Felder mit RGB-LEDS, jedes Feld kann mit einer von 8 voreingestellten Farben individuell angesteuert werden. LEDs sind über PWM angesteuert, das alles läuft auf 3,3V Nun funktioniert das nicht mehr richtig, die LED-Felder sind entweder dauerhaft aus oder glimmen mehr oder weniger intensiv in einer Farbe. Erst dachte ich der µC hat den Geist aufgegeben, aber der lässt sich einwandfrei ansprechen, programmieren und debuggen... Naja, also debuggen nicht unbedingt einwandfrei, das kann ich so nicht sagen. Wenn ich das Programm durchsteppe kommt früher oder später der Punkt wo anstatt einen Schritt weiter zu gehen das Programm normal weiterläuft und ich erst mit "Break all (Ctrl-F5)" in den Step-Modus komme. Das passiert beim System-init (ich habe die Atmel-Framework-Libraries verwendet), präziser beim clock-init in der Funktion switch_peripheral_gclk(); Ausserdem wird der µC merklich warm, mehr als ich für normal halte. Was kann da passiert sein und wieso hängt der µC in so etwas wie einer Endlosschleife? Was kann ich tun um dem Problem weiter auf die Schliche zu kommen? Mein Wissen mit µC hält sich in Grenzen, leider... Grüßle, Bob
Mit wieviel Strom treibst du die LEDs, und woher kommt dieser Strom? Wenn du da einige zig mA durch den uC fließen lässt, könnte das die hohe Temperatur erklären. Oder du hast ihn schon überlastet und jetzt ist er (bzw. sind die Pins) ein bisschen kaputt, was die Wärmeentwicklung definitiv erklären kann.
Bob A. schrieb: > Das passiert beim System-init (ich habe die Atmel-Framework-Libraries > verwendet), präziser beim clock-init in der Funktion > switch_peripheral_gclk(); Das ASF hat ein riesen Problem: Es arbeitet mit Rekursion und es werden Fehlerfälle nicht behandelt. Gerade bei den Clocksettings kannst du folgendes Problem bekommen: Das ASF versucht per Rekursion den Clock zu ermitteln. Wenn die Clocksettings ungünstig/falsch gewählt sind, kann es zu einer endlosen Rekursion kommen -> Stacküberlauf. Da könntest du mal mit der Suche anfangen.
S. R. schrieb: > Mit wieviel Strom treibst du die LEDs, und woher kommt dieser Strom? > Wenn du da einige zig mA durch den uC fließen lässt, könnte das die hohe > Temperatur erklären. Oder du hast ihn schon überlastet und jetzt ist er > (bzw. sind die Pins) ein bisschen kaputt, was die Wärmeentwicklung > definitiv erklären kann. die LEDs werden über FETs angesteuert, sonst wären die IOs schon längst gegrillt :)
Kaj schrieb: > Bob A. schrieb: >> Das passiert beim System-init (ich habe die Atmel-Framework-Libraries >> verwendet), präziser beim clock-init in der Funktion >> switch_peripheral_gclk(); > Das ASF hat ein riesen Problem: > Es arbeitet mit Rekursion und es werden Fehlerfälle nicht behandelt. > Gerade bei den Clocksettings kannst du folgendes Problem bekommen: > Das ASF versucht per Rekursion den Clock zu ermitteln. Wenn die > Clocksettings ungünstig/falsch gewählt sind, kann es zu einer endlosen > Rekursion kommen -> Stacküberlauf. > Da könntest du mal mit der Suche anfangen. OK, aber wie kann sowas im laufenden Betrieb passieren? Ich habe 8 solcher Leuchten, und nun fallen die nach und nach aus... An der Programmierung wurde nix geändert, die ersten Wochen lief alles problemlos. Das ist mir alles etwas schleierhaft. Ich kram mal in der Bauteilkiste ob ich eine µC zum tauschen finde
Bob A. schrieb: > die LEDs werden über FETs angesteuert Und du bist dir sicher, dass du die I/Os trotzdem nicht, also auch nicht "ein bisschen" überlastest? Langsam sterbende Bauteile können nämlich auch durch beschleunigte Alterung entstehen. Bist du dir sicher, dass deine LEDs noch fehlerfrei sind? Nicht, dass der Fehler ursprünglich von dort kam und der sterbende Controller nur ein Folgefehler ist. Bob A. schrieb: > Ich kram mal in der Bauteilkiste ob ich eine µC zum tauschen finde Wenn du den Fehler nicht gefunden hast und einfach den Controller tauchst, stehen die Chancen gut, dass der gleiche Fehler mit der Zeit wieder auftritt. Gibt es irgendwas interessantes zur Umgebung zu sagen? Feuchtigkeit, hohe Temperaturen, etc.? Im Augenblick ist es jedenfalls nur ein Ratespiel.
Hi Bob, Wie ist der Optimierungslevel des Compilers eingestellt ? Debuggen klappt nur sinnvoll ohne Optimierung: -O0 Wenn Dein Code dann zu groß ist, hast Du Pech und musst den Fehler anders finden oder eine größere Ausbaustufe des uC nehmen. Mit Optimierung gibt es immer komisches verhalten. Hast Du and den Clocks geschraubt und hast mehr als 24MHz ? Im Datenblatt gibt es eine Tabelle 36-39, welche Wait States Du bei bestimmten Spannungen / Frequenzen einstellen musst. Beliebter Fehler. Und der bleibt häufig genau in der Routine hängen. Ich teile im Übrigen die Auffassung von Kaj nicht, weil ich "riesen Problem, Rekursion, Fehlerfälle nicht behandelt" pauschal auf das ASF bezogen verstehe...es mag genau hier an der Stelle ein Problem sein, aber außer das ASF etwas...sagen wir "aufgeblasen" ist, seh ich keine Probleme, gerade bezüglich Fehlerfälle...man muss sich natürlich die Mühe machen, alle Rückgabeparameter zu verifizieren und nicht blind annehmen, "dieser API Call kann eh nicht schief gehen, pfeifen wir auf den Return Wert..." Wenn Du einen alten funktionierenden Code hast und der auf einmal nicht mehr funktioniert, nur weil Du eine Zeile hinzugefügt hast oder gelöscht hast -> Stack oder Pointer. Bitte ALLE Warnungen korrigieren, meist liegt der Compiler mit seinen Warnungen richtig. Das scheint aber nach Deiner Beschreibung nicht Dein Problem zu sein. Das Ding hat ja mal funktioniert. PS: Die IOs sind gegen Überlastung geschützt. Wenn Du den Prozessor also nicht künstlich arg gealtert hast, solltest Du damit auch kein Problem haben. PPS: Welche Spannung sehen Deine LEDs an der Anode ? 3V3 reicht normalerweise nicht aus für blau und weiss. Und jetzt bitte nochmal auf die Schulbank und das kleinstmögliche Program zum Testen erstellen: * richtige GPIOs als Output konfigurieren * Im Abstand von 1s (hier gerne delay_ms, delay_init nicht vergessen) und Output toggeln * Mit Multimeter am Gate messen Sonst kannst Du lange Raten... cu N2
Kai P. schrieb: > Debuggen > klappt nur sinnvoll ohne Optimierung: -O0 Moderne Compiler kennen -Og (Optimierung für Debugging). Bei -O3 oder -Os würde ich mir vorher den Assembler Output anschauen (-save-temps=obj -fverbose-asm) - ansonsten kann man den oft wilden Sprüngen schlecht folgen. Debugging ist dann immer noch möglich (aber unbequem und verwirrend).
S. R. schrieb: > Gibt es irgendwas interessantes zur Umgebung zu sagen? > Feuchtigkeit, hohe Temperaturen, etc.? Hmm... Temperaturen sollten im spezifizierten Bereich liegen, ich schätze nicht über 60°C Vibrationen gibt es jede Menge Elektromagnetische Verseuchung auch, in der Nähe werden Motoren mit Frequenzumrichtern betrieben S. R. schrieb: > Wenn du den Fehler nicht gefunden hast und einfach den Controller > tauchst, stehen die Chancen gut, dass der gleiche Fehler mit der Zeit > wieder auftritt. Das stimmt allerdings, war 'ne blöde Idee! Kai P. schrieb: > Wenn Du einen alten funktionierenden Code hast und der auf einmal nicht > mehr funktioniert, nur weil Du eine Zeile hinzugefügt hast oder gelöscht > hast -> Stack oder Pointer. > > Bitte ALLE Warnungen korrigieren, meist liegt der Compiler mit seinen > Warnungen richtig. > > Das scheint aber nach Deiner Beschreibung nicht Dein Problem zu sein. > Das Ding hat ja mal funktioniert. Jupp, die Leuchten haben "einfach so" im laufenden Betrieb versagt. Die clocks habe ich nicht angefasst, alles ist auf einem Beispiel der ASF aufgebaut... Ist schon watt her und ich mach das nicht jeden Tag, muss mich auch wieder einarbeiten. Von daher ist dein Tipp mit einem minimalistischen Beispiel ranzugehen genau das was ich versuchen werde, Danke! Aber erst probiere ich das Debuggen ohne Optimierung aus :) Ich merke mal wieder wie wenig ich von der Materie verstehe ... :/ Grüßle, Bob
Hey Jim, Danke für den Hinweis auf "-Og". Der GCC unterstützt das ab Version 4.8, also 2013. So lange hab ich schon nicht mehr ins GCC Manual geschaut... Fragt sich, warum Atmel Studio in der Konfiguration Debug den Default immer noch auf -O1 hat, wo es immer noch bei Step by Step Probleme gibt. Aber gut, würde man sich die DropDown-Liste der Optimierungslevel noch durchlesen und nicht in gewohntes Verhalten zurückfallen, hätte man den Schalter "-Og - Optimize Debugging Experience" (den es vermutlich schon in Atmel Studio 6 gibt) finden können :) Gruß N2
Kai P. schrieb: > PPS: Welche Spannung sehen Deine LEDs an der Anode ? 3V3 reicht > normalerweise nicht aus für blau und weiss. 3,3V reichen, die leuchten ganz schön hell :)
Na toll... da ich di -Og option nicht hatte dachte ich mir, och machste mal ein update vom Atmel Studio. GROßER FEHLER!! jetzt geht gar nix mehr, ich kann den µC nicht mehr programmieren:
1 | Could not activate interface, but found DAP with ID 0xbc11477.. |
2 | |
3 | This usually indicates that the device is locked or in deep sleep. Try to do a chip erase to restore connectivity to the device. |
4 | |
5 | Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device. |
Fuses kann ich lesen & schreiben, Speicher auslesen geht auch, Chip löschen auch, nur programieren nicht. Danke Atmel, bzw. Microchip :/
Uff, mit Hilfe vom Support ist jetzt alles wieder lauffähig! Was'n Krampf! Und weiter geht die Suche!!
Ich habe jetzt noch 2 weitere defekte Leuchten angeschaut, die schmieren beim debuggen an unterschiedlichen Stellen ab... Spaßeshalber habe ich mal einen Segger J-Link drangehängt, der meldet schon nach dem download der Firmware Fehler! "Lost connection to target", oder ich sehe gleich die disaasembly Ansciht mit lauter 0xFF drin... Programmieren lässt sich der µC auch nicht, Verifiy schlägt fehl und es stehen lauter 0xFF drin. Mit dem Atmel ICE ist program, verify und debug kein Problem... Sehr dubios! Hat jemand noch eine Idee was ich noch versuchen kann um dem Problem auf die Schliche zu kommen? Irgendwas in dem µC stimmt doch nicht aber was? Und wieso? Grüße, Bob P.S.: ein funktionierender µC lässt sich auch mit dem J-Link problemlos programmieren und debuggen
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.