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

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

Mi entendimiento es el siguiente:

1. Las botas ARM Cortex-M4 esperan el valor de inicialización del puntero de la pila y los vectores de interrupción activados 0x00000000 + SCB->VTOR, mientras que SCB->VTORse borran al reiniciar.
2. No hay memoria en esa ubicación. La memoria flash comienza en 0x08000000, SRAM en 0x20000000.
3. Para hacer posible el arranque, el µC puede asignar 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 STM32F4 dice en la página 69 que

   Cuando el dispositivo se inicia desde SRAM, en el código de inicialización de la aplicación, debe reubicar la tabla de vectores en SRAM utilizando la tabla de excepciones NVIC y el registro de desplazamiento.

   ? En mi punto de vista, esto no es necesario, ya que la región de memoria completa tiene un alias de todos modos. Curiosamente, esto no parece ser necesario cuando la región flash se reasigna al 0x0espacio.

2. El único uso para arrancar desde SRAM que puedo pensar es reducir los ciclos de escritura en la memoria flash durante el desarrollo. Antes de liberar el µC del reinicio, escribe el programa en SRAM usando el depurador y luego inicia desde allí. Sin embargo, como tiene acceso al depurador, no habría restricciones sobre dónde iniciar 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 no se utilizará durante el desarrollo sino en la operación final. Y en la operación final, SRAM es clara en el momento del arranque. Por lo tanto, no tiene sentido arrancar desde SRAM.

Pregunta 1:

Definitivamente no puedo responder tu primera pregunta. Pero en el manual de programación donde se describe el registro VTOR ( página 212 ) establece que el bit 29 se usa para determinar dónde está ubicada la tabla de vectores, ya sea en la región de código (0) o en la región SRAM (1).

Ahora no entiendo por qué esto debe hacerse por la misma razón que usted dice, la SRAM tiene un alias de 0x0, entonces, ¿por qué es necesario establecer este desplazamiento?

La única suposición que tengo está indicada en su página 69 citada. Dicen:

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

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

El Cortex ® -M4 con CPU FPU siempre recupera el vector de reinicio en el bus ICode

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

Pregunta 2:

Si bien puede ser cierto, que la SRAM está vacía en el primer arranque del dispositivo, no es necesariamente para arranques posteriores. Por lo tanto, podría crear algo así como un dispositivo alimentado por batería que programe su SRAM durante la producción y luego funcione hasta que la batería se agote, lo que eliminaría su SRAM. Supongo que esto haría que la ingeniería inversa del dispositivo sea un poco más difícil.

En un dispositivo alimentado por batería, probablemente usaría el modo de espera para ahorrar energía, y si abandona 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 puede reiniciar el dispositivo de forma segura ya que el contenido de la SRAM no se destruye si no hay una toma de corriente.

No es una aplicación muy convincente para rectificar todos los problemas para reasignar la SRAM.