Bus SPI intermitente

Estoy intentando conectar un PIC18F4520 a un 25LC640 a través del protocolo SPI. Estoy usando el hardware MSSP integrado del PIC. El PIC18F4520 es el único maestro en el bus. Estoy leyendo 16 bytes de datos de la EEPROM 32 veces por segundo. He comprobado dos veces los siguientes elementos:

  1. Registros TRIS para SDI, SDO, SCK y CS
  2. Tasa de baudios ~ 1 Mhz
  3. Modo SPI 0,0

Revisé las señales en un osciloscopio y todo se ve bien. Intenté usar un BusBee para registrar los datos provenientes de la EEPROM y el 99% de las veces es correcto. De vez en cuando hay una serie de solicitudes en las que la línea MOSI (SDO) no parece contener la instrucción de lectura EEPROM correcta, lo que hace que los datos registrados en el micro no sean válidos. Esto sucede a pesar de que estoy escribiendo la misma instrucción de lectura en el SSPBUF cada vez. ¿Qué más puede salir mal con un bus SPI?

¿Tiene un osciloscopio para ver la señal analógica? Incluso si no tiene un MSO digital/analógico de registro costoso para capturar el paquete que contenía el error, algunas ejecuciones de "muestra única" pueden decirle mucho (y a las personas que intentan ayudar).
He ejecutado el osciloscopio en modo de muestra única, pero todas las muestras que capturo se ven bien. La falla ocurre con poca frecuencia y durante tan poco tiempo que no he podido capturarla en el osciloscopio solo en el analizador de bus que no muestra los voltajes analógicos ni los anchos de pulso.

Respuestas (3)

En el pasado, noté que algunas de las hojas de datos de PIC no muestran correctamente los registros SPI CPOL y CPHA, hubo algunos problemas que al mirar la salida en un osciloscopio, dos de las cuatro combinaciones estaban al revés de lo que se esperaba. . Así que verifique que esté obteniendo la forma de onda esperada de su PIC y que la forma de onda coincida con lo que se necesita en la EEPROM.

También me encontré con algunos convertidores A/D que funcionaban de manera intermitente cuando tenía una configuración SPI incorrecta en un HC12, lo que me llevó a tratar de resolverlo, fue uno de mis primeros proyectos como ingeniero profesional, finalmente lo resolví. Pero yo divago. Por lo tanto, es posible tener problemas intermitentes al usar el bus SPI debido a una configuración incorrecta de CPOL/CPHA. Como es un registro de desplazamiento después de todo, y el último bit de un carácter puede leerse del primero del siguiente carácter. Es posible que este tipo de problema tampoco se note de inmediato.

Así que asegúrese de tener la configuración correcta en un osciloscopio y no confíe solo en configurar los registros del PIC.

No estoy seguro si fue el PIC18F4520 o el 25LC640 el que no funcionó del todo bien en el Modo 00 de SPI, pero ambos funcionan en el Modo 11.

Si tiene un esquema, publíquelo, también cualquier información sobre cómo está tratando las líneas de señal. A 1Mhz, los efectos de la línea de transmisión pueden entrar en juego, mencionó que analizó la señal y todo se veía bien, pero ¿verificó los tiempos de subida/bajada, los reflejos y el timbre? ¿Su línea de señal está terminada y controlada por impedancia? ¿Cuánto tiempo son?

Otras cosas aleatorias que podrían ser:

  • error en el código, cree un programa mínimo que no haga nada más que leer desde la EEPROM para probar
  • Verifique la configuración adecuada de CS y los tiempos de espera antes de que comiencen las transferencias
  • ¿Estás escribiendo en la EEPROM también? si es así, ¿está comprobando el registro de estado para asegurarse de que la escritura esté completa antes de intentar una lectura?
  • ¿Está utilizando el control de velocidad de respuesta en el MSSP? De cualquier manera, verifique que sus tiempos mínimos/máximos de subida/bajada estén dentro de los límites de EEPROM.
Verifiqué los tiempos de subida y bajada, están muy por debajo del máximo de la hoja de datos de 2 us. No parece haber reflejos ni timbres en la señal.
Pensé que el control de velocidad de giro solo se aplicaba a I2C. Estoy muestreando los datos a la mitad del tiempo de salida (SMP=0).
Los tiempos de configuración y espera de CS son de ~ 10 us. La hoja de datos indica que el tiempo mínimo es de 500 ns. ¿Hay algún problema con tener una configuración de CS demasiado larga o un tiempo de espera?
no debería ser un problema con mucho tiempo en CS. Si la integridad de la señal está bien, buscaría un error en el código uC, crearía un caso de prueba minimalista.

Tuve errores intermitentes similares y descubrí que era un error en el código. No tenía que ver con SPI, pero de vez en cuando el chip se reiniciaba y esto provocaba que se escribiera basura en la memoria del chip; asegúrese de que su código sea estable. Una forma de hacer esto sería reiniciar para que presione un botón para que no se reinicie automáticamente.

¡Buen pensamiento! Tengo un mensaje que imprimo en RS-232 cuando inicio. El programa no parece estar reiniciando.
O encienda una luz al encender para que sea obvio para usted.
¿Se desbordó el temporizador del perro guardián y provocó que el chip se reiniciara?
Bus SPI intermitente
RespuestasAquíPolítica de privacidad1y, 0v