• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 2171 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.

CCS/RM48L952: Getting stuck in dabort.asm with integer arrays

Bailey Jones
Prodigy 160 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

Hi,

I have a program with 5 integer arrays, each of length 64.  This runs fine.  If I increase the size of these to 128 or 256, when I run in DEBUG the code gets hung up in dabort.asm - which I assume is some sort of stack overflow routine.  I was advised to go into properties -> ARM LINKER -> BASIC OPTIONS and increase the size of the stacks, but that doesn't have any effect.  The same code has run on another ARMCortex processor (Actel) so I'm guessing there's something I need to do in the CCS compiler to enable more memory, or to map the arrays to RAM rather than local registers?  Is there a header file I need to enable RAM?

I'm using the latest CCS and HalCoGen.

A little help?

Thanks for your time.

  • 0
    Prodigy 160 points
    Should I be using sys_core.h? I'm just going through the HalCoGen help files looking for answers.
  • 0 in reply to Bailey Jones
    TI__Guru 59540 points

    Hello Bailey,

    What is most likely happening is you are overrunning your stack area because these arrays are defined as static or global so they are placed on the stack. To resolve this, you can increase your stack size in the linker command file (sys_lnk.cmd). You will need to adjust the size of the .stack section at the top of the file. Be sure to reduce the RAM size accordingly. Below are the lines in the linker command file you will want to change.

    You will also want to make updates to sys_core.asm to update the initialized pointer for the user stack pointer (userSP). Excerpt below:

    There should then be sufficient room for you arrays to be pushed to the stack without overflowing it.

  • 0 in reply to Chuck Davenport
    Prodigy 160 points
    Thanks for your prompt reply. Is there a way to declare arrays so that they are automatically allocated to RAM? For instance with a malloc or calloc?
  • 0 in reply to Chuck Davenport
    Prodigy 160 points

    Sorry, but I'm having a little trouble understanding this.  I get the part about changing the relative sizes of the RAM and STACKS space, but not the pointers.  Is userSp pointing to the top of the user stack?  And won't I also need to bump up the pointers to the other 5 stacks as well?

    Thanks

  • 0 in reply to Bailey Jones
    TI__Guru 59540 points
    Bailey,

    Yes, this is the code to initialize the pointers to the top of the stack spaces and, yes, you would also need to adjust the other stack pointers relative to the location of the newly adjusted user stack pointer.
  • 0 in reply to Bailey Jones
    TI__Guru 59540 points
    Bailey,

    It might also be worthwhile to have a look at the map file in your original implementation to see where these arrays are being placed and this would confirm if we are on the right track with the approach of increasing the stack space. You may also want to declare these arrays as static if they are used in context of multiple functions and not just in scope for one function. Also, just to be sure, are you passing these arrays as parameters between functions? If so are you passing them directly or by reference only? Passing directly could also cause them to be an excessive burden on the Stack.