• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 909 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/LAUNCHXL-CC2640R2: ROV view stackPeak and internal error

Bjoern Gutgesell
Prodigy 230 points
Part Number: LAUNCHXL-CC2640R2


Tool/software: Code Composer Studio

Hi forum,

about runtime object view I have two questions:

1) In ROV my stackPeak is sometimes higher than the displayed value and return fast to a lower value that dont change for a long time (1-5min). I thought the stackPeak represents the maximum stack in use since runtime, that was my assumption, but it is wrong. Is there a possibility to get this value, also the highest value? Or do you make try and error too and get the optimum stack size empirical?

2) In my application there are 4 task. Once in 5..10min there happened rov->task->detaied->blockedOn a red flag "blockedOn Internal Error" message. What does it mean?

Hint to 2): at the other time it show the normal "blockedOn Semaphore: 0x20002288" in white / or yellow (changestate). And the application has normal function, works well,  dont hangup.

best regards,

Bjoern

  • 0
    TI__Guru* 96960 points

    Hi Bjoern,

    1. To determine stack peak, a stack is initialized with 0xbebebebe values. Then ROV starts at the top of the stack (low address for your device) and starts searching for the first non-0xbebebebe value. Once it finds it, that is the peak. For example, let's assume this is the stack

    0x1000: 0xbebebebe

    0x1004: 0xbebebebe

    0x1008: 0xbebebebe

    0x100C: 0x20043234

    0x1010: 0xWWWWWWWW // any value

    0x1014: 0xXXXXXXXX // any value

    0x1018: 0xYYYYYYYY // any value

    0x101C: 0xZZZZZZZZ // any value

    ROV starts looking at 0x1000. Since it has 0xbebebebe (for your device, it looks at a character at a time instead of the 32-bits), it looks at the next address and so on. At address 0x100C, the compare fails, so the stack peak is 20 bytes.

    So unless you have something on the stack that is being set to 0xbe, the peak in ROV should never go down over time. Note: I'm assuming you are not deleting the task (or letting it exit) and recreating it. In that case, it's basically a new task with a fresh stack.

    2. Are you updating ROV while the target is running. Occasionally this can result in garbage in ROV. ROV is simplying reading memory on the target and then intelligently displaying the data. If the target is running (or was halted in a critical loaction), the data could be in a non-valid state from ROV's standpoint. For example if HeapMem's freelist was examined right when a next pointer was updated but not the prev, this might result in a ROV issue. The target code is fine. So if you are seeing this every few minutes while the target is running and there appears to be nothing wrong with the application (e.g. UART is still working, stack is still working, etc.), I would not be concerned.

    Todd