Hi,Could you please let me know what ti_sysbios_hal_Hwi_checkStack() is?It's in the idle loop.Is the function required to excute in every idle loop, or is it OK to be excuted just one time in the first idle loop?Thank you very much in advance.Best regards,j-breeze
This is a utility function that checks the top of the system stack to see if a ‘watermark’ value has changed from its initial value. If the value has changed, then a stack overflow has probably occurred, and a “stack overflow” error is raised.
So… this function does not *have* to be called regularly for application purposes, but if it isn’t called regularly, then a stack overflow won’t be automatically caught.
This function is inserted in the Idle loop if the following Hwi configuration parameters are both set to true:
Hwi.initStackFlag - indicating that the system stack should be initialized with the watermark
Hwi.checkStackFlag - indicating that background checks for stack overflow should be executed in the Idle loop
If you set “Hwi.checkStackFlag = false;” in your application configuration then the background checking won’t be done automatically, and the function won’t be called from the Idle loop.
If you leave “Hwi.initStackFlag = true;” then the stack watermarking will still be done, so that you can still see depth of stack usage in ROV.
Scott-san,Thank you for your kindly support. I got it.Best regards,j-breeze------------P.S.David-san,Could you please let me know why you verified this answer?I do'nt know well this procedure. I think that I can verify this answer. Right?Thanks in advance.Regards,
From your explanation , I understood the functionality of the function ti_sysbios_hal_Hwi_checkStack().
Even my program is having the same problem of getting stopped at if (*stackTop != (UInt8)0xbe) of the function ti_sysbios_hal_Hwi_checkStack().
1)I am running the IPC messageQ example program for single core in generic 66xx simulator in CCS v5.
2) After first three message were exchanged between client and server, this stack overflow happened.
3) I did not have a c6618 cmd file for linker, so I let the linker take the default memory map file.Only increased the stack size to 0x2000 in an independent cmd file.
Please let me know what to look for in the code to solve this problem.
I think it would be good to post this question on a new forum thread, with something about ‘stack overflow’ or ‘IPC messageQ example’ in the title. That should get more attention from others who can help.
I’ve not looked at that example, but since you are running on a simulator I’m wondering if maybe whatever is triggering the messages is too fast compared to running it on actual hardware. Is there an interrupt that may be configured too fast in the simulator?
Also, since the overflow is repeatable, can you use a breakpoint to check the stacks with ROV (http://rtsc.eclipse.org/docs-tip/RTSC_Object_Viewer) after each message? You’ll probably see the stack growing, and can debug to see why.
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.