Concetti di avvio STM32F4 e trasferimento della tabella vettoriale

Ci sono alcune cose che non capisco sul processo di avvio del microcontrollore STM32F4.

La mia comprensione è la seguente:

1. L'avvio di ARM Cortex-M4 prevede il valore di inizializzazione del puntatore dello stack e i vettori di interruzione attivi 0x00000000 + SCB->VTOR, mentre SCB->VTORviene azzerato al ripristino.
2. Non c'è memoria in quella posizione. La memoria flash inizia alle 0x08000000, SRAM alle 0x20000000.
3. Per rendere possibile l'avvio, µC può mappare il flash o l'intervallo di memoria SRAM su 0x00000000. L'intervallo di memoria da mappare è definito dallo stato dei pin di avvio.

Le mie domande:

1. Perché il manuale di riferimento STM32F4 dice a pagina 69 che

   Quando il dispositivo si avvia da SRAM, nel codice di inizializzazione dell'applicazione, è necessario riposizionare la tabella vettoriale in SRAM utilizzando la tabella delle eccezioni NVIC e il registro offset.

   ? Dal mio punto di vista questo non è necessario, poiché l'intera area di memoria è comunque aliasata. È interessante notare che questo non sembra essere richiesto quando la regione del flash viene rimappata nello 0x0spazio.

2. L'unico uso per l'avvio da SRAM posso pensare se è quello di ridurre i cicli di scrittura sul flash durante lo sviluppo. Prima di rilasciare µC dal reset, scrivere il programma su SRAM usando il debugger e quindi avviare da lì. Tuttavia, poiché si dispone dell'accesso al debugger, non ci sarebbero restrizioni su dove avviare comunque. Quindi perché avere questa funzione?

   Il fatto che la posizione di avvio sia derivata dai pin indica (almeno a mio avviso) che questa funzione non deve essere utilizzata durante lo sviluppo ma nell'operazione finale. E nell'operazione finale, SRAM è chiaro al momento dell'avvio. Quindi non ha senso eseguire l'avvio da SRAM.

Domanda 1:

Non posso assolutamente rispondere alla tua prima domanda. Ma nel manuale di programmazione in cui è descritto il registro VTOR ( pagina 212 ) si afferma che il bit 29 viene utilizzato per determinare dove si trova la tabella vettoriale, nella regione del codice (0) o nella regione SRAM (1).

Ora non capisco perché questo debba essere fatto per la stessa ragione che affermi, SRAM viene impostato su 0x0, quindi perché è necessario impostare questo offset?

L'unica ipotesi che ho è riportata nella tua citata pagina 69. Dicono:

l'area del codice inizia dall'indirizzo 0x0000 0000 (accessibile tramite i bus ICode / DCode)

l'area dati (SRAM) inizia dall'indirizzo 0x2000 0000 (accessibile tramite il bus di sistema)

Cortex ® -M4 con CPU FPU recupera sempre il vettore di ripristino sul bus ICode

Forse su un interrupt viene utilizzato il bus ICode, che non può accedere alla SRAM anche se rimappato (non so se questo è vero). Questo spiegherebbe perché questo bit deve essere impostato di conseguenza, dicendo al core di usare il bus di sistema e accedere alla SRAM.

Domanda 2:

Mentre potrebbe essere vero, che la SRAM è vuota al primo avvio del dispositivo, non è necessariamente per gli avvii successivi. Quindi potresti creare qualcosa come un dispositivo alimentato a batteria che ottiene la sua SRAM programmata durante la produzione e quindi funziona fino a quando la batteria è scarica, il che cancellerebbe la sua SRAM. Immagino che questo renderebbe il reverse engineering del dispositivo un po 'più difficile.

In un dispositivo alimentato a batteria è probabile che tu utilizzi la modalità standby per risparmiare energia e, se lasci quella modalità, i pin di avvio vengono nuovamente campionati, quindi devono avere le impostazioni corrette per accedere nuovamente alla SRAM.

È inoltre possibile riavviare il dispositivo in modo sicuro poiché il contenuto della SRAM non viene distrutto se non vi è alcuna interruzione di corrente.

Un'applicazione non molto convincente per correggere tutti i problemi per rimappare la SRAM.