Forum: Mikrocontroller und Digitale Elektronik Keine Open Load Meldung bei ata6836c und IFX9201SG!


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Steffen D. (stdue)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich habe 2 Treiber mit Halbbrücken im Einsatz und bei keinem 
funktioniert anscheinend die Open-load Erkennung.
1) IC Atmel ata6836c, läuft über SPI-Bus an einem PIC18F44K22.
Über OUT1-OUT3 und OUT4-6 sind jeweils 2 Motoren angeschlossen. Alle 
Kommando-Ausgaben (leider 16Bit von bit0..15 gespiegelt erforderlich) 
und Fehlermeldungen bzgl. Kurzschluss funktionieren, also SPI Bus über 
Register SSP2BUF ist okay. Leider kommt niemals eine Statusänderung bei 
einen offenen Ausgang an den aktiven Ports, weder mit gesetzten OLD Bit 
(OL inaktiv) noch mit aktivierten OL über Bit13 = 0.
Auf Bit15-0 = 1010 0000 0101 001 1 (OUT3/2/1 = 1/1/0, OLD gesetzt = OL 
inaktiv) kommt als Status immer 0x0052. Mit OL aktiv (Bit13=0) kommt 
zwar 0x0AD2, d.h. die Bits LS1..LS3 sind alle gleich, nur bei LS4,5,6 
sind dann die LSx Bits gesetzt, was aber nichts heisst, da laut 
ATANN0013 S.5 bei Connected beide HS an den aktiven Ausgängen 1 sein 
sollen und wenn Open dann nur ein Hx=1 und der andere Hy auf 0. Das ist 
aber alles egal, da dann bei einer beliebig getrennten Leitung zu den 
Motoren immer genau die gleichen States für OUT1,2,3 gemeldet werden.
2) Einfacher sollt es mit einem IFX9201SG sein, da nur OUT1/2 und direkt 
eine Statusmeldung DIA4-DIA1 = 0x0C den Openload-Zustand melden soll, 
das erfolgt aber auch nicht. Wenigstens muss man da die Bits nicht noch 
im 8Bit System ständig spiegeln. Die SPI Ansteuerung ist auch okay, da 
die anderen Stati für Short nach GND und Vs usw. richtig gemeldet 
werden. Es wurde mit Motoren, Glühlampen und Festwiderständen alles 
probiert, eine offene oder mehrere offene Leitungen wurden nie erkannt.
Was kann da prinzipiell falsch sein? Kämpfe da schon eine Woche, auch 
mit Abfolgen von OLD=1/0/1 Kommandos hintereinander usw. Der Microchip 
Debugger ist bekanntlich auch nicht hilfreich, da u.a. ständig bei gar 
nicht eingegebenen unsichtbaren Breakpoints angehalten wird, ständig USB 
am ICD3 abgezogen und wieder gesteckt werdenm muss usw. Das ist leider 
alles mehr als mühselig.
Ist die Dokumentation der IC da ev. fehlerhaft, vor allem beim ata8636? 
Direkt zu den IC findet man absolut nichts in Foren, nur immer die 
Datenblätter. Auch das spezielle 
Atmel-9251-ATA6836C-ATA6838C-Open-Load-Detection_Application-Note.pdf zu 
OpenLoad vom Atmel (lies sich nicht mehr anhängen) half da nicht.
Danke für einen jeden Tipp.
Steffen

von Steffen D. (stdue)



Bewertung
0 lesenswert
nicht lesenswert
Jetzt auch
Atmel-9251-ATA6836C-ATA6838C-Open-Load-Detection_Application-Note.pdf
angefügt. Problem immer noch nicht gelöst, trotz 100er Versuche!

: Bearbeitet durch User
von Steffen D. (stdue)


