简体   繁体   English

Atmelstudio UC3C AVR32-框架对象在内存中的错误位置?

[英]Atmelstudio UC3C AVR32 - framework objects in wrong place in memory?

During the setup of a CAN transmission, a Pointer is being corrupted (it goes from a valid 0x00000bd0 to a 0x84520000 that is out of the bounds of my RAM). 在设置CAN传输期间,指针已损坏(指针从有效的0x00000bd0变为超出我的RAM范围的0x84520000)。 The pointer is also unrelated to the CAN activity. 该指针也与CAN活动无关。 The reason for the corruption is, that a union64 is written over the address of the pointer. 损坏的原因是,在指针的地址上写入了union64。 This union64 belongs to the CANIF object (from ASF), in sourcecode the corruption happens here: 此union64属于CANIF对象(来自ASF),在源代码中,此处发生损坏:

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

My question is, why is the memory for "data" allocated at the same address as my pointer? 我的问题是,为什么“数据”的内存分配给与指针相同的地址? Or is this a wrong conclusion? 还是这个错误的结论?

In the following screenshots, the first is immediately before the function is executed, the last is immediately after execution. 在以下屏幕截图中,第一个紧接在函数执行之前,最后一个紧接在执行之后。 The Content of "msg" is 0x8452000000000000. “ msg”的内容为0x8452000000000000。 The content of the pointer A that is corrupted should be 0x00000bd0, as it is before the corruption happens. 指针A损坏的内容应为0x00000bd0,就像发生损坏之前一样。 The 32Bit integer after the pointer A is pointer B, pointer B is pointing at pointer A, its uncorrupted content is therefore 0x00000004 (as seen in the screenshot). 指针A之后的32Bit整数是指针B,指针B指向指针A,因此其未损坏的内容为0x00000004(如屏幕截图所示)。

腐败前的记忆

腐败后的记忆

I don't know if this is a useful information: According to the Datasheet the CANIF registers are at Memory address 0xFFFD1C00. 我不知道这是否是有用的信息:根据数据表,CANIF寄存器位于存储器地址0xFFFD1C00。

update: This is the assembly level code that corrupts the pointer: 更新:这是破坏指针的程序集级代码:

//CANIF_mob_get_ptr_data(ACTIVECHANNEL,0)->data = (Union64)msg; // 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

In the line: 在该行中:

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

CANIF_mob_get_ptr_data is a macro yielding a structure pointer, defined according to the documentation as: CANIF_mob_get_ptr_data是产生结构指针的宏,根据文档定义为:

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

In turn the macro CANIF_get_ram_add is a macro returning the address contained in the CAN interface register CANRAMB : 反过来,宏CANIF_get_ram_add是一个宏,返回包含在CAN接口寄存器CANRAMB的地址:

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

So if AVR32_CANIF_CANRAMB is not previously initialised, or incorrectly initialised, the pointer returned by CANIF_mob_get_ptr_data will not be valid, and the subsequent assignment will fail. 因此,如果AVR32_CANIF_CANRAMB先前未初始化或未正确初始化,则CANIF_mob_get_ptr_data返回的指针将无效,并且后续分配将失败。

Even if the resolved address is invalid, the typical effect of such an access in the absence of any kind of hardware memory protection is to "wrap" the address so that it resolves to a non-deterministic real address - so corrupts unrelated memory. 即使解析的地址无效,在没有任何种类的硬件内存保护的情况下,这种访问的典型效果是“包装”该地址,使其解析为不确定的真实地址-从而破坏了不相关的内存。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM