SPI-Fehlerbehebung, Teensy, Arduino und Tri-State

Ich versuche, meine SPI-Bus-Geräte auf einer benutzerdefinierten Leiterplatte zum Laufen zu bringen, die ich zusammengelötet habe. Leider habe ich es versäumt, Sondentestpunkte auf dieser speziellen Platine hinzuzufügen, und glaube nicht, dass ich die SPI-Bussignale direkt an den ICs testen kann. Einer ist ein stromziehender LED-Treiber mit 20 Pins in einem SSOP-Gehäuse und der andere ist ein microSD-Kartenhalter.

Ich bekomme beide Geräte nicht zum Laufen.

Meine MCU ist ein Teensy 3.1. (Arduino-kompatibel) In Bezug auf die Firmware verwende ich Arduino v1.06 (höchste Version, die von Teensyduino unterstützt wird) und Teensyduino V1.20. Ich verwende die SPI-Bibliothek/das Objekt für die Kommunikation mit dem LED-Treiber und die SdFat-Bibliothek für die Kommunikation mit der SD-Karte.

Hier ist das Schema, wie mein LED-Treiber und die SD-Karte angeschlossen sind:

LED-Treiber Schematisch

Schema der SD-Karte

Gemäß dem TLC59025-Datenblatt sieht das Zeitdiagramm für die Kommunikation mit dem LED-Treiber folgendermaßen aus:

SPI-Timing-Diagramm für TLC59025

Meine bisherige Testmethode, abgesehen von Software (dh dem Versuch, eine Datei auf der SD-Karte zu öffnen), war wie folgt:

  • Stellen Sie sicher, dass der 3,3-V-LDO, der die SD-Karte versorgt, die richtige Spannung ausgibt
  • Es wurde versucht, die serielle Kommunikation mit der SD-Karte mithilfe der SdFat-Bibliothek zu starten (dies war ein No-Go)
  • Gemessene Spannung an verschiedenen Ausgangspins des LED-Treibers , bevor und nachdem zwei 8-Bit-Wörter an den MOSI- Pin des LED-Treibers gesendet und LE hoch gepulst wurden

Wenn der bestimmte LED-Ausgangspin verriegelt ist und Strom zieht, sollte die Spannung, die ich an diesem Pin messe, nahe 0 V liegen, richtig?

Meine Master-SPI-Taktrate liegt bei etwa 2 MHz . Ich weiß, dass der TLC59025 sagt, dass sein Arbeitspunkt 30 MHz ist . Ich dachte, solange der Master einen SCK verwendet , der niedriger ist als die Uhr des Slaves, würde die Kommunikation funktionieren. Liege ich falsch?

Ich dachte, dass vielleicht das Tri-State-Verhalten für meine Probleme verantwortlich ist, aber es sieht so aus, als ob der LED-Treiber TLC59025 so konzipiert ist, dass er immer Daten in sein Schieberegister akzeptiert, selbst wenn es nicht der beabsichtigte Slave ist, mit dem kommuniziert wird. Es sieht für mich so aus, als ob es so konzipiert ist, dass es einfach die letzten 16 Datenbits speichert, die über den SPI-MOSI-Bus gesendet werden, wenn der LE- Pin hoch gepulst wird.

Ich bin ratlos, wie ich bei der Fehlersuche vorgehen soll. Ich weiß, dass das Problem nicht am MISO-Bus liegen sollte, da ich nur ein Gerät (die SD-Karte) an diesen Bus angeschlossen habe. Könnte es der MOSI-Bus sein? Ist es möglich, dass der MOSI-Bus zu viel Kapazität hat, wenn ich versuche zu kommunizieren, wodurch das Datensignal verschlechtert wird? Wenn ich den MOSI/CS-Signalen auf der SD-Karte einen Tri-State-Puffer und dem Chipauswahlsignal der SD-Karte einen Pullup-Widerstand hinzufüge, würde dies dazu beitragen, die Signalintegrität auf dem MOSI-Bus aufrechtzuerhalten (dh die Kapazität von MOSI zu verringern Bus bis zu dem Punkt, dass zumindest der LED-Treiber funktionieren sollte?).

