• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 476 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.

[OMAPL137] stack size

Flamingo
Expert 2290 points


Here is an excerpt from my memory map. (See arrows for points of interest.)

c26c76c8   TSK_collect$stack  <-------------------------
c26c7a60   TSK_collect$stkptr <-------------------------
c26c7ac8   TSK_idle$stack
c26c7e60   TSK_idle$stkptr
c26c7ec8   __CIOBUF_
c26c7fe8   TRC_cinit
c26c7fec   TRC_R_mask
c26c7fec   _TRC_R_mask
c26c7ff0   GBL_initdone
c26c7ff4   IDL_A_TABBEG
c26c7ff4   Load_cpuloadIdlObj
c26c7ff4   _Load_cpuloadIdlObj
c26c7ff8   IDL_END
c26c8000   ti_sdo_ce_bioslog_track$buf
c26cc000   TSK_process_data$stack <-------------------------
c26cc398   TSK_process_data$stkptr <-------------------------
c26cc400   ti_sdo_ce_osal_LOG_Buffer$buf

My server.tcf file says

prog.module("TSK").STACKSEG = bios.DDR2;
prog.module("TSK").STACKSIZE = 0x10000;

The .h62 file says

TSK_STACKSIZE       .set 010000H

codec.cfg says

Server.algs = [
    {name: "vqm_results", mod: VQM_RESULTS , threadAttrs: {
        stackSize: 0x10000, stackMemId: 0, priority: Server.MINPRI + 4},
        groupId : 4,
    },

I've tried to make all the input files to the build agree about stack size. The .s62 file that is auto-generated says

;; ======== TSK_config ========
    .asg 010000H, _STACKSIZE
    .asg DDR2, _STACKSEG
    .asg 01H, _PRIORITY
    .asg _LogTracker_createHook, _VCREATEFXN
    .asg _FXN_F_nop, _VDELETEFXN
    .asg _FXN_F_nop, _VEXITFXN
    .asg 00H, _SWITCHFXN
    .asg 00H, _READYFXN
    .asg 00H, _NUM_HOOKS
    TSK_config  _STACKSIZE, _STACKSEG, _PRIORITY, _VCREATEFXN, _VDELETEFXN, _VEXITFXN, _SWITCHFXN, _READYFXN, _NUM_HOOKS

If I'm reading the map correctly, the stack sizes seem to be 0x398. These are the stacks for my background tasks, and although they are large enough, in one case it is mighty close to too small. I'm wondering if some of the erratic behavior I see when I add trace statements might be associated with this. Can someone tell me what I need to change to make the stacks be larger in the memory map? Or am I misinterpreting the map?

 

  • 0
    TI__Guru*** 125430 points

    Looks like your stacks for TSK_process_data and TSK_collect are both set to 0x400 hex.

    You're looking at the wrong part of the map file.  Here's an example.  I created a task called "GPIO" which has a stack in addition to the TSK_idle.  Here's the snippet of interest from the map file:

    .GPIO$stk
    *          0    10806878    00000400     UNINITIALIZED
                      10806878    00000400     6424_GPIOcfg.obj (.GPIO$stk)

    .TSK_idle$stk
    *          0    10806c78    00000400     UNINITIALIZED
                      10806c78    00000400     6424_GPIOcfg.obj (.TSK_idle$stk)

    Doing a delta of the 2 labels you show is not the correct thing to do.  In your case, TSK_collect$stack indicates the smallest address in the stack (which corresponds to the last address to be written since stack grows from high address to low address at run time).  The TSK_collect$stkptr corresponds to the INITIAL address for the stack pointer, i.e. 0x68 hex is being allocated right off the start.  It's the same in your case too, i.e. 0x68 bytes are always allocated for new tasks on 64x+ (0x398 + 0x68 = 0x400).

    I normally use the graphical tool to make changes to my tcf files, but the corresponding code when I modify the stack size for a given task looks like this:

    bios.TSK.instance("GPIO").stackSize = 1024;

    You mentioned the following code from your tcf:

    prog.module("TSK").STACKSEG = bios.DDR2;
    prog.module("TSK").STACKSIZE = 0x10000;

    Note that this code would only affect new tasks instantiated AFTER that part of the tcf.  For example, if you created a new task immediately before and immediately after the above code, you would end up with a stack size of 0x400 (BIOS default) for the first one and a stack size of 0x10000 for the second one.

    Brad