AT89LP51ED2 SPI ISP: el primer intento de ingresar al modo ISP después del restablecimiento devuelve los datos incorrectos, pero el segundo intento funciona

3

Tengo una placa que utiliza un AT89LP51ED2 de Atmel: se trata de un derivado 8051 con memoria de programa Flash incorporada y una interfaz SPI ISP, que estoy usando mi Bus Pirate para conducir (velocidad de 30 kHz, pullups ON y cableado a la placa Vcc; la configuración SPI predeterminada es otra cosa, el pin AUX de conducción / RESET). El protocolo ISP está documentado por Atmel, tanto en la hoja de datos como en esta nota de la aplicación Atmel : en general, es superficialmente similar a AVR SPI ISP excepto por el uso de 2 bytes de prefijo (lo que lo hace incompatible con avrdude ). El modo de programación requiere un comando de entrada: los dos bytes de prefijo de 0xAA 0x55 seguidos de 0xAC 0x53 y un dummy 0x00 , que debería devolver 0x53 para indicar que el dispositivo está en modo ISP.

Por lo tanto, me propuse implementar el protocolo yo mismo, usando el modo SPI binario de Bus Pirate, su módulo Python asociado y un poco de secuencias de comandos Python personalizadas en mi propio extremo. Sin embargo, me di cuenta de que mi secuencia de comandos Python solo entrar en modo ISP de forma intermitente. Pude reproducir la falla manualmente utilizando la interfaz del terminal de Bus Pirate, a partir de un arranque en frío de la placa:

SPI>a
AUX LOW
SPI>{ 0xaa 0x55 0xac 0x53 0x00 ]
/CS ENABLED
WRITE: 0xAA READ: 0xFF 
WRITE: 0x55 READ: 0xFF 
WRITE: 0xAC READ: 0xFF 
WRITE: 0x53 READ: 0xFF 
WRITE: 0x00 READ: 0xA7 
/CS DISABLED
SPI>{ 0xaa 0x55 0xac 0x53 0x00 ]
/CS ENABLED
WRITE: 0xAA READ: 0xFF 
WRITE: 0x55 READ: 0xAA 
WRITE: 0xAC READ: 0x55 
WRITE: 0x53 READ: 0xAC 
WRITE: 0x00 READ: 0x53 
/CS DISABLED
SPI>

El error en particular es que en el primer comando, la interfaz del ISP devuelve 0xA7 en lugar del 0x53 que debería. El restablecimiento de la placa me permitió reproducirlo nuevamente y capturar la secuencia en mi osciloscopio, incluido un error BAJO durante medio reloj al final del último 0xFF que se desplaza:

Entonces, ¿qué estoy haciendo mal? ¿Este es un problema de protocolo? ¿O debería sospechar de un microcontrolador defectuoso o, lo que es peor, un error en la implementación de la programación? ¿Debería simplemente solucionar esto en mi script ISP?

    
pregunta ThreePhaseEel

1 respuesta

1

Parece que puede estar recibiendo un pulso de reloj adicional antes del último bit del 4to byte. El esclavo piensa que se han enviado los 8 bits y comienza a conducir un 0 en la línea MISO en el último bit porque percibe que es el primer bit del siguiente byte.

Luego, todos los datos se desplazan en uno como resultado.

Creo que no puedes ver este pulso de reloj adicional porque tu velocidad de reloj es tan lenta que tienes que alejarte mucho del oscope. Intente hacer zoom en esa área entre los bits 7 y 8, y ajustar el oscope para que pueda ver el pulso más pequeño.

Es difícil decir si esto fue causado por hardware o software, pero me atrevería a adivinar el software: busque algo que pueda causar una pequeña falla en el reloj.

    
respondido por el Annie

Lea otras preguntas en las etiquetas