• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 32 subscribers
  • Views 862 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Declaring a global variable causes unintended behavior

Safiullah Hussaini
Intellectual 885 points

Other Parts Discussed in Thread: CCSTUDIO

I am just declaring a variable which causes one of my LUTs to fail to initialize properly. The variable is not a pointer, just a normal variable so I dont think its a garbage dereference issue.

I faced a similar issue on the TM4C123G series chip, where I found that the issue was with a memory misalignment. However I have been careful in my code to keep the variables 4 byte alligned. (but I cant be a 100% sure)

Could it be the same issue here? If so, how do I confirm and solve?

  • 0
    TI__Guru 69070 points
    Safiullah,

    Don't really understand the problem. I think we need more details. For example, do you initialize this global variable before using it?
  • 0
    Guru 15185 points
    you try to create a new project with the same characteristics and copy your code in this?

    I also have a similar problem when my schedule takes lots of instructions and function calls; this is because generally I do not use data structures in my code.

    this was solved since using data structures in CCSv6 and Hercules MCU.
  • 0 in reply to Martin Valencia
    Intellectual 885 points
    I will try this in the morning.

    Yeah I have not used a lot of data structures in my code. So does the compiler have a limit on how many global variables that can be declared in a single file or some such limitations?

    Will switching compilers (say I switch to gcc) solve this?
  • 0 in reply to Anthony F. Seely
    Intellectual 885 points
    Yes I have. Bear in mind these are not pointers, and just definition (no usage in runnable or non executing code) of these variables (say a uint8 or uint32) will cause the issue.
  • 0 in reply to Safiullah Hussaini
    TI__Guru 69070 points
    Some add'l questions:

    -What is the address of the global variable?

    -Have you tried to use the watchpoint feature of the CPU to catch whoever is writing over the value? (If it is from your code).

    - Do you have any DMA channels enabled or any other peripherals like ethernet or USB or HTU that are in use and have the capability to write to RAM.

    - Do you have sufficient stack space? If your stack spills outside it's allocated space, then it could corrupt other data in RAM like your global variables. (Watchpoint would catch this.)
  • 0 in reply to Anthony F. Seely
    TI__Guru 69070 points
    Add'l comments: This shouldn't be an issue related to any sort of compiler limitation. Of course you need to have sufficient *memory* for the global variables you want to use but if you don't then the linker will fail with a message that there isn't enough space.

    The stack overflow problem isn't something that the linker can resolve unfortunately. So it is a real possibility.

    Structures help organize your data so they'll increase the likelihood it isn't a coding error.
    But the compiler can handle either just as well.
  • 0 in reply to Anthony F. Seely
    Intellectual 885 points
    Since this is a global variable, should n't it be the data segment that overflows and not the stack?
    Any tools built into the CCstudio with which I can check what actually is the problem?

    Also, the RAM size is pretty big, so I think adjustment of the segments should do the trick, but a) the TI compiler does not give the size of the segments after the compilation is complete like a lot of others do, Is there an option or flag that I have to enable? also, if it is the segment size that is causing the problem, how do I fix it?
  • 0 in reply to Anthony F. Seely
    Intellectual 885 points

    The global variable is at 0x08001930.
    I found this by adding a watch expression at the very beginning of the run. Expression was "&g_var".

    I have not tried the watch point because I dont know where is the code to actually put it.

    I do have the HTU running, but the HTU is reading from the CPU space and writing to the N2HET space. So unless some order of the code memory gets written (specifically the code where I initialize the HTU DCPs) but just declaring/definiing this variable, I dont see why that would be a problem. Also, the problem occurs very early in the code, a point where the HTU initialization code has not even been executed yet.

    for the stack space, It could be an issue. But my variable is a global variable, so should n't it be in the data space. Maybe the data space overflows into the sack space? I dont know. How do I find out though?

  • 0 in reply to Safiullah Hussaini
    TI__Guru 69070 points

    Safiullah Hussaini said:
    Maybe the data space overflows into the sack space? I dont know. How do I find out though?

    Yes this is what normally occurs in case of a problem like this.


    You could try simply increasing the size of the stacks and see if the problem goes away.   It would be better to avoid this problem by careful placement of the Stack at the bottom of SRAM (because stacks are full - descending so they overflow 'down') and using the MPU to cause an exception if there is an overflow.
    But it is a lot quicker to just double the stack size assuming you have sufficient RAM.

    The Watchpoint feature is a special type of breakpoint.  So in CCS open the breakpoint window  (I think it is view->breakpoints)  you can add a breakpoint at the address of the global variable, and change it's type to a watchpoint.    A watchpoint will halt the program when the variable is *written* (or read - this can be configured) rather than when the address is executed as an instruction.
    Very handy to learn how to use this feature for debugging programs.