sja1000: Reset mode

[tilman (Gast)]

Hallo

Problem:
========
Der SJA 1000 läßt sich nach dem Initialisieren und Lesen/Schreiben einer 
Can-Message nicht in den Reset-Mode zurückschalten. Ich setzt das 
Reset-Bit, indem ich in das Mode-Register(Adresse 0) 0x01 schreibe. Dann 
polle ich das Reset-Bit einmal pro us über eine Zeitdauer von 1 ms. 
Leider wird aber nur 0x00 zurückgelesen (Reset-Bit nicht gesetzt).

Frage:
======
Es scheint, als würde der SJA1000 sich "aufhängen". Sind im Forum 
möglicher Weise die Bedingungen bekannt, die das beobachtete Verhalten 
auslösen können ? Kann es zum Beispiel mit dem Timing bei der Bedienung 
der parallelen Schnittstelle des SJA1000 zusammenhängen ? Vielleicht ist 
der Chip defekt ?


Hintegrundinfos
===============
Modus: Pelican
Betriebsystem: Linux (Treiber als Kernel-Modul)
Treiber: Der Treiber basiert auf dem PCAN-Treiber von Peak Systems. Ich 
verwende keinen PCI-Bus, so dass ich die untere Schicht des Treibers 
ersetzen musste (statt Zugriff auf PCI, Zugriff auf ein VME-ähnliches 
Bussystem).  Der Treiber an sich sollte aber funktionieren.


Ablauf im Treiber:

1) Initialisieren:
Es wird überprüft, ob ein SJA1000 vorhanden ist. Dann wird er in den 
Reset-Mode geschaltet, und anschliessend in den Pelican-Modus. Im 
nächsten Schritt werden die Acceptance-Code-Register und die 
Acceptance-Mask-Register auf die Default-Werte gesetzt (0 bzw 0xff). 
Dann wird eine BaudRate von 500 kbit/s für den CAN eingestellt und das 
Output Controll Register konfiguriert. zuletzt wird die Interrupts 
eingeschaltet.

2) Tx/Rx einer Can Message:
Anschliessend wird entweder auf eine CAN-Message (wird über 
Interrupthandler gelesen) gewartet, oder eine Can-Message gesendet.

3) Aufräumen:
Der Befehl "Abort Transmission" (Setzen des Bit 1 in Register 0x1) 
beendet die Übertragung. Anschliessend werden die  Interrupts 
ausgeschaltet.
Dann soll der SJA1000 wieder in den Reset-Mode gehen (durch Sezten des 
Reset-Bits im Mode-Register). Das verweigert er allerdings (siehe auch 
Anhang). Auch ein erneutes Initialisieren ist nicht möglich

4) Nach Ein- und Ausschalten der Versorgungsspannung kann im Rahmen der 
Initialisierung wieder in den Reset-Mode geschaltet werden.

Ich schicke gerne auch noch detaillierte Informationen, wenn benötigt.

Danke
Tilman

[Lehrmann M. (ubimbo)]

BTT sorry jetzt mal zum Problem:

tilman schrieb:
> Es scheint, als würde der SJA1000 sich "aufhängen".

Woran konkret machst du das fest? Nur daran, dass du 0x00 
zurückbekommst?

tilman schrieb:
> Sind im Forum
> möglicher Weise die Bedingungen bekannt, die das beobachtete Verhalten
> auslösen können ?

Wie sieht es hardwaretechnisch aus? Schirmung, Abblocken, 100nF ? Bitte 
Schaltplan posten.

tilman schrieb:
> Kann es zum Beispiel mit dem Timing bei der Bedienung
> der parallelen Schnittstelle des SJA1000 zusammenhängen ?

unwarscheinlich

tilman schrieb:
> Vielleicht ist
> der Chip defekt ?

Dann würde garnichts mehr funktionieren ... sehr sehr sehr 
unwarscheinlich.

tilman schrieb:
> Dann wird eine BaudRate von 500 kbit/s für den CAN eingestellt und das
> Output Controll Register konfiguriert.

