LIN-Tranceiver ATA6662 blockiert

[Daniel S. (daniel_s49)]

Hallo,

ich habe ein Problem, bei dem ich mich nun seit fast einer Woche auf der 
Stelle drehe und langsam keine Ideen mehr habe.

Ich habe ein Sensorboard, welches über einen LIN-Bus mit einem 
Steuergerät reden soll. Auf dem Sensorboard sitzt ein ATMega88 für die 
Steuerung und ein ATA6662 als Bustranceiver. Der Tranceiver wird über 
die UART des Mikrocontrollers angesprochen.

Um Strom zu sparen, lege ich den Tranceiver in den Schlafmodus 
(Enableleitung low). Laut Datenblatt sollte er nun von alleine 
aufwachen, sobald ich entweder die Enableleitung wieder auf high setze, 
oder aber Traffic auf dem Bus ankommt. Das funktioniert auch in den 
meisten Fällen. Genau hier liegt mein Problem. Hin und wieder starte ich 
das Steuergerät, dieses schaltet den Bus ein (12V, GND, Datenleitung) 
und der Sensor bootet. Der Sensor blockiert dann aber auf mysteriöse 
Weise und lässt sich nicht über den Bus ansprechen und ich bekomme auf 
dem Sensor auch keine Interrupts der UART. Der Mikrocontrollers des 
Sensorboards funktioniert aber ansonsten (LED blinkt - leider meine 
einzige Debug Möglichkeit).
So langsam gehen mir die Ideen aus. BrownOut ist es nicht, 
Versorgungsspannung passt, Taktfrequenzen passen, die Software für das 
Busprotokoll ist getestet, ... und trotzdem blockiert die Kommunikation 
manchmal und lässt sich nur durch einen Neustart des Sensors wieder 
aufnehmen.

Hat vielleicht jemand Erfahrung mit dem ATA6662 und hat da noch eine 
Idee, wieso er aus dem Schlafmodus nicht wieder aufwacht, wenn die 
Buskommunikation beginnt?

Ich weiß, dass das sehr vage formuliert ist, aber ich stocher leider 
auch immer noch im Nebel und hab da nicht wirklich einen Ansatz. Jede 
Idee (auch wenn sie noch so bescheuert klingen mag) ist willkommen.

Grüße
Daniel

[Soul E. (Gast)]

Hast Du nur Probleme mit dem Wecken über den Bus, oder lässt sich der 
Transceiver auch lokal nicht einschalten? Grundsätzlich gibt es da 
mehrere Fallen:

* das Wecksignal ist ein Puls, und der kommt genau einmal. D.h. wenn der 
Transceiver weckt und Dein Controller hat gerade die Interrupts 
deakiviert, Pech gehabt. Du kannst allerdings zusätzlich die INH-Leitung 
pollen, die bleibt dauerhaft aktiv.

* Der ATA6662 hat ein "Feature". Kurz vor Unterspannung hat er die 
Ausgangsstufen bereits deaktiviert, die interne Logik läuft aber noch. 
Diese setzt den Weckpuls ab, mangels aktiver Ausgangstreiber merkt der 
Controller da aber nichts von. Das ganze passiert nur in einem kleinen 
Bereich um VS = 4,80 V. Darüber und darunter ist alles in Ordnung.

Die APN http://www.atmel.com/Images/doc9155.pdf ist öffentlich 
zugänglich. Da steht das Ganze vorsichtig formuliert drin.


Für Neuentwicklungen sollte der Nachfolgetyp ATA6663 / 6664 verwendet 
werden. Der hat zusätzlich die Vorteile

* 8kV ESD statt 6kV
* INH-Pin hat Rds, on = 50 Ohm statt 1,5kOhm (für diejenigen, die damit 
den Master-Widerstand schalten)
* INH-Pin ist kurzschlußfest



HTH

[Daniel S. (daniel_s49)]

ein bisschen Zeit ist noch vergangen, aber am Ende hat sich das Rätsel 
dann doch noch gelöst. Für den Fall, dass in Zukunft irgend jemand ein 
ähnliches Problem haben sollte, schildere ich meine Erkenntnisse mal. 
Vielleicht dient es ja jemandem als Denkanstoß.

Die Idee, dass ich den Puls am Anfang verpasse, war richtig. Die 
INH-Leitung war bei meinem Board aber nicht verbunden, so dass die 
Polling-Variante ausfiel.
Problem war ein kleiner Fehler beim Start, der durch unglückliches 
Timing diese Situation erzeugte:
Der Bus versorgt mein Sensorboard mit Strom und Tranceiver und 
Mikrocontroller starten gleichzeitig. Da der Mikrocontroller erstmal ein 
paar ms auf einen stabilen Takt wartet, ist der Tranceiver schon fertig 
hochgefahren, während die TX-Leitung vom Mikrocontroller noch auf low 
steht. Irgendwann ist der Mikrocontroller fertig und gibt einen 
Enable-Puls an den Tranceiver, um diesen aus dem FailState-Mode in den 
Sleep-Mode zu versetzen. Dummerweise (und hier lag der Fehler) tut er 
das ohne TX vorher auf high zu ziehen.
Der Tranceiver behandelt das deshalb als Sendeversuch und zieht an der 
Datenleitung vom Bus. Wenn Board A das macht, sieht Board B damit 
"Traffic" auf dem Bus, zieht die RX-Leitung low und genau das bekomme 
ich nicht mit (sei() kommt später). Board B hing damit für immer im 
"Warte auf Buskommunikation"-Modus und hat auf den Interrupt gewartet.

Spannend daran war, dass dieser Fehler in zig Boards implementiert war, 
aber nur bei zweien Auswirkungen hatte (weswegen ich erst mal nicht so 
sehr in Richtung Software gesucht habe). Stellt sich raus, dass der 
Tranceiver einen Timeout von 6-20ms besitzt, der ihn quasi deaktiviert, 
wenn die TX-Leitung zu lange low ist (Datenblatt lesen lohnt sich immer 
wieder: TXD Dominant Time-Out Function). Alle anderen Boards brauchen 
länger als 20ms zum Starten und einzig meine beiden fehlerhaften liegen 
bei 7ms rum.
Sprich, alle Boards machen den Enable-Puls während TXD noch low ist, 
aber nur bei meinen beiden schlägt das auf die Datenleitung vom Bus 
durch. Bei allen anderen ist der Tranceiver durch den Timeout 
deaktiviert und damit hat das keine Auswirkungen auf den Bus. Vermutlich 
gehen die anderen dann zwar nicht in den Schlafmodus, aber immerhin 
hängen sie nicht im Deadlock.

Schön insg. eine Woche Zeit verbracht um einen Fehler zu finden, den ich 
glücklicherweise nicht selbst programmiert hatte :-D