Hallo, zunächst einmal ein Lob an das Forum. Sehr informativ. Ich habe ein Problem mit dem SJA1000. Meine Konfiguration entspricht der Standardbeschaltung mit Optos und einem 82C250 als Bustreiber. Derzeit habe ich nur diesen einen Knoten, d. h. mir bleibt nur der Self-Test-Modus zum Testen. Aber genau da liegt mein Problem. Nach dem Hardware-Reset und der Installation (16 MHz, Accept aus, Normal-Output,PeliCAN, Timing-Register für 250 kBit/s im One-Sample-Mode, RX-Int) funktioniert der Self-Test wunderbar. Das Beschreiben des TX-Buffers klappt, das Rücklesen aus dem Spiegelregister des TX zeigt die korrekten Daten. Nach dem Self-Request im Single-Shot kommt ein RX-Interrupt, RXFIFO zeigt korrekte Daten an, Spiegel-Register im internen RAM-Bereich auch, RXStartAddr stimmt. Alles super..... Denkste.... Ab dem zweiten Sendeversuch geht alles drunter und drüber. Daten im TX-Spiegelregister werden mal mit, mal ohne Frameinfo angezeigt, der Rest der Daten stimmt. RXFIFO zeigt falsche Daten an, im RX-Spiegelregister (RAM) liegen die Empfangsdaten häufig, aber nicht immer, an einer anderen Stelle...RXStartAddr stimmt also nicht. Wenn die RXStartAddr allerdings in den letzten vier Bits 0 oder 8 anzeigt, funktioniert das Ding wunderbar. Ich bin zunächst nicht über das Problem gestolpert, da ich als Testdatensatz immer eine Nachricht von genau 8 Byte (Frame+ID+Daten) gesendet hatte. Dann funktioniert das immer wunderbar, auch mit sich ändernden Einzeldaten. Jetzt erzeuge ich Zufallszahlen für die Anzahl der Daten und die Daten selbst (inkl. ID) und schon klappts nur solange, wie die RXStartAddr den genannten Adr-Teil zeigt. Ich sollte auch noch erwähnen, dass das Ding bei "korrekter" RXStartAddr unabhängig von den 8 Byte immer zum Erfolg führt. Erst wenn dann nach einem BufferRelease die neue RXStartAddr nicht 0 oder 8 in den letzten vier Bits zeigt funktioniert es nicht mehr. Kennt jemand das Problem? Gruß, Thomas
Welcher Controller und wie angeschlossen ? Liest Du die Daten im Interrupt aus ? Otto
Hallo Otto, ich benutze den IPC SC13 (80186), also mit Intel-Interface. Der Interrupt wird über einen 8259 ausgewertet, wie bei einem PC. Gruß, Thomas
Hallo Thomas, > ich benutze den IPC SC13 (80186), also mit Intel-Interface. > Der Interrupt wird über einen 8259 ausgewertet, wie bei einem PC. da kann ich leider nichts zu sagen.... Es ist aber so, dass Du die empfangene Botschaft im RX-RAM nur solange "vernünftig" lesen kannst, solange nur eine einzelne Botschaft eintrifft (Die Adressen an denen die RX-Daten liegen, ändern sich durch das FIFO). Ein sinnvoller Betrieb ist bekanntlich auch nur mit mindestens 2 Knoten möglich. Otto
Hallo Otto, erst einmal Danke. Aber wenn ich über die INT-Routine den RX-Buffer auslese, dann einen BufferRelease sende und danach erneut sende müsste es doch funktionieren. Was mir heute noch aufgefallen ist, ist, dass vom SJA im Self-Test-Mode imer 16 Bytes und nicht maximal 13 versendet und empfangen werden. Ich hatte mal nach einem Hardwarereset genau 8 Bytes (Frame+ID+Daten) versendet und siehe da, die nächsten 8 Byte im RX-Buffer waren immer 0. Neues Senden (Klappt ja, da genau 8 Bytes versendet werden) und siehe da, die Nachricht wird richtig mit Interrupt und RXStartAddr empfangen und die nächsten 8 Byte im RXBuffer (internes RAM) wieder null, und so weiter..... Kann mir das nicht erklären. Gruß, Thomas
Hallo Thomas, ja, dann sollte es - ich habe es nur geschrieben, weil ich anfangs zu Debug-Zwecken den Inhalt des RX-RAM ausgegeben hatte und die Anzeige hier nur solange stimmte, wie ich eine einzelne Botschaft sendete. Allerdings habe ich es relativ schnell aufgegeben, im "Self-Test-Modus" zu arbeiten und einen 2. Knoten verwendet (CAN232 von Elektronikladen), mit dem über HT sowohl einzelne Botschaften als auch Logs eines Trafic gesendet werden können. Dann klappte auch alles wie erwartet. Ich drücke Dir die Daumen.... Otto
Hallo Otto, danke, dann werde ich mir den wohl auch zulegen müssen..... Gruß, Thomas
> Ab dem zweiten Sendeversuch geht alles drunter und drüber... So ein Problem hatte ich auch mit dem SJA1000. Dann bin ich im CAN Forum von Jahuu auf einen Fred gestoßen der besagt, dass man TX1 nicht einfach offen floaten lassen soll. Also habe ich einen Pull-Down Widerstand angeschlossen und der Fehler war verschwunden. Werner
Hallo Werner, Danke für Deinen Tipp, hat das Problem aber leider nicht gelöst. Hat noch jemand eine andere Idee? Gruß, Thomas
Bitte 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.