Part Number: CC2650
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: 8This 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?
Panoptistar Research Pty Ltd (Smart Shepherd)
In reply to David Rubie:
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 stack...is 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:
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.