Bewertung
0 lesenswert
nicht lesenswert
Nach wie vor wird bei mir kein OpenLoad erkannt, hat niemand eine 
Lösung? Egal mit welchem Controller?
Danke
Steffen

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Zeig mal den Schaltplan.
Ich bin mir sicher, dass hier der Hund begraben ist.
Hast du dir die Funktion mal angeschaut, wie OL detektiert wird? Da wird 
ein Strom in den Ausgang eingeprägt.
Wenn du an den Motorleitungen noch einen Spannungsteiler hast, damit du 
die Spannungen zurück lesen kannst, dann hast du bei abgetrenntem Motor 
kein OL.
Wie sieht die Beschaltung am Ausgang der ICs bis zum Motor aus.

Und bitte Bilder und kein Text mit 1000 Worten, bei dem dann das 
Wesentliche fehlt.

von Steffen D. (stdue)


Bewertung
0 lesenswert
nicht lesenswert
Danke Jens für endlich mal eine Antwort. Bild kann ich mir sparen, auch 
1000 Worte ;-) deswegen. Es sind wirklich nur jeweils 22nF dran, gegen 
Masse. So einfach ist das leider nicht. Auch kein MOSFET etc. ist da 
dran, da Motoren direkt nur ca. 200mA ziehen. Müsste irgendwie am Code 
für OL liegen. Egal was ich sende, der rückgemeldete Status ist immer 
gleich, ob Ausgang offen oder R dran. Habe auch schon direkt am IC den 
Draht abgelötet. Motoren laufen, auch Kurzschlusserkennung usw., also 
SPI sollte okay sein.

Sende 0b1100000000000001 (wird gespiegelt übergeben in Funktion unten 
wegen 2x 8Bit), aber sogar auch schon mit Bit Reset = 0 und OLD=1 
probiert, falls Dokufehler! Bekomme meist mit und ohne Motor 0x0AAA 
zurück.

uns16 FKT_writeSSP2_SP(uns16 cmd)
{
    uns16 status16 = 0u;
    uns8 status1 = 0u;
    uns8 status2 = 0u;
    uns8 send_cmd_low = 0u;
    uns8 send_cmd_high = 0u;

    //Baustein CS=0 aktiv
    CLR_PORT(M_CS); // CS >=16clocks low für OLD!? (s. ATAN0013 S.3 )

    //Code wird voher von Bit 0-15 gespiegelt für 8Bit senden.
    //Low 1. Teil
    send_cmd_low = (uns8) (cmd >> 8) ; //Status Bit0 First In
    //SSR Reset, Bit0 gespiegelt = Bit15 setzen

    //High 2. Teil
    send_cmd_high = (uns8) (cmd & 0x00FF);


    /* WRITE SPI */
    SSP2CON1bits.WCOL = 0;
    SSP2BUF = send_cmd_low;         // write to buffer for TX
    while (SSP2STATbits.BF == 0u);  // wait for transfer to complete
    status1 = SSP2BUF;  //Bit0 zuerst

    NOP();
    NOP();
    NOP();   //Wartezeit: WICHTIG, muss wohl sein vor senden HighByte!

    SSP2CON1bits.WCOL = 0;
    SSP2BUF = send_cmd_high; // write to buffer for TX
    while (SSP2STATbits.BF == 0u);
    status2 = SSP2BUF;

    SET_PORT(M_CS); //Disable ATA6836

    //Spiegeln für Bit16-0 Ansicht, statt Bit0-16
    status1 = FKT_bits8_spiegeln(status1); //Low Byte
    status2 = FKT_bits8_spiegeln(status2); //High Byte
    //16Bit Status zusammensetzen, 2x 8Bit
    status16 = (status2 * 256) + status1;
    return status16; //Wird später in Diagnosemodul ausgewertet
}

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Du spiegelst deine Werte nicht!

Was du brauchst ist die Reihenfolge: Bit0...Bit15
Was du tust ist aber kein Spiegeln, sondern du machst einen Swap von 
Highbyte und Lowbyte.

Deine Reihenfolge ist: Bit7...Bit0, Bit15...Bit8.

Du musst aber einen Code haben, der Bit15 mit Bit0 vertauscht und Bit14 
mit Bit1 und so weiter.

