3

I have a thread, which does a function call,

 Thread 1()
 {
 while(1)
 {
 msg =  msgreceive();
condn= msg->condn;
 switch(condn)
 {
 case 0:
 //do sonmething
 break;
 case 1:
  printf("case_1");
  function2()
 break;
  }
}
}

function 2()
{
printf("fn2_Start");
//Do something
function 3();
printf("fn2_end");
}

fucntion3()
{
printf("fn3_Start");
//Do something
printf("fn3_end");
}

Normally i get the printf traces this way,

case_1
fn2_Start 
fn3_Start
fn3_end
fn2_end
case_1
fn2_Start 
fn3_Start
fn3_end
fn2_end
....
....
...

But some times in long run, i get the traces this way

case_1
fn2_tart
fn2_start
fn2 start
case 1
case 1

This is with embedded RTOS device environment.(MQX) Language - C Is there anyway we can suspect why the sytem can behave this way.This happens when the system is heavily loaded running with about ~93% of memory usage.

artless noise
  • 21,212
  • 6
  • 68
  • 105
buddy
  • 805
  • 1
  • 15
  • 30
  • Do you have a software/hardware watchdog timer active? – macduff Feb 20 '12 at 14:24
  • yes,hardware watchdog is active. – buddy Feb 20 '12 at 14:26
  • Will your application reset if the watchdog is triggered, I'm guessing yes, but just to make sure. You're sure the OS does not have software watchdogs active? – macduff Feb 20 '12 at 14:28
  • 1
    How does your main() function look like? Maybe you are scheduling your Thread in a specific way? Maybe the watchdog timer restarts your thread because it has not relinquished the CPU in the agreed time? – parasietje Feb 20 '12 at 14:29
  • yes application will reset if watchdog is not serviced at regular intervals. – buddy Feb 20 '12 at 14:38
  • Threads are scheduled in FIFO, but we dont see that the watchdog is resetting the application – buddy Feb 20 '12 at 14:40
  • And even if the watchdog resets it would reset the application as whole and reboots the device, but it won't affect the scheduling of the thread. – buddy Feb 20 '12 at 18:05
  • 93% memory usage is not likley to be an issue, did you mean 93% CPU usage? – Clifford Feb 25 '12 at 12:17
  • 93% of memory usage, we have 1 MB of static RAM and hence its usage reaches 93%. – buddy Feb 25 '12 at 16:36

1 Answers1

2

If the stdout stream is buffered at the device driver level and outout handled by an interrupt, then when the buffer is full, and if it is designed to simply discard characters rather than perform blocking I/O, then this will result in loss of characters in the output.

If that is the case, then the actual execution is following the normal sequence (and Occam's Rasor rather suggests that would be the case), but some of the trace output is simply being lost. This hypothesis is supported perhaps by the malformed fn2_tart output.

Using "printf" as a trace method is not non-intrusive. It can both affect and be affected by the way your code runs. Increasing the buffer size may help if the high CPU load periods are relatively short, but if they are permanantly sustained, no ammount of buffering will solve the problem.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Yes correct...the suspect is the same we arrived at. it was not the stdout stream, in our case , that here print writes to, it is written to the telnet trace, or to the hyperterminal connection, that involved a buffer and the buffer was overwritten at loaded condition. – buddy Feb 25 '12 at 16:35
  • @Jebina: That is what I meant by "buffered at the device driver level", I mentioned stdout only because that is the "source" of teh data because you were using printf(). Yes overwriting a circular buffer would have similar consequences. Most implementations "block" when the buffer is full (on a semaphore, or a message queue or pipe if the buffer is implemented that way), but that affects the real-time performance of the calling task; discarding or overwriting data is a way around that. – Clifford Feb 25 '12 at 17:22
  • yea, setting the buffer size would be the crucial one, for us where no debug tools is not available currently with our device on MQX, relying only on this telnet trace to get the source of error,with 1 MB RAM, this is pretty annoying. – buddy Feb 25 '12 at 18:53