Hi all I'm running a massive test harness on DSK6416, I'll send the input data from Matlab via RTDX to the target and I get back the data for analyzing in Matlab via RTDX. After a while , matlab reported a failure in input channel , at the same time the CCS has crashed and error in CCS is as following "stack overflow" Comments or suggestions would be very much appreciated. thanks , hamid
Urgent:RTDX issue
Started by ●April 16, 2004
Reply by ●April 16, 20042004-04-16
On 16 Apr 2004 05:50:58 -0700, Hamid <hsepehr@yahoo.com> wrote:> Hi all > > I'm running a massive test harness on DSK6416, I'll send the input > data from Matlab via RTDX to the target and I get back the data for > analyzing in Matlab via RTDX. > > After a while , matlab reported a failure in input channel , at the > same time the CCS has crashed and error in CCS is as following > "stack overflow" > > Comments or suggestions would be very much appreciated. > > thanks , hamidHow big is your stack? How deep do your calls go? Brute force would be to allocate an enormous stack and hope for the best. Better would be to trap when the stack gets above a certain size and take a look at your calls at that point. Are you doing something with a lot of recursion and exponential memory usage?
Reply by ●April 16, 20042004-04-16
U-CDK_CHARLES\Charles wrote:> On 16 Apr 2004 05:50:58 -0700, Hamid <hsepehr@yahoo.com> wrote: > >>Hi all >> >>I'm running a massive test harness on DSK6416, I'll send the input >>data from Matlab via RTDX to the target and I get back the data for >>analyzing in Matlab via RTDX. >> >>After a while , matlab reported a failure in input channel , at the >>same time the CCS has crashed and error in CCS is as following >>"stack overflow" >> >>Comments or suggestions would be very much appreciated. >> >>thanks , hamid > > > How big is your stack? How deep do your calls go? Brute force would be > to allocate an enormous stack and hope for the best. Better would be to > trap when the stack gets above a certain size and take a look at your > calls at that point. > > Are you doing something with a lot of recursion and exponential memory > usage?Is there a rarely used routine that doesn't pop all it pushes, or a routine than can be made to "forget" to pop by an unfortunately timed interrupt? To figure your stack need, you need to add the deepest interrupt nesting to the deepest main nesting. C, with it's stack frames, can be stack hungry. Even when parameters are passed in registers, the old register values need to be saved, and stack depth can add up fast. An advantage of assembler is that stack use is in the open. Not only is seen, but it can be managed. It is hidden with C and other HLLs, making it easy to ignore and hard to manage. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●April 16, 20042004-04-16
Jerry Avins wrote:> U-CDK_CHARLES\Charles wrote: > >> On 16 Apr 2004 05:50:58 -0700, Hamid <hsepehr@yahoo.com> wrote: >> >>> Hi all >>> >>> I'm running a massive test harness on DSK6416, I'll send the input >>> data from Matlab via RTDX to the target and I get back the data for >>> analyzing in Matlab via RTDX. >>> >>> After a while , matlab reported a failure in input channel , at the >>> same time the CCS has crashed and error in CCS is as following >>> "stack overflow" >>> >>> Comments or suggestions would be very much appreciated. >>> thanks , hamid >> >> >> >> How big is your stack? How deep do your calls go? Brute force would be >> to allocate an enormous stack and hope for the best. Better would be to >> trap when the stack gets above a certain size and take a look at your >> calls at that point. >> >> Are you doing something with a lot of recursion and exponential memory >> usage? > > > Is there a rarely used routine that doesn't pop all it pushes, or a > routine than can be made to "forget" to pop by an unfortunately timed > interrupt? To figure your stack need, you need to add the deepest > interrupt nesting to the deepest main nesting. > > C, with it's stack frames, can be stack hungry. Even when parameters are > passed in registers, the old register values need to be saved, and stack > depth can add up fast. An advantage of assembler is that stack use is in > the open. Not only is seen, but it can be managed. It is hidden with C > and other HLLs, making it easy to ignore and hard to manage. > > JerryIt is good practice with embedded C code to fill your proposed stack space with some pattern (0xDEAD, or 0xF00D, etc., or "stack" repeated). Then you can go back and look at your stack later to see how much was consumed. It's not 100% deterministic, but it works very well. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