Mach nicht sowas: cmd = 0b1100000000000001
Schreibe die Bits aus, die du setzen willst. Schau mal in die 
Artikelserie für die Bitszugriffe. Also eher sowas: cmd = 
(1<<OL_DETECTION);
Und in den defines steht dann die Bitposition drin.
Also #define OL_DETECTION  2

Dann kannst du die Bitzuordnung in den Defines so anpassen, dass du in 
der Funktion zum Senden keine Bits mehr tauschen musst. Einfach die 
Bitpositionen aus dem Datenblatt abzählen. Da rein und fertig.

Das sollte funktionieren.

Und dann messe (Oszi, Logic Analyser,...) dass auch der Transfer zum 
Chip so aussieht wie du es gerne hättest. Aber das MUSST du MESSEN.

Grüße, Jens

von Steffen D. (stdue)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,
also in die oben abgebildete Funktion gebe ich die Werte schon 
gespiegelt ein, deswegen passt das schon was ich sende, alle 6 Outputs 
für die Motoren funktionieren ja auch richtig darüber. Habe auch eine 
ausgiebig getestete BitsSpiegeln() Funtion, die das mit 8 oder 16 Bits 
macht. Das ist nicht das Problem, Bits setzen auch nicht, da fertige 
#Defines für die Kommandos die sich nicht ändern. Mal mit und mal ohne 
OLD Bit.

Problem ist das einfach die OpenLoad Erkennung nicht funktioniert bzw. 
dazu die Statusmeldungen nicht passen.
In einer speziellen Testfunktion (wenn Motoren nicht laufen sollen) 
schalte ich alle 6 OUTx (inklusive OLD=0) einzeln ein und prüfe dann die 
Nachbar-OUTx auf 0. Mit U messen klappt das. Also schalte bspw. OUT2 auf 
12V ein, über die 2 Motoren nach OUT1 und OUT3 hat man dort auch die 
12V, solange angeschlossen. Trenne ich dort die Leitungen, misst man 
natürlich 0V an OUT1 und OUT3, nur an OUT2 die 12V, aber am Status aus 
dem ATA kann ich da nichts sicher erkennen. Mal kommt 0x152A, mal 0x0054 
= völliger Blödsinn die ich ausblende. Dann aber auch mal, bei voll 
angeschlossenen 4 Motoren je zwischen OUT1-2, OUT2-3, OUT4-5 und OUT5-6 
(2 Spiegelverstellungen links-rechts, hoch-runter), ein 0A94 (also 
HS1=HS2=LS4(!) mit "1". Eigentlich müsste ja auch HS3 in Bit6 gesetzt 
sein usw. Wenn alles gut kommt auch oft richtig 0x0AAA.
Ich weis nicht was noch machen. Ich wechsle jetzt nochmal die Platine. 
Noch eine Idee? Bei diese ATA6836 steigen übrigens auch 2 von 10 bei 
Dauertests im KS bei 85°C und mit je nur 5s 500mA je OUT reihum Last 
aus. Die Ausgänge springen dann wild ein und aus, ohne eine 
Fehlermeldung wegen Übertemp. oder Überstrom. Senkt man die Temp. auf 
unter 60°C geht es wieder. Auch halbe LAst mit 250mA hilft bei 85°C 
nicht. Dann mit Fön auf über 100°C erhitzt erkennt meine SW die 
Übertemp. Meldung TP korrekt! Also macht alles den Eindruck sehr 
unzuverlässig. Übrigens ein Testkit dazu (Mouser 180€ !) gibt es schon 
seit über 10Jahren, geht aber nicht unter Win 64bit und Ansteuerung der 
SW über LPT Druckerschnittstelle!!! Wer hat noch sowas? Also das Ganze 
wird auch nicht weiter gepflegt anscheinend! Bei weiteren Entwicklungen 
werden wir also sicher nie wieder diese Familie von Atmeltreibern 
einsetzen.
Danke

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.