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.

  • Resolved

RTOS/CC2650: How can I debug the following BIOS Scan issue?

Part Number: CC2650

Tool/software: TI-RTOS

I'm getting the following error reported when running TI-RTOS -> BIOS -> Scan for errors...

Caught exception in view init code: "C:/ti/xdctools_3_32_00_06_core/packages/xdc/rov/StructureDecoder.xs", line 518: java.lang.Exception: Target memory read failed at address: 0x20003d28, length: 8
This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.

When I look at the map, this location is in the stack area.

Is this simply a stack overflow?

Do I need to allocate additional area in the stack?



  • You can look at the tasks to see whether one of them has blown it's stack. There also should be an exception recorded in the Hwi if you are accessing something you shouldn't that might have more details. The "module" tab on the Hwi shows the hwiStackPeak and hwiStackSize. for the Tasks, use the "detailed" tab to see the stackPeak and stackSize.

    In our case it was the Hwi stack that needed expanding once we hit problems like that.

    Panoptistar Research Pty Ltd (Smart Shepherd)

  • In reply to David Rubie:

    Thanks David,

    Do the task stacks build downward like the system stack(start at a high address and fill into lower addresses)?

    I'm using IAR.  IAR initiallizes stacks to 0xBE.

    So, assuming the stacks build downward, if I've blown one of the task stacks I will see non-0xBE data in the bottom (lowest addresses) of the that right?

    In 2 task stacks, I see the lowest 4 bytes filled with 0x00, then over 200 bytes of 0xBE in increasing address locations. This is the bottom of the stack, right?

    I don't know why the bottom of the stack would be zeroed out, but this might make it easy to see the bottom?

    I may be blowing one of the task or even the system stack, but 'm having difficulty viewing the failure in the debugger:

    When it fails, a window pops up with the following message:

    'XDS reported an error: Unknown CPU status'

    'Try again by resetting target?'

    (pressing CANCEL aborts debug session)

    'Yes, No or CANCEL'

    CANCEL does me no good. It just throws me out of the debug session.

    No comes back almost immediately with the same error box.

    Yes looks good initially, but then, after some time it says 'Warning: Can not set SW breakpoints and no more HW breakpoints available'

    I click OK and it gets stuck in a loop reporting the same breakpoint message.

    I try clearing all breakpoints (of which I only have 3 set) and it comes back with the same breakpoint message.

    Do I need to look at the task stacks and the Hwi Module tab after finding a good place to breakpoint, just prior to the debugger losing it's mind?


    Thanks for your help.



  • In reply to John Wright:

    The debugger is likely losing it's mind because the device has halted. I just use the RTOV to look at the stacks rather than trying to dig through the memory, I honestly have no idea which direction they grow. If you can find RTOV in your IAR setup, everytime you hit a breakpoint or pause in the debugger it will populate the various tabs with information on the tasks and any errors the system has encountered.

    Panoptistar Research Pty Ltd (Smart Shepherd)

  • In reply to David Rubie:

    Thanks again, David,

    Like you said, you can see hwiStackPeak and hwiStackSize in the RTOV, in the TI-RTOS -> Hwi -> Module tab.

    And the stacks all build downward from the top.

    I said earlier that IAR initializes stacks to 0xBE. That's wrong. It's the initialization code that fills the stacks with 0xBE.

    What I've concluded is there are conflicts between the RTOV hwiStackPeak reporting and the stack window graphical display. The tools fight with each other. The root cause of this conflict is the fact that the stack initialization value used by each tool is different. The RTOV tool uses a value of 0xBE, whereas the stack window graphical display uses a value of 0xcd.
    This difference in initialization value makes it impossible to use both tools at the same time.
    You can use either one of the tools, but you can't use both.
    The TI examples currently leave the stack initialized with 0xBE (after running to main), which allows the RTOV to operation correctly. If you continue to use RTOV, it will work.

    And, you can view the stacks in the stack window by clicking View -> Stack. Whenever the debugger is halted the stack window shows only the valid data contained in the stack. It also shows you what the data is (for example, it could be part of the stack frame, or local variables, etc.)
    The entire data table in the stack window is valid any time the debugger is halted.
    However, the graphical display on the top-right of the stack window will not work correctly unless the stack is initialized with the pattern 0xcd. All the information that is presented in this display bar is valid, including indication of a stack overflow (by turning red), works when it is setup correctly.
    Note - by changing the stack initialization value from 0xbe to 0xcd you enable the stack display bar to work, but you also cause the RTOV hwiStackPeak information to be invalid.

    To change from using RTOV hwiStackPeak to using the stack window graphical display do the following:
    - In Project -> Options -> Debugger -> Setup tab, check the box 'Run to' and specify main
    - Start the C-Spy debugger. It will halt just short of calling the main function...the stack will be empty.
    - Now initialize the entire stack with the value 0xcd.
    - Continue debugging; the graphical display will be valid until you hit the debugger reset again.
    - If you want to continue using the stack graphical display window after reset you will need to fill the stack with the value 0xcd again.

  • In reply to David Rubie:

    Thanks again, David,

    The stacks all build downward from the top.

    Your wise in using RTOV hwi module to view stack peak.

    In View -> Stack window you can see:
    the current depth of the stack,
    currently valid data in the stack,
    and whether the stack has overflowed.
    Although you need to initialize the stack with 0xcd after running to main to enable some of this functionality to work correctly.
    And doing this kills the ability of the RTOV to provide the stack peak value (since RTOV uses the initial value 0xbe to work)
    However, stack peak is not provided in the View -> Stack window.

  • In reply to John Wright:

    Correction, the stack peak is provided in the View -> Stack window in graphical form only.
    The peak is shown as the transition from dark grey to light grey.
    As long as the right-most portion of the display is not red, the stack has not overflowed.
    As I indicated above, when the View - stack graphical display is setup correctly, the RTOV hwiStackPeak is invalid.


  • In reply to John Wright:

    OK, I've located the line of code in C where the debugger blows up.
    It's in the sensor controller framework.c file, line 741; this line reads as follows:
    // Set the REQ event to hand over the request to the Sensor Controller

    Just prior to executing this instruction I see the following results in ROV
    BIOS -> Scan for errors: 'All ROV views have run, no errors encountered. Includes check of System stack usage and Task stacks.

    As soon as I execute this line of C code the debugger comes back with:
    'XDS reported an error: Inknown CPU status'
    'Try again by resetting target?'
    '(Pressing CANCEL aborts debug session)'

    I know the sensor controller code executed, because I have a scope on signals that get toggled by the sensor controller code.

  • In reply to John Wright:

    If, instead of running the debugger, I hit the board reset, the M3 code and sensor controller run over and over without error.
    That is, I see the sensor controller execute again and again and again.
    For some reason the debugger cannot continue after the sensor controller executes, but the code seems to be executing correctly.

  • In reply to John Wright:

    I've found a couple solutions to the issue of the debugger crashing:

    1) Inserting certain breakpoints and running to these locations will cause the debugger to crash.

    Removing these breakpoints prevents the debugger from crashing. This makes it tricky to debug, however, it's not impossible.

    2) Compiling with 'None' optimizations prevents the debugger from crashing.


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.