Comportamiento del programa AVR incorrecto después de desactivar el fusible de reinicio

1

Estoy usando un ATtiny13 para controlar 15 LED de cinco pines de E / S (Charlieplexed). Estoy usando ADC0 (pin1) como entrada de un divisor de voltaje para proporcionar un control de velocidad. Para usar ADC0 correctamente, necesito deshabilitar el fusible de restablecimiento cuando escribo el programa.

El problema es que el programa se comporta de manera diferente cuando el fusible de restablecimiento está deshabilitado. En lugar de las 15 luces LED, solo 9 son. Los 9 LED que se encienden involucran a los 5 pines de E / S, en ambas polaridades, por lo que no creo que haya cambiado accidentalmente ninguna configuración de esos pines.

Aquí está la línea de comando que utilizo para actualizar el AVR (usando avrdude en wintel) y configurar los fusibles:

avrdude -c usbtiny -p attiny13 -U flash:w:program.hex -U lfuse:w:0x6a:m -U hfuse:w:0xfe:m

Y el esquema:

Antes de configurar los fusibles, el programa funciona perfectamente, encendiendo los 15 LED como se esperaba. La entrada en ADC0 restablecerá el micro cuando el voltaje caiga lo suficientemente bajo, como se esperaba, pero de lo contrario el control de velocidad funciona. Aquí hay un gráfico para mostrar cómo están conectados los LED:

LED #    AVR PINs    I/O PINs
 1       5-6         1-2
 2       6-5         2-1
 3       5-7         1-3
 4       7-5         3-1
 5       5-2         1-4
 6       2-5         4-1
 7       5-3         1-5
 8       3-5         5-1
 9       6-7         2-3
10       7-6         3-2
11       6-2         2-4
12       2-6         4-2
13       6-3         2-5
14       3-6         5-2
15       7-2         3-4

Después de deshabilitar el fusible de restablecimiento, los LED 1 a 9 funcionan, 10 a 15 no. Hay un ligero parpadeo detectable en el LED 13. El control de velocidad ADC0 funciona en toda la gama, sin reiniciar el micro.

Estoy completamente confundido. ¿Alguien puede aconsejar?

Editar:

En caso de que sea importante, esto está utilizando un paquete SOIC-8. Anteriormente, he usado un DIP-8 y no he tenido este problema.

    
pregunta JYelton

3 respuestas

2

¡Descubrí la solución a este problema!

Escribí un archivo por lotes para compilar el código, convertirlo en hexadecimal y escribir en el microcontrolador de una sola vez. Para evitar la desactivación accidental del fusible de restablecimiento, escribí un segundo archivo por lotes.

En algún momento, estaba experimentando con diferentes niveles de optimización con avr-gcc. Mis parámetros de línea de comando para avr-gcc incluyeron -O3 en ambos archivos. Descubrí que este nivel de optimización no era confiable y causó algunos problemas. Lo cambié de nuevo a -Os pero solo en el primer archivo por lotes, no en el segundo.

Por lo tanto, el cambio de comportamiento del código fue el resultado de una optimización incorrecta, que se usó solo en el script que usé para deshabilitar también el fusible de reinicio. Finalmente, fue atrapado por un compañero de trabajo astuto que notó la diferencia en los dos scripts.

    
respondido por el JYelton
0

No tiene límites de derivación entre VCC y GND. El ruido de la fuente de alimentación es probablemente tu problema.

    
respondido por el Jim Paris
0

Esta es una suposición un poco descabellada, pero el siguiente fragmento de la página 103 de la hoja de datos puede ser relevante.

  

Consulte “Funciones alternativas del puerto B” en la página 54 para obtener una descripción de   Fusibles RSTDISBL y DWEN. Al programar el fusible RSTDISBL,   La programación en serie de alto voltaje debe utilizarse para cambiar fusibles a   realizar más programación.

Una vez que hayas programado el fusible RSTDISBL , necesitarás usar la programación de alto voltaje para realizar cualquier otra programación del dispositivo. Parece que está usando el USBTiny que no puede realizar la programación de alto voltaje.

Lo que puede estar sucediendo es que el primer ciclo de programación ha funcionado como se esperaba porque el fusible RSTDISBL se programó por última vez en la invocación avrdude , pero los intentos posteriores están fallando debido a que el RSTDISBL está programado y previene la pieza de pasar al modo de programación en serie.

    
respondido por el Austin Phillips

Lea otras preguntas en las etiquetas