J'essaye d'émuler le contrôleur STM32F407XX avec le processeur cortex M4 sur QEMU. J'ai écrit le fichier .ld comme ci-dessous:
Qemu: fatal: Lockup: cant escalate 3 to Hardfault (Current Priority -1) error. Aborted (Core Dumped)
Lorsque je génère le fichier .elf et exécute le code, j'obtiens l'erreur
ENTRY(_Reset)
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K
PERIPHERALS(rw) : ORIGIN = 0x40000000, LENGTH = 128K
}
SECTIONS
{
.startup . : { stm32.o(.text) } >FLASH
.text : { *(.text) }
.data : { *(.data) } >RAM AT> FLASH
.bss : { *(.bss COMMON) } >RAM
. = ALIGN(4);
. = . + 0x400; /* required amount of stack */
stack_top = 0x20020000;
}
Je sens que c'est un problème de mémoire. Qu'est-ce que je fais mal? J'ai alloué les mémoires flash et RAM conformément aux exigences du manuel de référence pour STM32F407.
Pourquoi cette erreur survient-elle en premier lieu et comment puis-je résoudre cette erreur? Merci.
3 Réponses :
Vous devez réinitialiser votre ROM après le chargement de votre noyau dans votre machine (après l'appel à armv7m_load_kernel ). Vous pouvez utiliser par exemple:
rom_check_and_register_reset(); qemu_devices_reset();
Le processeur doit démarrer lors de la réinitialisation du gestionnaire.
Le problème était que le gestionnaire de réinitialisation n'était pas placé là où le processeur l'attendait. A travaillé sans la réinitialisation de la ROM.
Placer la table vectorielle au bon endroit a résolu le problème. J'ai suivi toutes les instructions de @peter Maydell dans les commentaires ci-dessus. Je les ajoute ici.
Vous pouvez activer certaines des options de journalisation du débogage de QEMU avec -d ('in_asm, int, exec, cpu, guest_errors, unimp' sont probablement un bon ensemble pour commencer), qui vous dira quel est votre code invité fait. Je commencerais par vérifier que votre fichier ELF contient une table vectorielle à l'endroit où QEMU s'attend à le trouver. Sinon, QEMU sera immédiatement en panne après la réinitialisation (ce que fait le matériel).
Le vidage de mémoire est attendu: QEMU entre en verrouillage, mais nous n'émulons pas correctement le verrouillage (à proprement parler, QEMU devrait simplement rester assis à ne rien faire comme le matériel réel), donc nous affichons un vidage de registre et abandonnons (). Comme je l'ai dit dans mon commentaire précédent, votre problème est presque certainement que votre binaire n'a pas de table vectorielle.
La principale chose que vous devez avoir dans votre table vectorielle est les entrées pour le PC initial et le pointeur de pile. Les entrées d'interruption et d'exception valent la peine d'être ajoutées mais ne seront nécessaires qu'en cas d'interruption ou d'exception. Si vous mettez en place des gestionnaires de débogage pour les autres erreurs, vous saurez au moins quand vous obtenez une erreur due à un bogue dans le reste de votre programme, cependant
Informations supplémentaires pour toute personne comme moi qui rencontre ce problème en essayant de corriger une erreur matérielle qemu: J'ai eu la même erreur matérielle en raison d'une instruction non mise en œuvre.
Cela s'est produit parce que j'ai compilé le code avec -mcpu = cortex-m4 mais j'ai exécuté qemu avec -cpu cortex-m3
La chose la plus délicate à ce sujet est que cela fonctionne pour la plupart du code car gcc n'utilise le plus souvent aucune des "instructions m4-only" (même en fonction du niveau d'optimisation - cela fonctionnait avec - O1 mais a échoué avec -O2 ) ...
Une faute matérielle signifie généralement un bug lié à un pointeur ou à un compteur de programme. Un seul pas et voir où ça se passe? En remarque, vous devez placer la pile de 0x20000000 -> 0x2000xxxx. Vous ne voulez pas qu'il déborde dans .bss.
Vous pouvez activer certaines des options de journalisation de débogage de QEMU avec -d ('in_asm, int, exec, cpu, guest_errors, unimp' sont probablement un bon ensemble pour commencer), qui vous dira ce que fait votre code invité. Je commencerais par vérifier que votre fichier ELF contient une table vectorielle à l'endroit où QEMU s'attend à le trouver. Dans le cas contraire, QEMU provoquera une panne matérielle immédiatement après la réinitialisation (ce que fait le matériel).
J'ai également oublié de mentionner que j'obtiens une erreur de vidage de base avec l'erreur de verrouillage
Le vidage du noyau est attendu: QEMU entre en verrouillage, mais nous n'émulons pas correctement le verrouillage (à proprement parler, QEMU devrait simplement rester assis à ne rien faire comme le matériel réel), nous imprimons donc un vidage de registre et abandonnons (). Comme je l'ai dit dans mon commentaire précédent, votre problème est presque certainement que votre binaire n'a pas de table vectorielle.
vous avez raison, je comprends le problème maintenant. J'ai défini la moitié de la table vectorielle (uniquement pour les défauts et systick mais pas pour le GPIOS et les autres périphériques que le code attend. Je les définirai également dans mon fichier .s et générerai le fichier .bin et vérifierai. Merci Peter.
La principale chose que vous devez avoir dans votre table vectorielle est les entrées pour le PC initial et le pointeur de pile. Les entrées d'interruption et d'exception valent la peine d'être ajoutées mais ne seront nécessaires qu'en cas d'interruption ou d'exception. Si vous mettez en place des gestionnaires de débogage pour les autres défauts, vous saurez au moins quand vous obtenez une faute due à un bogue dans le reste de votre programme, cependant.
Merci @PeterMaydell, c'était exactement le même problème et j'ai pu le résoudre. Comme vous l'avez dit, la table vectorielle n'était pas à l'adresse attendue. Je pourrais le vérifier avec la commande readelf -Wl, maintenant cela fonctionne très bien. C'était plus facile à comprendre de cette façon. Merci.