问题
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). The pointer is also unrelated to the CAN activity. The reason for the corruption is, that a union64 is written over the address of the pointer. This union64 belongs to the CANIF object (from ASF), in sourcecode the corruption happens here:
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. The content of the pointer A that is corrupted should be 0x00000bd0, as it is before the corruption happens. 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).
I don't know if this is a useful information: According to the Datasheet the CANIF registers are at Memory address 0xFFFD1C00.
update: This is the assembly level code that corrupts the pointer:
//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
回答1:
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:
#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
:
#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.
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.
来源:https://stackoverflow.com/questions/43387873/atmelstudio-uc3c-avr32-framework-objects-in-wrong-place-in-memory