• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 584 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.

ez430 rf2560

Mark Joseph
Prodigy 180 points


Hello,

I recently changed the size of the data buffer "appl_spp_data_buffer[4]" in appl_sdk.c to [6] to accommodate to spp transfer of all three axis of accelerometer data. I then added the appropriate variables and added to the buffer[] commands to pack the data and shift it out to the bt device to send. Now to the issue at hand. It's possible that I don't have enough memory to support this change but I am not sure. The warning I get everytime I step through the subroutine to get the accelerometer data is as follows:

"Tue Feb 28, 2012 11:08:27: The stack pointer for stack 'Stack' (currently Memory:0x20FC) is outside the stack range (Memory:0x5B4C to Memory:0x5C00) "

I have only a basic understanding of the stack, and would like to know if my above theory of not having enough memory is correct. Regardless of whether I am on the right track or not as to what the warning message means, I am lost when it comes to cleaning it up. Any help would be greatly appreciated.

~MJ


  • 0
    Guru 92251 points

    The Code Generation Tools XML Processing Scripts can report the maximum stack usage for a program.

    This can be checked against the C system stack size allocated in the CCS5 project properties -> Build -> MSP430 Linker -> Basic Options. Not familiar with how to set the stack size in IAR, but guess there is an equivalent option.

  • 0
    Prodigy 30 points

    I got the same error, but I haven't got a clue on how to resolve the problem.

    So I'm also waiting for an answere too...

  • 0 in reply to S Geerts
    Prodigy 180 points

    As for the warning, its due to the overflow of the stack. I'm in the process of reading up more thoroughly on RTOS, but from what I can tell the stack size allocated when the user task is created is too small (fairly obvious from the overflow). As for fixing the problem, I am weary of simply increasing the stack allocation size that the task creates. I am unfamiliar with the memory mapping used by the program and not sure if increasing the stack will cause other issues like overwriting mpu instructions or data loss.

    s geerts - if you are using IAR you can go to Tools -> options -> stack and click the box to display the stack usage and a warning at a given percent usage. This was how I confirmed that my stack was overflowing.

    As for an answer to how to best deal with the issue, if anyone has more experience with RTOS and can point me in the right direction I would appreciate it.

    ~Mj

  • 0 in reply to Mark Joseph
    Guru 227245 points

    Teh debuger warning is based on three things:

    first, the 'stack setting' in your project settigns (which isn't actually 'setting' the stack - it is only a threshold value for linker and debugger)
    second, the end of ram position and
    third, the current stack pointer.

    If the debugger stops the CPU and reads the stack pointer, it compares it to teh address that is "Stack setting' bytes below teh top of ram. If the stack pointer is below that, you'll get the stack overflow warning.

    However, RTOS will allocate a separate stack for each thread. This stack is allocated form the unused ram above your gobal/static variables (the heap, the same one as used by malloc). And therefore definitely below this threshold address. The debugger cannot possibly knwo htat someone, the RTOS, is messing intentionally with the stack pointer to provie different stacks for different threads. So when using an RTOS, the stack warning usually (but not necessarily) is a bogus one.
    Like a speed limit warning that triggers an alarm on 30MPH, no matter wether you're inside a city or on a freeway.

  • 0 in reply to Jens-Michael Gross
    Intellectual 425 points

    This stack pointer warning is not related to the any IAR stack/ MCU Stack size issue. This warning will show up since IAR is not aware
    of FreeRTOS and will come after the scheduler is called. If you run a simple non-OS based program, the IDE will be able to track the stack pointer and will
    not give this warning. In the current application, the stack is maintained by FreeRTOS. If IAR supports a third party or custom FreeRTOS aware plugin, then that might
    help to remove this issue and provide task level awareness while debugging.

     

     

    Regards,

     

  • 0 in reply to srisenthilkumar chandrasekaran
    Prodigy 180 points

    Thanks to all for the invaluable help. 

**Attention** This is a public forum