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
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.
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
}
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
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
