We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello!
A function is called with three pointer parameters to assemble command messages for SPI-mode communication in SPI initialization function as follows.
Problem is that the addresses of parameters change when they go into the function.
This error occurs in working with debugging version and monitor program.
CMD_Message 0x00007DD0 -> 0x7FDD0 CMD_Argument 0x00007DCC -> 0x7FDCC CMD_Index 0x00007DCA -> 0x7FDCA
So that the assembled CMD_Message shows wrong results. I am working with Memory model of HCompact:'huge' data, 'near'func.
unsigned integer i; unsigned char CMD_Index; unsigned char CMD_Argument[4]; unsigned CMD_Message[6]; Assemble_CMDMessage(&CMD_Index, CMD_Argument, CMD_Message);
void Assemble_CMDMessage(unsigned char *CMD_index, unsigned char *CMD_argument, unsigned char *CMD_Message) { // Command Index consists of star bit of 1 bit, transmission bit of 1 bit, and command index of 6 bits. unsigned char good_crc7; xmemcpy(CMD_Message, (unsigned char *)CMD_index, sizeof(unsigned char)*1); // CMD_Message[0] xmemcpy(CMD_Message+1, (unsigned char *)CMD_argument, sizeof(unsigned char)*4); // CMD_Message[1] - CMD_Message[4] //Generate_CRC7(CMD_message); //generate a valid CRC field; good_crc7 = Generate_CRC7(CMD_Message); good_crc7 = good_crc7 << 1; // shift to left by 1 CMD_Message[5] = good_crc7; CMD_Message[5] = CMD_Message[5] + 1; // add end bit }
I would be really happy if anybody inform me of what causes this eror. Thanks. Yoong-Goog Cho
Looking at the code "that works properly" I can see that the pointers passed as arguments are in fact near pointers, while in the code "that does not work properly" the arguments are 32-bit pointers (most likely huge). Probably you changed memory model at some point in the development of the program, but some code steal depends on the old memory model. It's just a guess, though.
- mike
It's still, not steal. What was I thinking? :-) On the other hand, English is not my first language, so please excuse my mistakes.
Thanks Mike.
Yes, I used the memory model of Small 'near' functions and data for the code that works properly because it is a kind of simple test program.
After confirming that all functions work properly, I integrated the codes into the firmware which consists of various functions. For this, I used the memory model of HCompact 'huge' data, 'near' function.
However, I don't know why the parameter values (addresses) change when they go into the called function.
-Yoong-Goog
I don't know why the parameter values (addresses) change when they go into the called function.
If you read the compiler manual, you will see that in HCOMPACT memory model
Variables are stored in huge memory when they require more space than defined by the HOLD directive.
www.keil.com/.../c166_le_modelhcompact.htm
Probably all three variables in question are smaller than your HOLD threshold, so all three variables are near. But the function arguments are huge pointers, so the addresses have to be converted from near to huge.
Regards, - mike
Hello! Mike.
The problem has been resolved temporarily by putting near data type before each argument of the called function. However, I am going to find out more fundamental solutions for this issue, which will take some time.
Your suggestion and comments were very helpful. I really appreciate your help.
Thanks.
Regards,
Yoong-Goog Cho