Hi, ich habe wieder mal eine Frage zu einem RFM12 Modul. Konkret habe ich das RFM12BSPm Rev1.0. Wie schon andere, habe auch ich festgestellt, dass sich das Modul hin und wieder mal taub stellt und nichts mehr empfangen will. Das ist aber nicht weiter schlimm, weil ein neues Initialisieren des Moduls das Problem immer löst und ich solche Ausfälle für meinen Anwendungsfall problemlos hinnehmen kann. Was mich aber mehr stört ist, dass das Modul auch irgendwann das Senden verweigert. Will ich eine Zeichenkette verschicken, so bekomme ich (nach dem ersten "gesendeten" Zeichen) nie einen Interrupt vom Modul, der mir ein erfolgreich versendetes Zeichen zu bestätigen soll. Als Reaktion darauf habe ich einfach mal einen Watchdog eingebaut, der den Controller restet, aber leider ohne Erfolg. Auch nach einem Reset kann das Modul nicht mehr senden. Empfangen funktioniert aber schon. Helfen tut dann letztlich nur ein echter Reset der Schaltung. Ob es reichen würde, das Modul alleine spannungsfrei zu schalten, kann ich noch nicht sagen. Hattet ihr auch schon mal ein ähnliches Verhalten?
Ich habe mir jetzt mal einen kleinen LogicAnaylzer ausgeliehen um evtl. das Problem zu sehen. Erkennen kann man sehr deutlich, dass das Empfangen wirklich noch ohne weiteres funktioniert. Nachdem ich alle Zeichen empfangen habe, sende ich ein 0x8208, rechne ein bisschen und sende dann ein 0x8238. Dann warte ich auf einen Interrupt um mit dem Senden zu beginnen. Leider kommt der aber dann nie mehr. Außerdem kann man erkennen, dass beim Senden des vorletzten Befehls, die 0x8208, die MISO Leitung auf High geht und dann nie wieder Low wird. Was könnte denn das bedeuten? Ach ja. Das Modul, und nicht den ganzen Aufbau, von VCC abzuhängen und dann mittels Reset neu zu Initialisieren hilft auch nicht. Kann der Mikrocontroller die MISO Leitung auf High setzen, bzw. ist das irgendwie ein bekanntes Fehlerbild? Bin ratlos....
Passt veilleicht nicht ganz, aber ein ähnliches Problem hatte ich auch. Ich steuere neben dem Datenfunk auch Funksteckdosen und diese "wollten" plötzlich nicht mehr obwohl der RFM12 noch Daten empfangen hat. Ich habe 2 Sachen eingebaut, weiss aber nicht welche gegriffen hat. 1. ich habe eiun Reset eingefügt befor ich Daten ausgebe, da ich ohnehin die Frequenz umschalte passte das dahin:
1 | ... |
2 | RFM12_CS_ON // Chipselect ein |
3 | delay_ms(10); |
4 | rfm12_trans(0x0000); // Status lesen (u.a. nIRQ löschen) |
5 | |
6 | rfm12_trans(0xFE00); // Software reset |
7 | delay_ms(10); |
8 | |
9 | rfm12_trans(0x0000); // Status lesen (u.a. nIRQ löschen) |
10 | // weitere INIT |
2. ich sende einen Datensatz vor dem Senden Seitdem funktioniert alles einwandfrei. Komischerweise ist das nur bei einem Modul aufgetreten, welches relativ wenig sendet. Ist zwar auch nicht der Weisheit letzter Schluß aber bei mir hat es geholfen. HolgerW.
Hi, ich das mit dem "Reset" habe ich auch mal probiert. Ich mal die 0xFE00 vor oder nach der 0x8208 (Deaktivierung RX) gesendet. Leider ohne Erfolg bzw. Wirkung. Ich bin mir auch nicht sicher, ob der Befehl bei meinem Modul das gleiche bewirkt wie bei deinem. Bei mir Steht im Datenblatt dazu, dass ich damit einen Wakup Timer Command absetzte mit T = 0*2^30 [ms].
Also ich hab insgesamt 4 RFM12 die untereinander Daten austauschen, ausser dem einen gab es nie Probleme. Init ist die aus dem Thread von Benedikt, nichts besonderes darin. Im Datenblatt zum si4420/4021 steht: Software reset: Sending FE00h command to the chip triggers software reset. Vielleicht doch mal vor der Initialisierung wie bei mir einbauen und diese jedes mal aufrufen bevor etwas gesendet wird. Holger
Angehängte Dateien:
-
screenshot.png
5,2 KB
Irgendwie komm ich nicht dahinter, vor allem weil auf dem Master (Atmega644) der gleiche RFM Treiber läuft wie auf dem Client (Atmega168). Auffällig ist aber auch noch, dass kurz vor dem Fehlerfall zwischen dem vorletztem und dem letztem empfangenen Byte die MISO Leitung ebenfalls high bleibt, wird aber wieder Low nach dem Abfragen des letzten Bytes. Das ist im Normalfall auch nicht so. Sende ich dann noch das 0x8208, bleibt MISO dauerhaft high...
Evtl. solltest du bei jedem Interrupt auch das Status Register abfragen, dann kannst du auch überprüfen ob der Interrupt auch wirklich durch ein freigewordenes Byte im FIFO stammt oder einen anderen Grund hatte. So mache ich das auch und das läuft absolut stabil.
Peter schrieb: > Evtl. solltest du bei jedem Interrupt auch das Status Register abfragen, > dann kannst du auch überprüfen ob der Interrupt auch wirklich durch ein > freigewordenes Byte im FIFO stammt oder einen anderen Grund hatte. Nach dem was ich von LogicAnalyzer so sehe, sollte das schon passen. Hab's aber trotzdem mal ausprobiert. Hat leider den Fehler auch nicht beseitigt, aber dabei ist mir was anderes aufgefallen. Immer wenn der Fehler auftrit, war vorher mal eine Phase dabei, in der der Interrupt des RFM länger angestanden hat als gewohnt. Sprich, ein anderer Interrupt hat den des RFM blockiert. Das war eigentlich kein Problem, da dass immer mal wieder der Fall war und alles einwandfrei funktioniert hat. Aber ich vermute mal, dass, falls der Interrupt über eine bestimmte kritische Zeit hin blockiert wird, irgendwas im RFM schief geht, wenn ich kurze Zeit nach dem Auslesen des letzten Zeichens RX wieder einschalte und dann sofort oder sehr bald ein neues Zeichen empfangen wird. Man kann das auch an dem Screenshot sehen. INT0 stand schon etwas an, bevor das Zeichen gelesen wurde. Dann kommt noch ein Zeichen nach und danach geht alles schief. Ich habe jetzt mal die anderen Interrupts raus genommen und schon läuft der Testcode seit 1,5h Stunden ohne Probleme.
Vielleicht ist dein Problem eher das du zu viel in deine Interrupt-Handler (die anderen) reingepackt hast und der RFM dann in einen Buffer underflow rein kommt. Ich glaub das müsste man auch im Statusregister sehen. Wäre Bit 2: RGUR - TX register under run, register over write (Cleared after Status Read Command )
Hallo, ohne jetzt alles gelesen zu haben: ich hatte auch mal hängende Module, die plötzlich nicht mehr senden wollten. Lag wohl am etwas ungünstigen Aufbau, ein 4,7-10µF Elko dicht am Modul behob das Problem zuverlässig. Gruß aus Berlin Michael
Hallo, Ich habe viele RFM12 Module am laufen, und bei mir hat sich über monatelangen Betrieb hinweg noch keines aufgehängt. Schlüssel zu der ganzen Sache ist ein vernünftiger Interrupthandler. 1. Status lesen. 2. Auf den Status reagieren (reagieren/quittieren/löschen): Ist es ein FFIT INT: FIFO lesen, FIFO_off, FIFO_on. Ist es ein RGIT INT: In das Tx Register schreiben. Nach dem letzten gesendeten Byte TX_off. Dabei entweder warten bis das letzte Byte gesendet wurde, oder zusätzlich ein Dummy byte senden und dann Tx_off. Dann gibt es aber einen RGUR Interrupt, der mit rfm12_cmd(0x0000) zu löschen ist! (Das Dummy byte wird praktisch "abgewürgt") Alle anderen INTs (WKUP, LOBAT etc.) falls nicht benötigt, quittieren mit rfm12_cmd(0x0000). FFIT int und RGIT int sind beide Status 0x8000. FFIT kann aber nur auftreten wenn Rx = on, RGIT tritt nur auf wenn Tx = on. Der RFM12 IRQ bleibt auf LOW (d.h. das Modul scheint sich aufzuhängen) wenn auf einen Interrupt nicht reagiert wird.
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.