This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

scater file problems

Hi
I am using uvision to develop code for LPC1768. my code is not small but I am sure I have lots of unused SRAM and I have assigned enough heap and stack

But I have a problem. Some of my variables get values other than what they should have. For example a variable that I set it 1 in timer interrupt (and define it volatile when declaring it), is having 0 value when is referred to in code, etc

When these problems happen, I define the variable in a specific address, like this

unsigned char Flash_write_values[512] __attribute__((at(RAM_BaseAddress + 0x5000)));
unsigned char Flash_Data[512] __attribute__((at(RAM_BaseAddress + 0x5200)));
volatile unsigned char  SMS_QueueActive __attribute__((at(RAM_BaseAddress + 0x5A04)));

Now that my code is getting bigger, this problem is occurring more frequently.
Maybe I should define all my variables in specific addresses. What is your opinion?

I started studying linker manuals to learn how to create scatter files, but it seems the manuals are too large and not enough simple to work/start with

How do you suggest me to proceed?
Thanks in advance

  • You can have your variables in a specific source file (without any absolute addresses specified) and have the full source file store the variables in a different memory region by using the scatter file.

    Absolute addresses is best when you need to map a specific variable to overlap specific hardware - it really shouldn't be used to make the linker's task into your task. Remember that if you change the size of one of your arrays, then you suddenly have to recompute a whole lot of absolute addresses. Bad, bad, bad.

    But another thing - are you remembering to make your variables volatile, when they are modified by an ISR but read by the main loop? It really is a must, to inform the compiler that there are asynchronous changes possible to the variable values. Else the compiler will generate code that assumes it knows all places where the variable gets changed, so the code may cache old values of the variable in registers.

  • Thanks Per Westermark
    When I create and compile a project, a SCT file is generated automatically
    This is the content of that file:

    LR_IROM1 0x00000000 0x00080000  {    ; load region size_region
      ER_IROM1 0x00000000 0x00080000  {  ; load address = execution address
       *.o (RESET, +First)
       *(InRoot$$Sections)
       .ANY (+RO)
      }
      RW_IRAM1 0x10000000 0x00008000  {  ; RW data
       .ANY (+RW +ZI)
      }
      RW_IRAM2 0x2007C000 0x00008000  {
       .ANY (+RW +ZI)
      }
    }
    

    If I put all my variables in a specific source file like "variables.h" and include it in my main program file, how should I change the code above? Could you please illustrate it for me? I was confused among linker documentation, maybe this example help me

    Thanks again

  • But I have a problem. Some of my variables get values other than what they should have. For example a variable that I set it 1 in timer interrupt (and define it volatile when declaring it), is having 0 value when is referred to in code, etc

    When these problems happen, I define the variable in a specific address, like this
    That reaction makes no sense whatsoever. Even if it does help sometimes, that's by coincidence, not by design.

    You have to find out what actually happens with your code. The position of a variable in memory has no real significance for that. Did you really qualify both the definition and all declarations of those variables volatile?

  • Hey now - the linker have zero knowledge about the existence of any header files.

    Note that the linker works with object files - and it isn't header files, but *.c, *.cc, *.cpp, *.cxx or similar that is the reason that the compiler spits out object files. As you can see in your scatter file, there are references to *.o - which seem to imply "all" object files. A daring guess might solve the issue of how to instruct the linker what to do with RW and ZI data for a specific object file.

    To get a symbol (variable or function) into a specific object file, the linker don't care about what you do with your header files. And since you seem to think that putting the variables in a single header file would be the solution, I just need to recommend that you take a look in a C/C++ programming book about the difference between definition and declaration of variables. How to tell the compiler that there exists a variable. And how to tell the compiler that you want the memory for a variable allocated within code/object data it emits.

  • Hi again
    I'm sorry but it still seems that my variables are getting changed with no reason

    In more tests, I noticed when I change some local variables to global variables, the problems happen less

    Maybe the problem is "stack overflow"
    But I have set the stack size an enough big number in configuration wizard of lpc17xx_startup.s

    Should I change anything else to have enough stack size?

    Maybe I should define what address of RAM should be used for stack in scatter file, but I can't understand how to do this based on my studies of linker manuals ):

  • In more tests, I noticed when I change some local variables to global variables, the problems happen less
    Local vs global is almost certainly the wrong distinction. The only aspect that would be important is automatic vs. static storage duration.

    Maybe the problem is "stack overflow"
    But I have set the stack size an enough big number in configuration wizard of lpc17xx_startup.s

    Those two statements contradict each other to some extent. Either you know your stack is big enough, or you don't. There's not really any middle ground.

    That said, I'm afraid you're still jumping to conclusions. Forget about the scatter file. Forget about the stack size, at least for the moment. You have to diagnose this properly, instead of doing essentially random modifications to the code and hoping they'll cure something.

    There is clearly something seriously wrong with your code. But so far, you have not got one step closer to knowing what the problem is. For all you've established so far, it could be anything, e.g. a wild pointer, buffer underflow, buffer overflow, stack overflow, stack underflow, misaligned data access, a misconfigured compiler (register locations wrong, ...), or any combination of those.