Gibt es wirklich keine Möglichkeit, eine Sonde hineinzustecken und sie mit einem Oszilloskop zu betrachten? Auch wenn es immer nur eine Zeile ist. Es würde das Leben so viel einfacher machen.
Heute kommt ein Oszilloskop per Post. Ich werde sehen, was für eine Probe ich am Ende bekomme.

Antworten (2)

Der Zugriff auf die SD-Karte ist etwas komplizierter, da das FAT-Dateisystem usw. berücksichtigt werden muss. Wenn ich Sie wäre, würde ich mich also zuerst darauf konzentrieren, den LED-Treiber zum Laufen zu bringen. Zumindest wissen Sie dann, dass Ihr SPI-Bus funktioniert.

Um ein paar deiner Fragen zu beantworten:

  1. Die Spannung am Ausgang eines beliebigen LED-Ausgangspins ist die Spannung, die erforderlich ist, um den programmierten Konstantstrom zu erreichen. Es sollte nicht 0 V sein, es sei denn, die Ausgänge sind auf maximalen Strom eingestellt. Und es sollte nicht die Versorgungsspannung sein, es sei denn, die LED soll aus sein.
  2. Die Tatsache, dass der LED-Treiber einen internen 30-MHz-Takt hat, sollte Sie nicht stören. Ihr Gerät ist der Master, es steuert die Uhr, und der Slave sollte die Daten basierend auf der Uhr, die Ihr Master ihm zur Verfügung stellt, eintakten. Die 30-MHz-Informationen sind nur nützlich, um die maximale Geschwindigkeit zu schätzen, mit der Sie Daten durch das Gerät übertragen können.

Ein paar Dinge zu überprüfen:

Sie erwähnen das Pulsieren von LE hoch, aber Sie erwähnen nicht das Halten von OE niedrig, um die LED-Ausgänge zu aktivieren?

Sie müssen sicherstellen, dass Sie die Hauptuhr und die Datenpins richtig konfiguriert haben. Ich bin mit Arduino-Sachen nicht vertraut, daher kann ich Ihnen hier nicht mit den Einzelheiten helfen, aber es gibt verschiedene Modi des SPI-Betriebs, und Sie müssen Ihr Gerät entsprechend einrichten. Sie müssen sicherstellen, dass Sie den richtigen Modus eingerichtet haben, um die Daten an der steigenden Flanke der Uhr auszugeben, wobei die Daten in der Mitte abgetastet werden (für den LED-Treiber - vielleicht ist es für die SD anders!).

Wo ist der Chip-Select-Pin auf diesem Gerät? Der hat doch sicher einen? Konnte es auf dem mitgelieferten Diagramm nicht sehen. Wenn es keine Chipauswahl gibt, wie wechseln Sie zwischen den Daten, die auf der SD-Karte bereitgestellt werden, und den Daten, die dem LED-Treiber bereitgestellt werden? Sie benötigen zwei SPI-Peripheriegeräte? Es sei denn, der LED-Treiber sitzt gerne einfach da und empfängt Daten, auch wenn es nicht der beabsichtigte Empfänger ist, und es liegt an Ihnen, die LE- und OE-Pins zu steuern, wenn es sich um den beabsichtigten Empfänger handelt . Es lohnt sich, sich das einfach anzusehen, um alles zu klären.

Ich bin mir nicht sicher, was aus dem SDO-Pin des LED-Treibers kommen soll? Benutzt du es?

Wie soll sich SDI auf LED-Ausgänge beziehen? Ich bemerke im Zeitdiagramm, dass SDI für die Bits 0, 2, 5, 10, 11, 12 und 15 hoch ist. Die Ausgänge 0, 3 und 15 reagieren jedoch mit einem 'ON'-Zustand. Vielleicht wird dies an anderer Stelle im Datenblatt erklärt, da es aus dem Zeitdiagramm keinen offensichtlichen Sinn zu ergeben scheint ...

Viel Glück!

