SPI-Schnittstelle gibt nur Einsen zurück (0xFF)

Ich versuche, ein SPI-Gerät auf meinem Angstrom Linux (Kernel-Version 3.10) zu registrieren, um einen ADC-Chip (LTC2258) für mein benutzerdefiniertes Board zu verwenden. Der Prozessor, den I2m verwendet, ist Cyclone V, und die FPGA-Übergaben scheinen korrekt zu sein (SPI Master 1 wird an HPS übergeben). Also habe ich meine .dtb-Datei wie folgt bearbeitet:

        spi@0xfff01000 {
        compatible = "snps,dw-spi-mmio-15.0", "snps,dw-spi-mmio";
        reg = <0xfff01000 0x100>;
        interrupt-parent = <0x3>;
        interrupts = <0x0 0x9b 0x4>;
        clocks = <0x21>;
        #address-cells = <0x1>;
        #size-cells = <0x0>;
        bus-num = <0x0>;
        num-chipselect = <0x4>;
        status = "okay";

        spidev@0 {
            compatible = "spidev";
            reg = <0x0>;
            spi-max-frequency = <0x5f5e100>;
        };

    };

Beim Kernel-Boot sagt es nur Folgendes über SPI:

root@cyclone5:~# dmesg | grep -i spi 
[    0.652554] dw_spi_mmio fff01000.spi: master is unqueued, this is deprecated

Aber spidev0.0der Eintrag erscheint unter /dev. Mit dem Standardprogramm spidev_testsehe ich diese Ausgabe:

root@cyclone5:~# ./spi_d -D /dev/spidev0.0 
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)

FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF 

Und da ist die Sache: Die SPI-Schnittstelle dieses ADC wird zur Konfiguration verwendet. Der Testfall für mich besteht also darin, Konfigurationswerte in Register mit angegebenen Adressen zu schreiben und sie erfolgreich zurückzulesen. Also ändere ich den tx-Puffer aus dem Quellcode; Ich schreibe und lese die Register zurück. Aber es gibt mir das gleiche Ergebnis, volle FFs.

Im Datenblatt von ADC steht:

  • Daten werden mit einem seriellen 16-Bit-Wort in ein Register geschrieben. Daten können auch aus einem Register zurückgelesen werden, um seinen Inhalt zu überprüfen.
  • Das erste Bit des 16-Bit-Eingangsworts ist das R/W-Bit. Die nächsten sieben Bits sind die Adresse des Registers (A6:A0). Die letzten acht Bits sind die Registerdaten (D7:D0). Wenn das R/W-Bit niedrig ist, werden die seriellen Daten (D7:D0) in das durch die Adressbits (A6:A0) gesetzte Register geschrieben. Wenn das R/W-Bit hoch ist, werden Daten in dem durch die Adressbits (A6:A0) gesetzten Register auf dem SDO-Pin zurückgelesen

Also habe ich den Code entsprechend angepasst. Ich verwende meinen modifizierten spidev_test mit diesen Parametern:

./spi_d2 -D /dev/spidev0.0 -b 16 -s 100000000

Aber wie ich schon sagte, das Ergebnis ist voll. Auch das Ändern von Parametern Bits pro Wort wirkt sich nicht auf das Ergebnis aus.

Wie kann ich das debuggen? Wo soll ich suchen? Jede Hilfe ist willkommen. Vielen Dank im Voraus.

Nur für den Fall ... Haben Sie Ihr SPI-Protokoll für Ihr Terminal/Ihre SW bestätigt und das Gerät stimmt überein? SPI ist kein Standard (z. B. IEEE) und erfordert daher normalerweise die Einstellung einiger Parameter. Vielleicht spi mode: 0passt das für dich (?)
@CapnJJ Ja, das habe ich. Eigentlich habe ich sie nach dem Zufallsprinzip geändert, um die Reaktion zu sehen. Aber nichts hat sich geändert.

Antworten (3)

Es stellte sich heraus, dass ich über den Chip-Select-Pin des ADC falsch informiert war. Das Ändern des Werts des untergeordneten Spidev-Knotens regauf 1 löste das Problem. Letzte Parameter, die ich verwende, sind:

./spi_d -D /dev/spidev0.1 -b 16 -H -O

Entschuldigen Sie die Zeitverschwendung und danke für Ihre Hilfe!

Schließen Sie einen Logikanalysator oder ein Oszilloskop an, um zu sehen, ob sich die Signale tatsächlich ändern (CS, SCK und MOSI), und verbinden Sie dann MOSI mit MISO, um zu sehen, ob Sie empfangen können, was Sie senden. Stabiles 0xFF oder 0x00 zeigt normalerweise an, dass die Leitung feststeckt und nirgendwo verbunden ist.

Leider kann ich das vorerst nicht tun, da ich keinen Zugriff auf diese Geräte habe und die SPI-Leitungen nicht zum Sondieren erreichbar sind. Sobald ich einen Weg finde, werde ich es mit Sondieren und MOSI-MISO-Loopback versuchen. Danke!

Stellen Sie sicher, dass die Taktgeschwindigkeit nicht schneller als 25 MHz (aus dem Datenblatt) ist und die Taktpolarität und -phase richtig eingestellt ist (CPOL = 0, CPHA = 0)