Leonardo (32u4): formas de bloquearlo programáticamente

Creo que cuando se presentó el Leonardo, leí algunos artículos sobre la precaución de hacer algunas cosas, que podrían hacer que no cargue más bocetos nuevos, por lo que hay que reescribir el gestor de arranque. Debido a que planeo usar opciones de ahorro de energía, por ejemplo, para deshabilitar componentes de hardware no utilizados como el puerto USB, me temo hacer algo mal.

Una delicadeza de Leonardo que he encontrado hasta ahora:

• Si las interrupciones están desactivadas, la carga de nuevos bocetos falla a menos que uno presione el botón Restablecer tan pronto como el IDE de Arduino muestre "Cargando ..."

¿Qué cosas (excepto las habituales relacionadas con el hardware que se consideran como conectar pines configurados a la salida a potenciales fijos) podrían dañar el controlador o requerir que el Leonardo vuelva a actualizarse con un cargador de arranque nuevo?

Si carga un programa que cambia la velocidad del núcleo USB, sería casi bloqueado. Lo que sucedería es esto:

1. Encendido, se inicia el cargador de arranque, dispositivo USB enumerado en la PC.
2. Unos segundos después del inicio del programa, la velocidad del núcleo USB cambió, el dispositivo USB desaparece de la PC

El problema aquí es que no solo tiene que presionar restablecer al programa, después del restablecimiento, debe seleccionar rápidamente el puerto de comunicación correcto y luego cargarlo antes de que comience el programa.

Redbearlab Blend Micro requiere que se configure una velocidad de núcleo USB en el programa de usuario. En sus instrucciones de configuración hay un paso para editar el main.cpp de Arduino y agregar una sección para hacerlo. Si se omite este paso, ocurre el problema anterior.

Me las arreglé para bloquear un ATMega128RFA1. El gestor de arranque y el software que cargué en él funcionaban bien. Pero fue imposible borrar / escribir la ROM.

Después de verificar lo que sucedió, descubrí en la hoja de datos que algunos fusibles en el núcleo AVR están destinados a proteger la escritura accidental en la ROM. Algún tipo de fusibles de seguridad.

Nunca encontré el error que escribió en estos bytes (ya que era un programa realmente grande y éramos 3 personas involucradas en la codificación), pero sí, solo explotamos un fusible y perdimos un MCU debido a un error.

En cuanto al leonardo, pueden suceder varias cosas, pero ninguna de ellas puede obstruir su tablero a menos que se queme uno de estos fusibles de protección.

Es posible, con un código realmente inteligente , explotar el gestor de arranque para sobrescribirse.

Extracto:

La solución es en realidad conceptualmente bastante simple. Un gestor de arranque, por su propia naturaleza, está diseñado para descargar nuevo firmware al dispositivo. Por lo tanto, contendrá al menos una instrucción spm. Debido a que el registro de configuración spm debe escribirse no más de 4 ciclos antes de la instrucción spm, significa que hay muy pocas secuencias que prácticamente se producen: solo sts, spm o out, secuencias spm. Entonces, todo lo que necesita es encontrar la secuencia en la sección del cargador de arranque; configurar los registros correctos y llamarlo.

Sin embargo, resultó que había un problema importante con eso también. Las instrucciones spm del cargador de arranque de autoprogramación V-USB no son una pequeña rutina, sino que están integradas en el código principal; así que llamarlo solo provocaría que el AVR se bloquee al intentar ejecutar el resto del cargador de arranque V-USB.

Desagradable, pero de nuevo hay una solución. Al usar un temporizador sincronizado a la frecuencia de la CPU (que es fácil en un AVR), puede crear una rutina en ensamblador que configure los registros para la secuencia spm del Bootloader; lo llama y justo en el momento en que se ejecuta el primer ciclo del SPM, la interrupción del temporizador se apaga y el AVR debe saltar a su rutina de interrupción (en el espacio de la aplicación). La rutina de interrupción muestra la dirección del gestor de arranque y luego vuelve al código anterior, que es la rutina que configura la secuencia spm de salida. Esto debería funcionar, porque cuando aplica las instrucciones spm a la sección del cargador de arranque, la CPU se detiene hasta que se completa.

Básicamente, puedes hacer una programación sofisticada y hacer que el gestor de arranque se maneje solo, haciendo que la MCU sea inútil sin un programador dedicado.

El único que conozco es hacer que el Leonard actúe como un mouse USB que aletea en todas partes y escribe teclas aleatorias para que no pueda reprogramarlo sin hacer algún tipo de truco para evitarlo. Pero mencionan esto en los api docs.