Danke für die Antwort. Um einige der Fragen zu beantworten, die Sie hatten: -Der SDO-Pin am LED-Treiber dient zum Daisy-Chaining von LED-Treibern. Wenn ich zum Beispiel einen weiteren des gleichen LED-Treibers zur Platine hinzufüge und den SDO-Pin des ersten Treibers den zweiten Treiber füttern würde, hätte ich effektiv einen 32-Bit-LED-Treiber - wenn Sie die Datenbits im Zeitdiagramm rückwärts lesen , sie entsprechen dem Ausgangsstatus der verschiedenen Ausgangspins ... dh Bit 15 entspricht Ausgang 1. -Ich kann nur vermuten, dass es an diesem Treiber keinen Slave-Select-Pin gibt, sondern einen Latch-Pin
Okay, das macht Sinn. Ich würde mich definitiv darauf konzentrieren, diesen LED-Treiber zuerst zum Laufen zu bringen. Teile und herrsche, beginne mit dem Einfachsten zuerst.
Eine andere Sache: Die Spannung an den Ausgangspins des LED-Treibers sollte hoch sein, wenn die LED ausgeschaltet ist, da es sich um einen stromsenkenden Treiber handelt . Wenn Sie möchten, dass die LED eingeschaltet wird, ändert der Treiber dann seinen Widerstand an diesem Pin, bis ein benutzerdefinierter Strom durch ihn fließt. Daher würde ich annehmen, dass der Widerstand eines aktivierten Pins Null wäre, wenn dieser Pin aktiviert ist, ohne dass eine tatsächliche LED angeschlossen ist (dh es wäre dasselbe wie bei einem Kurzschluss gegen Masse). Sieht jemand irgendwelche Fehler in dieser Annahme?
Ah okay - in diesem Fall steht meine Antwort immer noch, außer dass der "Aus" -Zustand umgekehrt ist. Der "Ein"-Zustand wird immer noch die Spannung sein, die erforderlich ist, um den programmierten CC zu erreichen. Wie Sie sagen, wenn keine LED angeschlossen ist, sollte der Ausgang ganz auf '0 V' treiben, um zu versuchen, den Konstantstrom zu erreichen. Ich stimme Ihrer Einschätzung diesbezüglich zu. Ich hoffe, Sie bekommen das zum Laufen!
Der Weg des geringsten Widerstands zum Debuggen besteht hier darin, die clk/data-Leitungen zu erweitern und sicherzustellen, dass sowohl die Daten als auch das Timing der Daten Ihren Erwartungen entsprechen.

Also bekam ich mein Oszilloskop per Post, richtete es ein und schaffte es, die Sonden vorsichtig an die Teensy 3.1 MCU-Pins für SPI und meinen LED-Treiber (dh SCK-Pin und MOSI-Pin) anzuschließen.

Es scheint, als ob das Problem bei der SPI-Bibliothek liegt, die ich verwendet habe.

Der MOSI-Pin ging für das zweite Byte nicht hoch, als ich versuchte, zwei aufeinanderfolgende Bytes in den Treiber zu schreiben. Ich konnte die Ausgänge der Pins 8-15 des LED-Treibers so einstellen, dass sie aktiviert werden, aber ich konnte den MOSI-Pin anscheinend nicht dazu bringen, während des zweiten Byte-Schreibvorgangs hoch zu gehen.

Ich konnte das Problem lösen, indem ich eine Verzögerung von etwa 10 ms zwischen den beiden Byte-Schreibvorgängen hinzufügte.

Ich konnte die Geschwindigkeit weiter optimieren (so dass ich zwischen Byte-Schreibvorgängen nicht 10 ms warten musste), indem ich die Methoden SPI.beginTransaction() und SPI.endTransaction() der SPI-Klasse verwendete.

Indem ich jede Byte-Übertragung in diese Transaktionsmethoden einpackte, konnte ich den LED-Treiber zum Laufen bringen. Hier ist die Art der Codestruktur, die für mich funktioniert hat:

SPI.beginTransaction(LEDDriverSettings);
SPI.transfer(firstByte);
SPI.endTransaction();
SPI.beginTransaction(LEDDriverSettings);
SPI.transfer(secondByte);
SPI.endTransaction();