die Baudrate muss im gesamten System identisch sein (weißt du ja 
hoffentlich)

tilman schrieb:
> Dann soll der SJA1000 wieder in den Reset-Mode gehen (durch Sezten des
> Reset-Bits im Mode-Register). Das verweigert er allerdings (siehe auch
> Anhang). Auch ein erneutes Initialisieren ist nicht möglich

Gibt es lt. Datenblatt Gründe die dies verhindern könnten? Wenn ja 
welche ?

[tilman (Gast)]

Hallo Michael,

>> Es scheint, als würde der SJA1000 sich "aufhängen".
>Woran konkret machst du das fest? Nur daran, dass du 0x00
>zurückbekommst?
Ja, genau

>Wie sieht es hardwaretechnisch aus? Schirmung, Abblocken, 100nF ? Bitte
>Schaltplan posten
Schaltplan anbei

>die Baudrate muss im gesamten System identisch sein (weißt du ja
>hoffentlich)
Ist sie -- beim ersten Durchlauf kann ich eine gesendete CAN-Message mit 
weiteren CAN-Controller korrekt empfangen. Erst beim Versuch die zweite 
Message zu senden beobachte ich das beschriebene Verhalten.

Noch ein Hinweis: Ich habe die Logik im FPGA erweitert, die die 
Steuersignale für den SJA1000 erzeugt (Ich habe ein zusätzliches 
Register eingebaut. Es hat nichts direkt mit der Logik des SJA1000 zu 
tun). Seitdem kann ich das beobachtete Verhalten regelmässig 
reproduzieren. Davor trat es sporalisch auf. Die Erweiterung könnte die 
Signallaufzeiten im FPGA beeinflusst haben -- deswegen habe ich an ein 
Timingproblem gedacht. Die Adressen und Daten werden jedenfalls alle 
richtig an den SJA1000 gegeben -- das habe ich mit dem Logikanalyzer 
überprüft.

Wenn ich so  darüber nachdenke gibt es eine zweiter Änderung: Ich die 
Adresse 63 des SJA1000 in ein Register des FPGA umgemappt: Beim 
Schreiben/Lesen wird der AS-Impuls für den SJA100 erzeugt. Auch die 
Adresse 63 liegt an den gemultiplexten Adress/Datenleitung des SJA1000 
an. Ein Datentransfer (CS-Impuls + E-Impuls) folgt dann aber nicht 
mehr,d.h. der nöchste Zugriff auf den SJA1000 beginnt dann wieder mit 
der Übertragung einer Adresse.
Der Zugriff auf Adresse 63 erfolgt allerdings ganz am Anfang -- wenn es 
ein Problem wöre würde bereits das Senden der ersten Can-Message 
scheitern.

Ich probiere im nöchsten Schritt , nach jedem Zugriff auf den SJA in den 
Reset-Mode zugehen. Vielleicht kann ich das Problem durch die Stelle 
innerhalb der Startsequenz, an dem sich der Wechsel in den Reset-Mode 
nicht mehr vollziehen läßt, isolieren und lösen.

Für weitere Lösungsansätze bin ich offen :-)

Danke
Tilman

[tilman (Gast)]

Hallo nochmal

ich habe mich auf die FPGA-Logik konzentriert. Dort habe ich die letzte 
Änderung durchgeführt. Ich habe den Fehler auf Reset-Logic für den SJA 
im FPGA-Code isoliert. Nun funktioniert der Teil zumindest, d.h. ich kan 
CAN-Message lesen und schreiben. Auch das Reset-Bit lässt sich 
zurücksetzen.

Das Reset-Bit  läßt sich dann nicht zurücksetzten, wenn der RESET-Pin 
des SJA1000 aktiviert ist - wie zum Beispiel durch eine fehlerhafte 
Reset-Logic in einem FPGA.

Viele Grüsse und Vielen Dank für's Nachdenken

Tilman