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.

Stack filled to 100%

Other Parts Discussed in Thread: CC430F6137

I'm facing a difficulty. I wrote a code that copy bytes from msp430 flash to a spi external memory. I create a logging file during the debug session in order to monitor what does happen. At the beginning there was no problem, but  when I add the logging file, I've got this error after few minutes of execution:

Thu May 27 16:54:31 2010: Fatal error: Failed to identify device   Session aborted!
Thu May 27 16:54:31 2010: Unable to execute: driver busy.
Thu May 27 16:54:31 2010: The stack 'Stack' is filled to 100% (120 bytes used out of 120). The warning threshold is set to 90.%

Here is a part of my code:

 ecriture_octet(*p,k);               
 data_mem = lecture_octet(k); 
 logout_octet(k, *p);                     

void logout_octet(char serie, char test)
{
  char tempo=0;
  char to_print[21] = "000:IN:00/OUT:00/KO";      
  to_print[19]='\n';                  
  to_print[0] = HEX_TO_ASCII((char)serie>>8);
  to_print[1] = HEX_TO_ASCII((char)serie>>4);
  to_print[2] = HEX_TO_ASCII((char)serie);
  to_print[7] = HEX_TO_ASCII(test>>4);      
  to_print[8] = HEX_TO_ASCII(test);
  to_print[14] = HEX_TO_ASCII(data_mem>>4);
  to_print[15] = HEX_TO_ASCII(data_mem);
 
  if(test == data_mem)     
  {
    to_print[17]='O';
    to_print[18]='K';
  }
   

 for(tempo=0;tempo<20;tempo++)
  {
    putchar(to_print[tempo]);
  }


  }

 

The error come when I use the putchar function. I don't understand why does putchar overflows my stack.

Did someone face the same problem? or get another solution to generate a logging file without overflowing the stack?

 

Thanks,

 

Guillaume

  • Thu May 27 16:54:31 2010: Fatal error: Failed to identify device   Session aborted!

     

    ^^ You aren't concerned with this error? What IDE are you using?

  • Guillaume,

    Pre-defined C calls such as printf and putchar are fairly CPU and RAM intensive. Especially if you already have a number of user defined variables filling up RAM space.

    Try increasing the stack size and see if you can recreate the error.

    Regards,

    Priya

  • I'm using IAR Workbench. The problem is that the program run fine until the error appears. putchar works fine and the logging file is good. But after many loop, the stack appears to be overflown.

  • Today, the program works fine... I do not modiffy anything. Have you heard about stack monitoring problems with IAR?

  • There is an easy way to figure out if you are running into a stack issue. Have a look at "Advanced Debugging Using the Enhanced Emulation Module (EEM)" application report at http://www-s.ti.com/sc/techlit/slaa263. Search for register breakpoints...

    Regards,
    Thomas Mitnacht 

  • I was having this problem with my code so I tried the original code from TI and it creates the same error. This makes be believe that there is another problem here. Why would the original TI code overflow the stack? Why am I getting this error message?

    P.S.  The link to the EMM documentation is http://focus.ti.com/lit/an/slaa263c/slaa263c.pdf

     

  • I forgot to mention in my previous post that I am using the eZ430 which has the CC430F6137 MCU.

    I have tried to examine the SP and the stack to see if it is being filled but have run into problems. The F6137 has 4K RAM (according to the data sheet) but in IAR Kickstart it shows only 2K RAM (1C00-2BFF). What is happening?

  • fe950 said:
    The F6137 has 4K RAM (according to the data sheet) but in IAR Kickstart it shows only 2K RAM (1C00-2BFF). What is happening?

    0x1c00-0x2bff is 0x1000, which is 4k.

  • You are correct. When using IAR WB View > Memory > RAM it showed only 1C00-23FF which is 2K. After talking with IAR Support we found that the .xcl and .ddf files were incorrect as they defined RAM from 1C00-23FF. Changed it to 1C00-2BFF and the RAM display is now correct.

  • fe950 said:
    After talking with IAR Support we found that the .xcl and .ddf files were incorrect as they defined RAM from 1C00-23FF.

    Yep. Such things can happen if a software supports a wider variety of similar devices. Then not everything is tested for every device adn copy&paste errors may occur.
    I wonder why you're the first encountering this. But then, somebody has to be the first :)

    Maybe nobody ever bothered looking at the upper 2k of ram before :)

  • I am using the CC430F6137 which has 4K of RAM but the upper and lower 2K can be powered down independantly. At first glance this seems to imply 2 banks but I think it is actually just 2 separate internal power enables. Maybe that is what caused the error.

    Why might I be the first? I was having problems that suggested a stack overflow so I started looking at SP and the actual stack locations in RAM which are at the top of RAM. Using View > Memory > RAM indicated that RAM was 1C00-23FF. That is how I found the problem. Also, if you use View > Memory > memory the entire memory (flash, RAM, SFR, etc) are shown in one huge block. Unless you try to view RAM only the error would not be seen.

    BTW, what caused me to look for stack problems was the message "The stack 'Stack' is filled to 100% (256 bytes used out of 256). The warning threshold is set to 90.%." It turns out that this may be an IAR issue. IAR Support suggested turning off Tools > Options > "Enable graphical stack display and stack usage tracking" which made this error message disappear.

    Whatever the case, problem(s) resolved.

  • fe950 said:
    At first glance this seems to imply 2 banks but I think it is actually just 2 separate internal power enables. Maybe that is what caused the error.

    Well possible. Older MSPs have only one RAM area. The newer ones may have them separated into different segments, but always contiguous. The 5xx series has 4*4k plus another 2k for the devices with USB.

    If you plan to just use one of the banks (for power saving), it would be necessary to tell the linker that only part of it is available (as if there were less RAM). It's a difficult task. It's possible (similar to the INFOA-INFOD flash area which is actually one large INFO segment), but due to the automatic usage of the RAM for initialized or uninitialized data as well as for the stack, it is not simple. Defining different linker scripts (different pseudo-devices) might be the most obvious way.

    Maybe it was an incomplete attempt to implement something like this, or it was just a simple copy/paste error form a similar device in this seris which has only 2k (Is there one?) and the one copying the definitions for the 'bigger brother' forgot to adjust the ram size.

    fe950 said:
    The stack 'Stack' is filled to 100%

    If the program was compiled/linked for 4k RAM and the debugger assumed 2K, then the stack pointer at debug time was outside ram and the (assummed) stack-reserved area (in fact ~2k off), causing an error (should read >100% not 100%, but well...)

    fe950 said:
    Whatever the case, problem(s) resolved.

    Fine. Rather a workaround than a fix (unless you patch the description files), but once you know why and how to ignore/circumvent it, can teh show go on :)

**Attention** This is a public forum