Conceptos de arranque de STM32F4 y reubicación de la tabla de vectores

Question

Hay algunas cosas que no entiendo sobre el proceso de arranque del microcontrolador STM32F4.

Mi entendimiento es el siguiente:

1. El ARM Cortex-M4 espera que el valor de inicialización del puntero de pila y los vectores de interrupción estén en 0x00000000 + SCB->VTOR, mientras que SCB->VTOR se borra en el reinicio.
2. No hay memoria en esa ubicación. La memoria flash comienza en 0x08000000, la SRAM en 0x20000000.
3. Para que el arranque sea posible, el µC puede mapear el rango de memoria flash o SRAM a 0x00000000. El rango de memoria a mapear está definido por el estado de los pines de arranque.

Mis preguntas:

1. ¿Por qué el manual de referencia del STM32F4 menciona en página 69 que

    

   Cuando el dispositivo arranca desde la SRAM, en el código de inicialización de la aplicación, debes reubicar la tabla de vectores en la SRAM usando la tabla de excepciones de NVIC y el registro de desplazamiento.

   ? En mi opinión, esto no es necesario, ya que toda la región de memoria está aliada de todos modos. Curiosamente, esto no parece ser necesario cuando la región flash se remapea al espacio 0x0.

2. El único uso que puedo pensar para arrancar desde la SRAM es reducir los ciclos de escritura en la flash durante el desarrollo. Antes de liberar el µC del reinicio, escribes el programa en la SRAM usando el depurador y luego arrancas desde allí. Sin embargo, como tienes acceso al depurador, no habría restricciones sobre dónde arrancar de todos modos. Entonces, ¿por qué tener esta característica?

   Que la posición de arranque se derive de los pines indica (al menos en mi opinión) que esta característica se debe usar no durante el desarrollo sino en la operación final. Y en la operación final, la SRAM está limpia en el momento del arranque. Por lo tanto, no tiene sentido arrancar desde la SRAM.

Answer 1

Pregunta 1:

No puedo responder definitivamente a tu primera pregunta. Pero en el manual de programación donde se describe el registro VTOR (página 212) se indica que el bit 29 se utiliza para determinar dónde se encuentra la tabla de vectores, ya sea en la región de código (0) o en la región de SRAM (1).

Ahora no entiendo por qué esto debe hacerse por la misma razón que mencionas, la SRAM se ajusta a 0x0, ¿entonces por qué es necesario establecer este desplazamiento?

La única suposición que tengo se menciona en la página 69 que citas. Ellos dicen:

el área de código comienza desde la dirección 0x0000 0000 (accedida a través de los buses ICode/DCode)

el área de datos (SRAM) comienza desde la dirección 0x2000 0000 (accedida a través del bus del sistema)

La CPU Cortex ® -M4 con FPU siempre obtiene el vector de reinicio en el bus ICode

Tal vez en una interrupción se utilice el bus ICode, que no puede acceder a la SRAM incluso cuando está remapeada (no sé si esto es cierto). Esto explicaría por qué este bit debe configurarse en consecuencia, indicando al núcleo que use el bus del sistema y acceda a la SRAM.

Pregunta 2:

Aunque pueda ser cierto que la SRAM esté vacía en el primer arranque del dispositivo, no necesariamente lo está en arranques posteriores. Por lo tanto, podrías crear algo como un dispositivo alimentado por batería que se programa su SRAM durante la producción y luego funciona hasta que la batería se agote, lo que borraría su SRAM. Supongo que esto haría que la ingeniería inversa del dispositivo fuera un poco más difícil.

En un dispositivo alimentado por batería probablemente usarías el modo de espera para conservar energía, y si sales de ese modo, los pines de arranque se muestrean nuevamente, por lo que deben tener la configuración correcta para volver a la SRAM.

También puedes reiniciar el dispositivo de manera segura ya que el contenido de la SRAM no se destruye si no hay toma de corriente.

No es una aplicación muy convincente para rectificar todos los problemas de volver a mapear la SRAM.