Il y a certaines choses que je ne comprends pas sur le processus de démarrage du microcontrôleur STM32F4.
Ma compréhension est la suivante:
- Le démarrage ARM Cortex-M4 attend la valeur d'initialisation du pointeur de pile et les vecteurs d'interruption activés
0x00000000 + SCB->VTOR, tandis qu'ilSCB->VTORest effacé lors de la réinitialisation. - Il n'y a pas de mémoire à cet endroit. La mémoire flash commence à
0x08000000, SRAM à0x20000000. - Afin de rendre possible le démarrage, le µC peut mapper la plage de mémoire flash ou SRAM sur
0x00000000. La plage de mémoire à mapper est définie par l'état des broches de démarrage.
Mes questions:
Pourquoi le manuel de référence STM32F4 dit à la page 69 que
Lorsque le périphérique démarre à partir de SRAM, dans le code d'initialisation de l'application, vous devez déplacer la table vectorielle dans SRAM à l'aide de la table d'exception NVIC et du registre de décalage.
? À mon avis, cela n'est pas nécessaire, car toute la région de la mémoire est de toute façon aliasée. Fait intéressant, cela ne semble pas être nécessaire lorsque la région du flash est remappée à l'
0x0espace.La seule utilisation pour le démarrage à partir de SRAM, je pense que c'est de réduire les cycles d'écriture sur le flash pendant le développement. Avant de libérer le µC de la réinitialisation, vous écrivez le programme dans SRAM à l'aide du débogueur, puis démarrez à partir de là. Cependant, comme vous disposez d'un accès au débogueur, il n'y aura de toute façon aucune restriction sur le démarrage. Alors pourquoi avoir cette fonctionnalité?
Le fait que la position de démarrage soit dérivée des broches indique (au moins à mon avis) que cette fonctionnalité doit être utilisée non pas pendant le développement mais en fonctionnement final. Et en fonctionnement final, SRAM est clair au démarrage. Par conséquent, il n'est pas logique de démarrer à partir de SRAM.
Réponses:
Question 1:
Je ne peux pas vraiment répondre à votre première question. Mais dans le manuel de programmation où le registre VTOR est décrit ( page 212 ), il indique que le bit 29 est utilisé pour déterminer où se trouve la table vectorielle, soit dans la région de code (0) ou dans la région SRAM (1).
Maintenant, je ne comprends pas pourquoi cela doit être fait pour la même raison que vous dites, la SRAM est aliasée à 0x0, alors pourquoi est-il nécessaire de définir ce décalage?
La seule supposition que j'ai est énoncée à la page 69 que vous avez citée. Ils disent:
Peut-être que sur une interruption, le bus ICode est utilisé, qui ne peut pas accéder à la SRAM même lorsqu'il est remappé (je ne sais pas si c'est vrai). Cela expliquerait pourquoi ce bit doit être défini en conséquence, en disant au noyau d'utiliser le bus système et d'accéder à la SRAM.
Question 2:
Bien qu'il puisse être vrai que la SRAM est vide au premier démarrage de l'appareil, ce n'est pas nécessairement pour les démarrages ultérieurs. Vous pouvez donc créer quelque chose comme un appareil alimenté par batterie qui obtient sa SRAM programmée pendant la production, puis fonctionne jusqu'à ce que la batterie soit morte, ce qui effacerait sa SRAM. Je suppose que cela rendrait la rétro-ingénierie de l'appareil un peu plus difficile.
Dans un appareil alimenté par batterie, vous utiliseriez probablement le mode veille pour économiser de l'énergie, et si vous quittez ce mode, les broches de démarrage sont échantillonnées à nouveau, elles doivent donc avoir le réglage correct pour accéder à nouveau à la SRAM.
Vous pouvez également redémarrer l'appareil en toute sécurité car le contenu de la SRAM n'est pas détruit s'il n'y a pas de coupure de courant.
Pas une application très convaincante pour rectifier tous les problèmes de remappage de la SRAM.
la source