Conceitos de inicialização STM32F4 e realocação de tabela de vetores


8

Há algumas coisas que não entendo no processo de inicialização do microcontrolador STM32F4.

Meu entendimento é o seguinte:

  1. 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.
  2. Não há memória nesse local. A memória flash começa em 0x08000000, SRAM em 0x20000000.
  3. 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.

Minhas perguntas:

  1. 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.

  2. 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.


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

Respostas:


5

Questão 1:

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.

Questão 2:

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.

Não é um aplicativo muito convincente para corrigir todos os problemas para remapear a SRAM.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.