El software SPI no se mantiene bajo

1

... y algunas otras cosas. Estoy trabajando en el libro de Geoffrey Brown Descubriendo el microcontrolador STM32 y hasta ahora ha sido bastante sencillo. Me he encontrado con un ejercicio en el que el lector puede intentar leer / escribir en una EEPROM sobre SPI. He tenido la interfaz SPI trabajando en bucle invertido, aunque la noche anterior, cuando la estaba probando, noté que en el analizador lógico estaba viendo al NSS empujando hacia arriba antes de que se completara el mensaje. Entonces por la mañana, sin cambios, todo está funcionando bien otra vez. Ok.

Configuré todo para leer / escribir la ROM (Micro 25LC256) pero la señal que veo en el analizador no es lo que estoy esperando. Veo al NSS empujando alto de vez en cuando en medio de la comunicación. Además, el reloj parece inconsistente y los datos parecen incorrectos, y el analizador me está dando muchos errores.

Pensé, está bien, me quitaré la NSS por completo, ya que la ROM es la única cosa conectada de todos modos, luego se mantendrá baja y puedo verificarla. Pero aún así el reloj se ve mal ... Estoy empezando con estas cosas, pero no tengo nada que ajuste la frecuencia del reloj, ¿no estoy seguro de cómo está cambiando eso? El código se puede encontrar aquí , y creo que es bastante simple. la mayor parte de la lógica importante se ve como

  // Drop select level low then send the write enable flag
  GPIO_WriteBit(EEPROM_PORT, EEPROM_CS, 0);
  spiReadWrite(EEPROM_SPI, res, cmd, 2, EEPROM_SPEED);
  GPIO_WriteBit(EEPROM_PORT, EEPROM_CS, 1);
  Delay(1); // Debugging aid, Wait 1 ms to make analyzer easier to read

Tengo todas las velocidades establecidas bajas (SPI CLK / MOSI / MISO son 72 / 64 = 1.125 < 10Mhz = 25LC256 velocidad máxima y el GPIO que estoy usando para NSS es 2MHz), y puse un retraso de 1ms entre operaciones solo para facilitar la lectura en el analizador, no parece afectar la salida.

Aquí hay una captura de los datos del analizador con el NSS forzado bajo (desconectado):

Acercándomealosprimerospulsos,veoqueelanchodelrelojestáportodaspartes,nomepareceCPOL/CPHA=0/0,ynoparecequeestéenviandoelvalordehabilitacióndeescrituraWREN=0x06=0b00000110...

...ynoparecemejorar...

YunaúltimaquemuestraalNSSempujandoaltosinrazón

¿Cómo depuro desde aquí? ¿Hay algo obvio que estoy pasando por alto? ¿Es común tener problemas de tiempo tan malos? Gracias!

    
pregunta TrivialCase

1 respuesta

2

Una parte que es bastante obvia:

No deje la selección de chips desconectada o baja todo el tiempo. En la mayoría de los dispositivos esclavos, la selección de chip es una parte esencial de la máquina de estados del esclavo. En EEPROM, por ejemplo, la escritura en las celdas reales a menudo se realiza después de que la selección del chip sea alta.

Ahora las capturas de tu analizador lógico se ven muy torpes. Mi conjetura es que tienes algo de ruido en tus líneas (acoplamiento de las otras líneas, bucles de tierra), por lo que realmente no estás viendo lo que realmente está sucediendo allí. También he recibido informes de colegas de que el analizador lógico en sí estaba inyectando una buena cantidad de ruido.

No ha mencionado si realmente vio lo que el software le está diciendo: ¿hace que el búfer de lectura sea igual al que ha escrito? Eso es lo más importante por lo que debería preocuparse. Si ese no es el caso, entonces puede comenzar a mirar el autobús, pero antes de eso intentaría ver qué puedo obtener en el depurador.

Si su analizador admite el modo analógico, podría valer la pena ver las señales analógicas para ver si algunos de los bordes causan un ruido significativo en las otras líneas. O utilice un osciloscopio, por supuesto.

    
respondido por el Arsenal

Lea otras preguntas en las etiquetas