• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1988 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/TMS320C6746: Task stack overflow when I plug in the Ethernet cable

Jiawei Zhu
Intellectual 600 points
Part Number: TMS320C6746

Tool/software: TI-RTOS

I am developing my project. Recently I added a feature to the project, but I found program always crash with stack overflow when I plugged in the Ethernet cable. I have checked the stack usage in the ROV and found no overflow exist.

here is a screenshot when the program crashed:

Could you give me any idea to figure out the problem? Thank u.

PS:

Here is my memory map file located in Debug/*.map

******************************************************************************
               TMS320C6x Linker PC v8.2.2                      
******************************************************************************
>> Linked Tue May  8 15:21:25 2018

OUTPUT FILE NAME:   <ess2.out>
ENTRY POINT SYMBOL: "_c_int00"  address: c0067a40


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  IROM                  11700000   00100000  00000000  00100000  R  X
  IRAM                  11800000   00040000  00000000  00040000  RW X
  L3_CBA_RAM            80000000   00020000  00000000  00020000  RW X
  DDR                   c0000000   08000000  001ac46c  07e53b94  RWIX


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
c0000000    c0000000    000732c0   000732c0    r-x
  c0000000    c0000000    000732c0   000732c0    r-x .text
c00732c0    c00732c0    00000040   00000000    rw-
  c00732c0    c00732c0    00000040   00000000    rw- .far.1
c0073300    c0073300    0011c368   00000000    rw-
  c0073300    c0073300    00052b00   00000000    rw- .far:NDK_PACKETMEM
  c00c5e00    c00c5e00    00040000   00000000    rw- systemHeap
  c0105e00    c0105e00    000385b4   00000000    rw- .far.2
  c013e3b8    c013e3b8    000312b0   00000000    rw- MyHeap
  c016f668    c016f668    00020000   00000000    rw- NandBlockCacheHeap
c018f668    c018f668    00008990   00008990    r--
  c018f668    c018f668    00008990   00008990    r-- .const
c0197ff8    c0197ff8    000127c8   00000000    rw-
  c0197ff8    c0197ff8    00005944   00000000    rw- .fardata
  c019d940    c019d940    00005000   00000000    rw- .far:taskStackSection
  c01a2940    c01a2940    00004000   00000000    rw- .stack
  c01a6940    c01a6940    00003e80   00000000    rw- TcpHeap
c01aa7c0    c01aa7c0    00000550   00000550    r--
  c01aa7c0    c01aa7c0    00000550   00000550    r-- .switch
c01aad10    c01aad10    00000284   00000000    rw-
  c01aad10    c01aad10    0000008d   00000000    rw- .bss
  c01aada0    c01aada0    000001f4   00000000    rw- .neardata
c01aaf94    c01aaf94    0000005c   00000000    r--
  c01aaf94    c01aaf94    0000005c   00000000    r-- .rodata
c01ab000    c01ab000    00000200   00000200    r-x
  c01ab000    c01ab000    00000200   00000200    r-x .vecs
c01ab200    c01ab200    000002b8   00000000    rw-
  c01ab200    c01ab200    00000194   00000000    rw- emacComm
  c01ab398    c01ab398    00000120   00000000    rw- .cio
c01ab4b8    c01ab4b8    00000fd0   00000fd0    r--
  c01ab4b8    c01ab4b8    00000fd0   00000fd0    r-- .cinit
...

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the RTOS team. They will post their feedback directly here.

    Please share which processor SDK are you using?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 600 points
    Sorry for not mention that. I am using Processor-SDK-RTOS-OMAPL138 4_00_00_04 and CCS7.3
  • 0
    TI__Mastermind 27355 points

    Hi Jiawei,

    You can try increasing the stack size to narrow down whether it's really a stack overflow problem and not some memory corruption problem. Also, after the crash, you can open ROV and view the stackPeak usage and stackSize for each task.

    If it is a memory corruption issue, you will need to determine where your application enters the bad state. You can accomplish this by setting breakpoints within your code or by using the C6748's Advanced Event Triggering to set a watchpoint on the end of the stack. Refer to the article Checking for Stack Overflow for details on how do this.

  • 0 in reply to Sahin Okur
    Intellectual 600 points

    Thank you for your reply, Sahin Okur. I have followed your instructions. first I use ROV view checked the stackPeak and stackSize. All tasks's peak values are much lower than stack size. You can see the picture below:

    And I found the overflowed task didn't match any task in the ROV View and I am sure all tasks I created were here.

    Then I added a watch point at symbol __stack, but it didn't trigger after main() as expect. The problem still puzzled me much. Hoping for your reply, thank u.

  • 0 in reply to Jiawei Zhu
    TI__Mastermind 27355 points
    Hi Jiawei,

    After the crash occurs, open your memory browser and look at the base address (stackBase in ROV) of each task. You should see a bunch of 0xBEBEBEBE at the addresses near the base of the stack, which indicates unused stack (the highest address of the stack is used first and grows downward, contiguously from there). If you see anything other than 0xBEBEBEBE at the base then this indicates all the stack was used and overflowed. If there are gaps of unused stack, then this might indicate a memory corruption.

    You mentioned that you recently added a feature to your project. Is that when the stack overflow began to occur? If so, what did you add exactly? Sometimes we see stack overflow when a semaphore, heap, or something else is configured incorrectly.

    Also just to note, if you create your tasks using Task_construct, as opposed to Task_create, they won't show up in ROV. But it sounds like you have all of your tasks accounted for so you should be OK here.
  • 0 in reply to Sahin Okur
    Intellectual 600 points

    Thank you, Sahin Okur. 

    I have checked every task's stackBase. I can see every stackBase is filled with BEBE and no gaps of unused stack. And the crash happened at the very beginning of the execution. 

    I am also trying to figure out which line of code caused the stack overflow. I remove the feature line by line, and find the line. But I still could not figure out why. The program never run to this line before its crash.

    All the tasks I create dynamically are using TaskCreate() function in NDK package. It seems all tasks can be seen in ROV View. 

    Hoping for your help, thank u.

  • 0 in reply to Jiawei Zhu
    TI__Mastermind 27355 points
    Jiawei,

    Are you saying the stack overflow occurs immediately at the start of your program? Are you able to set breakpoints and single step through the code?

    If you comment out the NotifyAll() call, the problem is resolved? Can you share what is inside this function?

    Another thing is tasks that created dynamically are allocated from the heap so try increasing the size of your heap to see if that helps.
  • 0 in reply to Sahin Okur
    Intellectual 600 points

    We have done a lot of experiment. Increasing the heap size isn't useful.
    Recently we found when we change SysMin.bufSize to 128, the stack overflow disappeared. The origin bufSize is 0x10000. Why the stack overflow disappeared when we decreased the bufSize?

  • 0 in reply to Jiawei Zhu
    TI__Mastermind 27355 points
    Hi Jiawei,

    Sorry this was missed. I'm glad to hear you were able to resolve your issue.

    The Sysmin.bufSize parameter determines the size of the circular buffer used for system_printfs so my guess is that the larger buffer size required much more stack than what was being allocated.