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
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
Nach wie vor wird bei mir kein OpenLoad erkannt, hat niemand eine Lösung? Egal mit welchem Controller? Danke 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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.