La interfaz SPI devuelve solo unos (0xFF)

Estoy tratando de registrar un dispositivo SPI en mi Angstrom Linux (kernel versión 3.10) para usar un chip ADC (LTC2258) para mi placa personalizada. El procesador que usa I2m es Cyclone V, y las transferencias de FPGA parecen correctas (SPI Master 1 se entrega a HPS). Entonces, edité mi archivo .dtb así:

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

    };

En el arranque del kernel, solo dice esto sobre SPI:

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

Pero spidev0.0la entrada aparece debajo de /dev. Con spidev_testel programa predeterminado, veo este resultado:

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 

Y ahí está la cosa: la interfaz SPI de ese ADC se usa para la configuración. Entonces, el caso de prueba para mí es escribir valores de configuración en registros con direcciones dadas y leerlos con éxito. Entonces, modifico el búfer tx del código fuente; Escribo y leo los registros. Pero me da el mismo resultado, FF completos.

En la hoja de datos de ADC, dice:

  • Los datos se escriben en un registro con una palabra serial de 16 bits. Los datos también se pueden leer de un registro para verificar su contenido.
  • El primer bit de la palabra de entrada de 16 bits es el bit R/W. Los siguientes siete bits son la dirección del registro (A6:A0). Los últimos ocho bits son los datos de registro (D7:D0). Si el bit R/W es bajo, los datos en serie (D7:D0) se escribirán en el registro establecido por los bits de dirección (A6:A0). Si el bit R/W es alto, los datos en el registro establecido por los bits de dirección (A6:A0) se volverán a leer en el pin SDO

Entonces, modifiqué el código en consecuencia. Yo uso mi spidev_test modificado con estos parámetros:

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

Pero como he dicho antes, el resultado es completo. Además, cambiar el parámetro de bits por palabra no afecta el resultado.

¿Cómo puedo depurar esto? ¿Dónde debo buscar? Cualquier ayuda es apreciada. Gracias de antemano.

Por si acaso... ¿Ha confirmado su protocolo SPI para su terminal/SW y el dispositivo coincide? SPI no es un estándar (por ejemplo, IEEE) y, como tal, requiere que se establezcan algunos parámetros, por lo general. Tal vez spi mode: 0hace eso por ti (?)
@CapnJJ Sí, lo tengo. De hecho, los cambié al azar para ver la reacción. Pero nada cambió.

Respuestas (3)

Resultó que estaba mal informado sobre el pin de selección de chip del ADC. Cambiar el valor del nodo secundario de Spidev rega 1 resolvió el problema. Los parámetros finales que uso son:

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

Perdona por hacerte perder el tiempo y gracias por tu ayuda!

Conecte un analizador lógico o alcance para ver que las señales realmente están cambiando (CS, SCK y MOSI), luego conecte MOSI a MISO para ver que puede recibir lo que está enviando. 0xFF estable o 0x00 generalmente indica que la línea está atascada y no está conectada en ninguna parte.

Desafortunadamente, no puedo hacer eso por ahora ya que no tengo acceso a estos equipos y las líneas SPI no están accesibles para sondear. Tan pronto como encuentre una manera, intentaré probar y retroceder MOSI-MISO. ¡Gracias!

Asegúrese de que la velocidad del reloj no supere los 25 MHz (de la hoja de datos) y que la polaridad y la fase del reloj estén configuradas correctamente (CPOL = 0, CPHA = 0)