Remappage de la table vectorielle dans STM32F0 (pas de registre de décalage vectoriel)

Carlos

Remappage de la table vectorielle dans STM32F0 (pas de registre de décalage vectoriel)


J’ai déjà écrit un chargeur de démarrage pour un STM32 qui prend en charge le décalage vectoriel et est facile à utiliser.

Pour STM32F0xx utilisant HAL, j’ai lu que je dois déplacer la table vectorielle vers le ram et la copier depuis le flash. J’ai fait pour autant que je sache toutes les étapes décrites ici:

http://marcelojo.org/marcelojoeng/2015/09/bootloader-on-stm32f0.html

Je peux passer du chargeur de démarrage à l’application, mais au moment où une interruption survient, elle se bloque.

Cependant, la SEULE chose que je n’ai pas faite est d’utiliser le script de l’éditeur de liens. J’ai changé comme suit les paramètres:

entrez la description de l'image ici

Et j’ai sélectionné « Disposition de la mémoire utilisateur du dialgo cible » sous Linker dans les paramètres du projet. Si j’essaie d’utiliser le script de l’éditeur de liens en écrivant simplement):

MEMORY
{
VTRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 192
RAM (xrw) : ORIGIN = 0x200000C0, LENGTH = 32K-192
FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 256K-32K
}

Je reçois l’erreur:

*** Using Compiler 'V5.06 update 5 (build 528)', folder: 'C:Keil_v5ARMARMCCBin'
Build target 'Target 1'
linking...
.ObjectsDimmerBackend.axf: Warning: L6914W: option ropi ignored when using --scatter.
.ObjectsDimmerBackend.axf: Warning: L6914W: option rwpi ignored when using --scatter.
.App2.sct(2): error: L6226E: Missing base address for region MEMORY.
.App2.sct: Error: L6630E: Invalid token start expected number or ( but found x at position 8 on line 3
.App2.sct: Error: L6629E: Unmatched parentheses expecting ) but found x at position 8 on line 3
.App2.sct: Error: L6226E: Missing base address for region VTRAM.
.App2.sct(3): error: L6292E: Ignoring unknown attribute 'xrw' specified for region VTRAM.
.App2.sct(3): error: L6228E: Expected '{', found ')...'.
.App2.sct(3): error: L6228E: Expected '}', found 'EOF'.
Not enough information to list image symbols.
Not enough information to list load addresses in the image map.
Finished: 2 information, 2 warning and 7 error messages.
".ObjectsDimmerBackend.axf" - 7 Error(s), 2 Warning(s).
Target not created.
Build Time Elapsed:  00:00:02

Sans le script de l’éditeur de liens, je peux accéder à l’application, mais planter en cas d’interruption. Par conséquent, je suppose que ce VTRAM magique et mystérieux est nécessaire.

Mes questions sont alors:

  • Qu’est-ce que ce VTRAM?
  • Pourquoi je ne peux pas utiliser ce script de l’éditeur de liens?
  • Comment générer automatiquement un script de l’éditeur de liens, je ne pense pas que les gens les écrivent eux-mêmes.
Carlos

Ça marche enfin! J’ai recommencé tout cela et je ne peux qu’imaginer que j’ai fait une petite erreur quelque part. J’étais frustré par le lien en pensant que c’était le problème. Un bon moyen de vérifier que l’adresse est correcte est de vérifier le fichier de carte. Assurez-vous ensuite de faire la copie correctement et de changer 0x0 pour ram avec la macro!

Réponses


 Makotanist

Dans ce script de l’éditeur de liens, la VTRAM est juste une zone arbitraire en RAM (les adresses commençant à 0x20000000 sont en RAM), où vous stockez les pointeurs vers vos ISR.

Comme le tutoriel le mentionne, vous utilisez l’entrée dans le fichier de l’éditeur de liens pour indiquer à l’éditeur de liens que ces 192 octets sont interdits d’utilisation comme RAM normale. Si vous n’utilisez pas de fichier de l’éditeur de liens personnalisé, l’éditeur de liens utilise la valeur par défaut: il peut utiliser toute la mémoire à toutes fins. Cela signifierait que ces pointeurs sont remplacés par des données. Lorsqu’un ISR se produit, il essaie de passer à l’adresse de la table vectorielle, qui a été écrasée et qui est maintenant une ordure.

Le fichier de l’éditeur de liens dans le tutoriel est pour GCC. Votre capture d’écran indique que vous utilisez l’IDE Keil, qui utilise armcc, et n’accepte pas la syntaxe. Vous devez soit:

une. Commencez à utiliser GCC (*)

b. « Traduire » le fichier de l’éditeur de liens GCC en un « fichier scatter » (utilisé par armcc).

c. Essayez de déclarer une zone en lecture seule IROM2 dans l’interface graphique (commencez à 0x20000000, taille 192), puis dans le code, déclarez quelque chose comme

volatile uint32_t VectorTable[] __attribute__((at(0x20000000))) = {
     FIRMWARE_START_ADDR,
     FIRMWARE_START_ADDR + 4,
     FIRMWARE_START_ADDR + 8,
     .....
};

Le pragma « at » indique au compilateur / éditeur de liens de placer le tableau de pointeurs à l’emplacement souhaité.

Vous avez raison et tort que « les gens n’écrivent pas [les fichiers de liens] eux-mêmes » . Ils le font, mais généralement en modifiant un modèle. Si vous décidez de traduire en fichier scatter, je vous suggère de rechercher un exemple et de le modifier pour l’adapter à votre cas.

(*) techniquement, il suffit d’appeler l’éditeur de liens GNU; vous pouvez peut-être compiler avec Keil / armcc et lier avec l’éditeur de liens GNU, mais je ne peux pas imaginer que cela en vaille la peine

Carlos

Merci pour votre réponse, très informative. J’ai ouvert le fichier de carte et je peux voir que la première adresse utilisée dans la RAM est à 0x200000c0 donc je dois supposer que cela fonctionne correctement sans le script de l’éditeur de liens. Si j’ouvre le chargeur de démarrage, je peux voir que le premier est en revanche à 0x20000000 comme prévu. Alors je ne sais pas quoi d’autre pourrait manquer? Je n’ai pas désactivé toutes les interruptions périphériques car lors de l’utilisation de l’offset vectoriel ne semblait pas nécessaire. Je peux essayer, sinon avez-vous une suggestion sur ce qui pourrait être faux? Comme je l’ai dit, je ne peux démarrer que lorsque l’interruption survient, il se bloque.

Makotanist

Je ne suis pas sûr de ce que vous entendez par « Si j’ouvre le chargeur de démarrage, je peux voir que le premier est en revanche à 0x20000000 comme prévu ». Le chargeur de démarrage doit copier les valeurs de 0x08001000 à 0x080010C0 (les pointeurs ISR de l’image chargée) vers 0x20000000 à 0x200000C0. De cette façon, lorsque vous utilisez la macro __HAL_SYSCFG_REMAPMEMORY_SRAM (), le processeur peut trouver les ISR en regardant le début de SRAM. La figure 4 du didacticiel illustre cela.

 

#de, #la, #pas, dans, décalage», registre», Remappage, STM32F0, table, vectoriel, vectorielle

 

google

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *