PIC32: saltar de la aplicación al cargador de arranque sin reiniciar el software

Navega tus respuestas
3

Debido a que necesito mantener algunos estados de salida GPIO cuando se realiza la transición de la aplicación al cargador de arranque, vuelvo a saltar al cargador de arranque en lugar de usar un reinicio de software para llegar allí (lo que da como resultado una declaración de GPIO de ~ 200 ms) .

Antes de realizar el salto, deshabilito las interrupciones y borro las banderas de interrupción. Después del salto, el cargador de arranque comienza a funcionar a través de su inicialización, pero una vez que llega a INTEnableSystemMultiVectoredInt (), la MCU se reinicia ...

He intentado anular _DefaultInterrupt para detectar una interrupción que la aplicación podría haber dejado por alguna razón, pero esto no parece estar funcionando. El MCU simplemente se reinicia y me quedo rascándome la cabeza.

¿Alguna idea de lo que podría estar causando esto? Básicamente, imito el comportamiento de saltar desde el gestor de arranque a la aplicación (que funciona), por lo que no sé por qué no funciona al revés. ¿Alguna vez alguien pudo saltar de una aplicación PIC32 al cargador de arranque sin reiniciar el software?

    
pregunta bt2

2 respuestas

0

Esto parece un error tonto en retrospectiva, pero estaba saltando a la función principal del cargador de arranque. Necesitaba saltar a la dirección de entrada de reinicio, para que se ejecutara un código de inicio generado por el compilador y, entre otras cosas, configurar la tabla de vectores de interrupción a los ISR del cargador de arranque antes de ingresar a la función principal del cargador de arranque.

    
respondido por el bt2
1

Tal vez quieras repensar tu aplicación un poco. El uso del cargador de arranque debe ser una actividad rara vez necesaria que puede ser relegada a un comportamiento no estándar del sistema. Como tal, debería ser mínimo, si es que se necesita, mantener los estados GPIO a través de un reinicio / reinicio del software.

No se me ocurren instancias en las que su aplicación no pueda funcionar en el modo de cargador de arranque sin depender de los estados especiales de la configuración de los GPIO en la parte de la aplicación del código. Digo esto porque el cargador de arranque todavía tiene que funcionar en los casos en que comienza sin una aplicación presente o en los casos en que hubo una interrupción del proceso de programación de la aplicación y la aplicación no es válida.

Si ha dividido el diseño de su sistema en el que algunos estados GPIO están configurados en el cargador de arranque y luego intenta depender de esos estados en la aplicación, entonces creo que ha archivado las cosas de manera incorrecta y debería tener cuidado al aislar su arranque. La lógica del cargador desde la lógica de la aplicación en la mayor medida posible.

Si de hecho hay que mantener un estado crítico, creo que se maneja mejor en un expansor GPIO I2C externo que está desacoplado de las transiciones del procesador hacia y desde el modo de cargador de arranque.

    
respondido por el Michael Karas

Lea otras preguntas en las etiquetas

¿El mejor esquema de comunicación para una pantalla Bluetooth LE alimentada por batería? amplificador BJT de 2 etapas para carga de baja impedancia