J'utilise la carte STM32L486ZG en mode pouce. Je cours une application simple de métal nu sans aucun RTOS. J'ai SRAM externe connecté à la carte en utilisant FSM. La SRAM externe est située à l'adresse 0x60000000. Le système est initialisé et en cours d'exécution à 72MHz (j'ai essayé cette question avec une fréquence 18-80 MHz) maintenant dans ma fonction principale que j'ai le code suivant:L'instruction LDMIA ne fonctionne pas correctement sur la SRAM externe dans le cortex M4
int main(){
asm volatile (
"push {r0}\n"
"mov r0, #0x60000000\n"
"add r0, #0x400\n"
"stmdb r0!, {r1-r12}\n"
"ldmia r0!, {r1-r12}\n"
"pop {r0}\n"
);
}
Selon ce code ne registre doit être changé après fonction principale a exécuté, mais ce n'est pas le cas après l'instruction suivante
ldmia r0!, {r1-r12}
-à-dire r9 n'est pas correct après l'exécution. stmdb instruction fonctionne correctement mais ldmia ne charge pas les données correctement. J'ai vérifié cela en regardant le contenu de la mémoire.
Ce problème persiste avec tous les arguments de l'instruction ldmia: le 9ème registre est toujours affecté.
Explication: Disons que je suis mise au point de ce code et l'instruction suivante à exécuter est la suivante:
stmdb r0!, {r1-r12}
après avoir quitté tous ces registres ont été enregistrés dans la mémoire et la valeur de r0 est 0x600003d0
le contenu de la mémoire:
0x600003D0 00000000 40021008 0000000C [email protected]
0x600003DC 40000000 00000000 00000000 [email protected]
0x600003E8 20017FEC 00000000 00000000 ì.. ........
0x600003F4 00000000 00000000 00000000 ............
des registres:
r0 0x600003d0
r1 0x00000000
r2 0x40021008
r3 0x0000000c
r4 0x40000000
r5 0x00000000
r6 0x00000000
r7 0x20017fec
r8 0x00000000
r9 0x00000000
r10 0x00000000
r11 0x00000000
r12 0x00000000
cela montre que tous les registres sont sauvegardés avec succès dans la mémoire. Maintenant, j'étape, l'instruction suivante
ldmia r0!, {r1-r12}
après ceux-ci sont le contenu des registres:
r0 0x60000400
r1 0x00000000
r2 0x40021008
r3 0x0000000c
r4 0x40000000
r5 0x00000000
r6 0x00000000
r7 0x20017fec
r8 0x00000000
r9 0x555555d5
r10 0x00000000
r11 0x00000000
r12 0x00000000
que vous pouvez voir tous les registres sont restaurés à l'exception r9 qui a curieusement sa valeur « pop » ed de 0x60000000 au lieu de 0x600003F0.
Une idée de ce qui pourrait être à l'origine de ce problème. J'utilise Jlink pour écrire en flash.
P.S.Ce problème ne se produit pas lorsque les registres sont enregistrés sur SRAM onchip par opposition à SRAM externe;
modifier si l'instruction
ldmia r0!, {r1-r12}
est divisé en deux parties comme:
ldmia r0!, {r1-r6}
ldmia r0!, {r7-r12}
alors tous les registres sont restaurés avec succès
"J'ai une application SRAM externe connectée à la carte avec FSM" ... Qu'est-ce qu'un ** FSM ** – fazkan
Les registres au-delà du 9ème sont-ils toujours corrects? Le fait qu'il semble aller de travers à une limite de 32 octets sent un peu comme si les lignes d'adresse ne sont pas câblées à droite ou le contrôleur de mémoire n'est pas configuré correctement (en particulier en ce qui concerne le fractionnement AHB et/ou le timing) . – Notlikethat
@Notlikethat Oui, ils sont toujours corrects que le 9 est le défectueux. – ALK007