Atmelstudio UC3C AVR32 – Objets d’infrastructure mal placés en mémoire?

Lors de la configuration d’une transmission CAN, un pointeur est corrompu (il passe d’un 0x00000bd0 valide à un 0x84520000 en dehors des limites de la RAM). Le pointeur n’est également pas lié à l’activité CAN. La raison de la corruption est qu’une union64 est écrite sur l’adresse du pointeur. Cette union64 appartient à l’object CANIF (de ASF), dans le code source la corruption se produit ici:

void CAN_SendMsg_KMS(uint64_t msg) { CANIF_mob_get_ptr_data(ACTIVECHANNEL,0)->data = (Union64)msg; AVR32_CANIF.channel[ACTIVECHANNEL].mober = 1<<0; }

Ma question est la suivante: pourquoi la mémoire de “données” est-elle allouée à la même adresse que mon pointeur? Ou est-ce une mauvaise conclusion?

Dans les captures d’écran suivantes, la première est immédiatement avant l’exécution de la fonction, la dernière est immédiatement après son exécution. Le contenu de “msg” est 0x8452000000000000. Le contenu du pointeur A qui est corrompu doit être 0x00000bd0, comme avant la corruption. Le nombre entier de 32 bits après le pointeur A est le pointeur B, le pointeur B pointe vers le pointeur A, son contenu non corrompu est donc 0x00000004 (comme indiqué dans la capture d’écran).

Mémoire avant corruption

Mémoire après corruption

Je ne sais pas s’il s’agit d’une information utile: selon la fiche technique, les registres CANIF sont à l’adresse mémoire 0xFFFD1C00.

update: il s’agit du code de niveau d’assemblage qui corrompt le pointeur:

// CANIF_mob_get_ptr_data (ACTIVECHANNEL, 0) -> data = (Union64) msg;

 80006AC8 mov R8, -189440 80006ACC ld.w R9, R8[8] 80006ACE st.d R9[8], R5

Dans la ligne:

 CANIF_mob_get_ptr_data(ACTIVECHANNEL,0)->data = (Union64)msg;

CANIF_mob_get_ptr_data est une macro donnant un pointeur de structure, défini selon la documentation comme:

 #define CANIF_mob_get_ptr_data( ch, mob ) ((can_msg_t *)(CANIF_SIZE_OF_CANIF_MSG*mob+CANIF_get_ram_add(ch)))

À son tour, la macro CANIF_get_ram_add est une macro renvoyant l’adresse contenue dans le registre d’interface CAN CANRAMB :

 #define CANIF_get_ram_add(ch) ( AVR32_CANIF.channel[ch].canramb )

Par conséquent, si AVR32_CANIF_CANRAMB n’est pas initialisé ou est incorrectement initialisé, le pointeur renvoyé par CANIF_mob_get_ptr_data ne sera pas valide et l’affectation ultérieure échouera.

Même si l’adresse résolue est invalide, un tel access, en l’absence de tout type de protection de la mémoire matérielle, a pour effet typique de “boucler” l’adresse afin qu’elle soit résolue en une adresse réelle non déterministe – corrompt donc la mémoire non liée.