Há algumas coisas que não entendo no processo de inicialização do microcontrolador STM32F4.
As inicializações do ARM Cortex-M4 esperam que o valor de inicialização do ponteiro da pilha e os vetores de interrupção sejam ativados 0x00000000 + SCB->VTOR, ao passo que SCB->VTORsão limpos na redefinição.
Não há memória nesse local. A memória flash começa em 0x08000000, SRAM em 0x20000000.
Para possibilitar a inicialização, o µC pode mapear o intervalo de memória flash ou SRAM para 0x00000000. O intervalo de memória a ser mapeado é definido pelo estado dos pinos de inicialização.
Por que o manual de referência do STM32F4 está dizendo na página 69 que
Quando o dispositivo inicializa da SRAM, no código de inicialização do aplicativo, é necessário realocar a tabela de vetores na SRAM usando a tabela de exceção NVIC e o registro de deslocamento.
? No meu ponto de vista, isso não é necessário, pois toda a região da memória é alias. Curiosamente, isso não parece ser necessário quando a região do flash é remapeada para o 0x0espaço.
O único uso para inicializar a partir da SRAM, posso pensar se é para reduzir os ciclos de gravação no flash durante o desenvolvimento. Antes de liberar o µC da redefinição, grave o programa na SRAM usando o depurador e, em seguida, inicialize a partir daí. No entanto, como você tem acesso ao depurador, não haveria restrições de onde inicializar de qualquer maneira. Então, por que ter esse recurso?
O fato de a posição de inicialização ser derivada de pinos indica (pelo menos na minha opinião) que esse recurso deve ser usado não durante o desenvolvimento, mas na operação final. E na operação final, a SRAM é clara no momento da inicialização. Portanto, não faz sentido inicializar a partir da SRAM.
stm32f4 cortex-m
— Multisync
Você pode inicializar a partir da RAM, para executar uma atualização de firmware. O código da RAM é executado e pisca novamente o conteúdo da memória Flash. Após a conclusão da atualização, você redefine a execução novamente a partir do Flash.
— Fotis Panagiotopoulos
Definitivamente, não posso responder à sua primeira pergunta. Mas no manual de programação onde o registro VTOR é descrito ( página 212 ), afirma que o bit 29 é usado para determinar onde a tabela vetorial está localizada, na região de código (0) ou na região SRAM (1).
Agora não entendo por que isso deve ser feito pelo mesmo motivo que você afirma, a SRAM é aliasizada a 0x0, então por que é necessário definir esse deslocamento?
O único palpite que tenho está na sua página citada 69. Eles dizem:
a área de código começa no endereço 0x0000 0000 (acessado através dos barramentos ICode / DCode)
a área de dados (SRAM) inicia no endereço 0x2000 0000 (acessado através do barramento do sistema)
O Cortex ® -M4 com CPU FPU sempre busca o vetor de redefinição no barramento ICode
Talvez em uma interrupção o barramento ICode seja usado, o que não pode acessar a SRAM mesmo quando remapeado (não sei se isso é verdade). Isso explicaria por que esse bit deve ser definido adequadamente, informando ao núcleo para usar o barramento do sistema e acessar a SRAM.
Embora possa ser verdade, que a SRAM esteja vazia na primeira inicialização do dispositivo, não é necessariamente para inicializações posteriores. Assim, você pode criar algo como um dispositivo alimentado por bateria que programa sua SRAM durante a produção e depois funcione até a bateria acabar, o que limparia sua SRAM. Eu acho que isso tornaria a engenharia reversa do dispositivo um pouco mais difícil.
Em um dispositivo alimentado por bateria, você provavelmente usaria o modo de espera para economizar energia e, se você sair desse modo, os pinos de inicialização serão amostrados novamente, portanto, eles devem ter a configuração correta para acessar a SRAM novamente.
Você também pode reiniciar o dispositivo com segurança, pois o conteúdo da SRAM não será destruído se não houver falta de energia.