Seleccione el software SPI para no quedarse bajo

...y algunas cosas más. Estoy trabajando en el libro de Geoffrey Brown Discovering the STM32 Microcontroller y hasta ahora ha sido bastante fluido. Me encontré con un ejercicio en el que el lector puede intentar leer/escribir en una EEPROM sobre SPI. He tenido la interfaz SPI funcionando en bucle invertido, aunque anoche, cuando la estaba probando, noté que en el analizador lógico estaba viendo que el NSS presionaba alto antes de que se completara el mensaje. Luego, por la mañana, sin cambios, todo vuelve a funcionar bien. DE ACUERDO.

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

Pensé, está bien, quitaré el NSS por completo ya que la ROM es lo único conectado de todos modos, luego permanecerá bajo y puedo verificarlo. Pero aún así el reloj se ve mal... Recién estoy comenzando con esto, pero no tengo nada que ajuste la frecuencia del reloj, así que 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 parece

  // 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 bajas (SPI CLK/MOSI/MISO son 72 / 64 = 1.125< 10Mhz= 25LC256 de velocidad máxima y el GPIO que estoy usando para NSS es de 2 MHz), y puse un retraso entre 1msoperaciones solo para que sea más fácil de leer en el analizador, no parece afectar la salida.

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

ingrese la descripción de la imagen aquí

Al acercarme a los primeros pulsos, veo que el ancho del reloj está por todas partes, no me parece CPOL/CPHA = 0/0, y no parece que esté enviando el valor de habilitación de escritura WREN = 0x06 = 0b0000 0110...

ingrese la descripción de la imagen aquí

...y no parece mejorar...

ingrese la descripción de la imagen aquí

Y una última que muestra el NSS empujando alto sin motivo

ingrese la descripción de la imagen aquí

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

Lo primero que me viene a la mente es que necesita un pin CS para conectar este chip. De 3.2 en la hoja de datos: "Después de que se transmitan los ocho bits de la instrucción, el CS debe ponerse alto para configurar el pestillo de habilitación de escritura". En segundo lugar, ¿conectó el pin de "retención" correctamente?
¿A qué velocidad está muestreando su analizador lógico? Parece que podría ser demasiado lento en relación con su reloj SPI.
@brhans Lo tengo configurado en su máximo, que es 50MS/s. Creo que eso debería ser suficiente para muestrear una < 2MHzseñal.
@Maple Gracias, en realidad sé que el CS se usa para configurar el pestillo de escritura. Solo lo deshabilité para ver si podía 'forzar' la salida de la señal correcta de MOSI (espero ver 0x06cuál es el valor de activación de escritura), pero ni siquiera está llegando tan lejos. En cuanto al pasador de espera, lo revisaré dos veces por la mañana, pero todo está bastante conectado en su propia placa de prueba, por lo que estoy bastante seguro de que está bien conectado.

Respuestas (1)

Una parte que es bastante obvia:

No deje la selección de chip 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 estado del esclavo. En las 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 su analizador lógico se ven muy torcidas. Mi conjetura es que tiene algo de ruido en sus líneas (acoplamiento de las otras líneas, bucles de tierra) por lo que en realidad no está viendo lo que realmente está sucediendo allí. También recibí informes de colegas de que el analizador lógico en sí estaba inyectando una buena cantidad de ruido.

No ha mencionado si realmente miró lo que le dice el software: ¿obtiene el búfer de lectura igual a lo que ha escrito? Eso es lo principal que debería preocuparte, si ese no es el caso, puedes comenzar a mirar el bus, pero antes de eso, trataría de ver qué puedo obtener en el depurador.

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

¡Gracias! Revisé los valores en la ROM y no veo mis escrituras, pero obtengo la cantidad correcta de valores cero cuando reviso el depurador (hago que extraiga toda la primera página y obtengo 64 ceros) , lo que parece una buena señal). En realidad, hace que la situación sea más confusa, ya que si la lectura funciona correctamente, podría tener algún problema en el software con las escrituras (por eso estaba tratando de depurar con el analizador lógico en primer lugar) pero simplemente no puedo solucionar el problema. debido a problemas con el analizador. :-/
Actuando en base a su respuesta, vinculé todos los motivos a una mejor fuente. Resulta que el suelo que estaba usando para el pin CS es raro (probablemente toda la placa esté defectuosa de alguna manera). Ahora recibo una señal más clara, aunque algo todavía parece estar un poco mal. ¡Gracias por tu ayuda!
Gracias nuevamente por la ayuda, acepto su respuesta ya que me puso en marcha. El analizador lógico todavía tiene un poco de ruido, pero hice que todo funcionara muy bien. No estoy seguro de cómo es posible, pero uno de los pines de tierra en mi tablero de descubrimiento hace mucho ruido a pesar de que el resto del tablero parece funcionar bien. Mi sospecha es que los otros motivos podrían ser los culpables del resto del comportamiento errático que veo en el analizador, pero como funciona, no voy a volverme loco probando eso por ahora.
@TrivialCase Si uno de los pines de conexión a tierra genera mucho ruido adicional, es posible que no esté conectado a tierra (¿mala soldadura?) o una conexión a tierra diferente (algunas placas tienen conexiones a tierra separadas, pero no creo que eso es el caso de las placas Discovery). También podría ser que el pin tenga una mala ruta a tierra (bucle largo en lugar de directamente al avión). Me alegro de poder ayudarte un poco.
Seleccione el software SPI para no quedarse bajo
RespuestasAquíPolítica de privacidad1y, 0v