This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
I am debugging a DM6467 based codec engine and keep getting the message "cannot load from non-primitive location" in the watch window when I try to display some structure pointers which are cast to types other than their native type. Can anyone tell me what the message generally means ?
Many thanks,
Mike
Mike,
This message means that the expression tried to read and display data from the target where the type of the data is not a primitive type (char, short, int etc). For instance, "main" is of type "function pointer" so evaluating "*main" would be asking the debugger to display data of type "function" which doesn't make much sense and would return this error.
At least, that's what it's supposed to mean. If that doesn't make sense in your case, could you attach a small test program with the struct in question and show what evaluations incorrectly return that error message incorrectly?
Darian
I have this problem with any symbol defined in linker file regardless of the fact that this symbol is extern-ed as a type in C source and being used by the code. For instance
Linker:
.flash_wrapper : (NOLOAD) { _Flash_Registers = .;} > FWM
Header:
typedef struct FLASH_REGISTERS_TYPE_TAG
{
.............
} FLASH_REGISTERS_TYPE;
extern FLASH_REGISTERS_TYPE Flash_Registers;
Source:
Flash_Registers.Read_Control = ....;
The way to get CCS to display it as a structure is to use this expression in Watch window:
(FLASH_REGISTERS_TYPE *)Flash_Registers
This means that symbol information is there but CCS can not find it for some reason. It is the same in CCSv3.3 and CCSv4.
If a structure is completely declared and defined in the C code then watch window is working fine.
Eugene
Eugene,
When variables are declared in the linker command file like that, the symbol information gets stripped off. As such, the debugger only sees "Flash_Registers" as a label, vs a variable with a type. As such, you have to cast it to let the debugger know that you want it considered a variable of that type.
I've spoken to some of our compiler experts and they're not sure what the issue may be, but I've filed a bug to track it regardless: SDSCM00033924
In the meantime, they have a workaround you can use, although it will require code changes: Actually declare the object in the C data and place it in its own DATA_SECTION. Then in the linker command file, place that section instead of trying to define the symbol.
#pragma DATA_SECTION(Flash_Registers, ".flash_wrapper") FLASH_REGISTERS_TYPE Flash_Registers;
SECTIONS
{
.flash_wrapper > FWM1
}
Hope that helps,
Darian
Darian,
Thanks. It is tricky to implement this workaround in our environment as typedefs are in header files that do not have corresponding C files. Lets wait and see what linker team can do about keeping symbol information.
Eugene
Darian,
I am experiencing a simular problem on the C6000 platform, specifically on the C6727. I am utilizing TI's chip support library to setup dMax for a SPI slave transfer. In doing so I must cast a structure member of each of the two referenced variables below to CSL_dmaxParamSetup and CSL_dmaxEventSetup types, respectively. Doing so produces the error "cannot load from non-primitive location" in the watch locals window in CCS. This error "cannot load from non-primitive location" causes the CSL_dmaxHwSetup() function to fail.
CSL_DmaxSpiParameterSetup dmax_spiparamsetup
CSL_DmaxSpiSlaveTransferEventSetup dmax_spievent.paramSetup
Would the work around above apply this platform and scenario, casting TI defined Structures in C code?
Amanda,
I'm actually not all that familiar with the CSL. Would you be able to compile and attach a small example .out file with the necessary structures and let me know precisely what expressions you are entering in the watch view that return this error message?
Also, you mentioned that the watch view error message causes the function to fail on the target. The watch view only reads memory and registers, so it shouldn't affect target execution (unless there's a silicon bug where a read causes some side effect). If you close the watch (or locals) view, does the function succeed?
Darian
Darian,
Thank you for your response. I realized that the message in the watch veiw window "cannot load from non-primitive location" was not causing the CSL_dMaxHwSetup() function to fail, but that since the variable was a structure and not a char, int, etc. it could not display its value. I dug a little deeper by finding the code for function CSL_dMaxHwSetup() within the install files. From evaluating this function I found that either the casting of the variables that I sighted above were not being handled correctly by the compiler/linker, or that the "etype" that I provided in the CSL_dMaxHwSetup structure was not what this function was looking for. Initially I assigned the hex value of 0x00010 to the spi field of the CSL_DmaxSpiSlaveTransferEventSetup structure. This is the value specified by the dMax documentation to select an etype of spi slave transfer in the event entry register. The etype field is selected with bits 0-4 of this register. Within TI's include file cslr_dmax.h, There is a definition for an etype of value 0x00000002u for event 0 named, CSL_DMAX_EVENT0_ETYPE_SPISLAVEXFR. When I used this contant to set the value of the "etype" field of the CSL_DmaxSpiSlaveTransferEventSetup structure, the CSL_dmaxHwSetup() function did not fail, but returned a status of CSL_SOK. Therefore the value of the etype field for the structure was causing CSL_dmaxHwSetup() function to fail.
My concern is that this is not the correct value that I need to setup the dMax for an SPI 1 slave transfer, which is event 14. There is no definition for spi slave transfer for any event other than event0. If I add the needed case statement for CSL_DMAX_EVENT14_ETYPE_SPISLAVEXFR, which is (0x00000010u) to function CSL_dmaxHwSetup(), and add a #define statement to cslr_dmax.h for a serial peripheral interface port 1 (SPI1) slave transfer (# define CSL_DMAX_EVENT14_ETYPE_SPISLAVEXFR (0x00000010u) ), how can I rebuild these files and produce a new csl_C6727.lib library file? I have tried to do this by running the C6727 makefile executable found within TI's install directories. However, no new executable was produced. Please advise.
If you will provide your e-mail address, I can e-mail the referenced functions to you, as I cannot attach them to this post.
Thanks,
Amanda
Hi Darain,
The example you mentioned in this message , with main and "*main" is happening with my code. "error cannot load from non-primitive location", Could you please let me know the resolution for this problem?
Actually ,have gone through all the forum conversations and have tried the stack size change approach, as well as other approaches stated. But not able to solve the problem.
Hi Tanmayee,
In the screenshot, you are getting errors when you try to deference a variable of type void*. If you know it's actual type, you can cast it in the expressions view and then expand it to see it's members. For instance:
(MyStructType*)ADCDRV_1ch_Rlt3
Darian
Thanks Darian,
Tried the casting, and now I am able to view the values of parameters.
Regards,
Tanmayee
Thanks Richard. Your reply should be selected as the right answer too. I got into the exact problem and your post helped me out.
I created a new project and by default the heap size was default to 0x0 and the stack size was default to 0x512. I oversaw the project settings and didn't spot this out until I saw your post.
Notes to TI: I think the CCS project template should really need to be changed to give the heap size something more sensible than 0x0 (can't do anything with zero heap size). It was a pain to figure out why Tera Term didn't work for me while all the code looked perfectly fine.
Hi ,
Is there someone who can tell the solution? Stack size approach not working please suggest something.
Thanks
Regards
Mehwish
Girish and Mehwish,
If you post a picture of your expressions view when you get this error, I may be able to explain it to you. Most likely the variable is a void* and you are trying to deference it. You would have to cast the variable to see it.
I suspect that for most people seeing this issue, the suggestion to change the stack size will not work.
Darian
Mehwish,
It's very hard to read the text on that picture, but it looks like you are hovering over a function. Functions have a value (where they are located in memory), but cannot be dereferenced, even though their type is a pointer type. Dereferencing them would be equivalent to calling them. This is as expected.
Are you seeing this error in a case where you expect the expression to evaluate to a value?
Darian