MicroC/OS-II hangs after printf in main

[Altera_Forum]

I have a simple system made with Q4.2sp1, Nios II v1.1 running MicroC/ OS-II. 

Running entirely on-chip from rom code and on-chip ram. Uart is rs232 servicing all three stdio's. Periodic timer 1ms, Sysclk=80MHz, Tick at Clean exit (Flush buffers). rest no tick or default. Compile: Debug, No optimization, Highest debug level. Nios core: Fast, debug level 2. The code which shows the blocking of the system can be coocked down to this trivial thing: #include <stdio.h> int main() {  int i=0;  while(1)    printf("%1d",i++ % 10);  //.. this hangs after 91 to 93 characters  return 0; } The number of bytes is 91 to 93 before it hangs and prints no more. Its not a trivial stack overflow because if I double the ram (128kB), there is no change in number of printed characters.  Printf from tasks works perfect all the time.  Any ideas why its behaving like this?

[Altera_Forum]

Thanks for doing a lot of the work tracking down a minimum case where it stops working. Does this same code work in a HAL only project? 

 Does it work if you step over the printf lots of times rather than letting it run? Where it the processor stuck if you press pause in the debugger?  I wonder whether this is something to do with event flags. When the UART driver's buffer fills up it waits on an event (ALT_FLAG_PEND in altera_avalon_uart.c).  In the HAL only case this turns into a busy loop.  In the uCOS-II case this uses the event flag mechanism built into the OS. But you haven't started the OS yet (by calling OSStart) so the event flags may not work correctly (I haven't looked at the code yet).

[Altera_Forum]

Removed double post

[Altera_Forum]

Thank you for commenting on this. Its very appreciated. 

<div class='quotetop'>QUOTE </div>  --- Quote Start ---  Thanks for doing a lot of the work tracking down a minimum case where it stops working. Does this same code work in a HAL only project?[/b]  --- Quote End ---  Yes, no problems in HAL mode. <div class='quotetop'>QUOTE </div>  --- Quote Start ---  Does it work if you step over the printf lots of times rather than letting it run?[/b]  --- Quote End ---  Yes then it works, but for debugger not to get absorbed in the printf statement, i had to modify the code slightly to be covered by two lines #include <stdio.h> int main() {  int i=0;  while(1) {    printf("%1d",i % 10);    i++;}      //.. this hangs after 91 to 93 characters if free running    // if debugged line by line, it works for as long as I had patience (>150)    return 0; }  It still fails in debug single state-mode if I print a long line with more than 93 chars in one printf statement like    printf("Looooooooooooooooooooooooooooooooooooooooooong line >93 chars"); <div class='quotetop'>QUOTE </div>  --- Quote Start ---  Where it the processor stuck if you press pause in the debugger?[/b]  --- Quote End ---   Varies (ofcourse): Sometime in OsCore.c as         for (;;) {        OS_ENTER_CRITICAL();        OSIdleCtr++;        OS_EXIT_CRITICAL();# if OS_CPU_HOOKS_EN        OSTaskIdleHook();                        /* Call user definable HOOK                           */# endif Some times its in alt_irq.c caught doing static ALT_INLINE alt_irq_context ALT_ALWAYS_INLINE       alt_irq_disable_all (void) {  alt_irq_context context;  NIOS2_READ_STATUS (context);  NIOS2_WRITE_STATUS (0);    return context; } static ALT_INLINE void ALT_ALWAYS_INLINE       alt_irq_enable_all (alt_irq_context context) {  NIOS2_WRITE_STATUS (context); } Stepping down into the code is very confusing, at least to me, it jumps in an unexpected manner. Maybe its the macros which plays me a trick or maybe the interrupts. Anyway it seems to always spin in the same track of this for(;;) loop.  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  I wonder whether this is something to do with event flags. When the UART driver&#39;s buffer fills up it waits on an event (ALT_FLAG_PEND in altera_avalon_uart.c).[/b]  --- Quote End ---  I never caught it down in altera_avalon_uart.c <div class='quotetop'>QUOTE </div>  --- Quote Start ---  In the uCOS-II case this uses the event flag mechanism built into the OS. But you haven&#39;t started the OS yet (by calling OSStart) so the event flags may not work correctly (I haven&#39;t looked at the code yet).[/b]  --- Quote End ---  I tried using tasks also. In fact that was where I came from before stripping the code to minimum. If I call OSStart() The tasks start and run correctly. I never get past OSStart() so putting printf&#39;s here will never get called, unless maybe all my tasks stops, but thats not what I wanted. Putting printf() before breaks as described above. My last option is to create a task for printing my message. Thanks for reading this far. Comments welcome.

[Altera_Forum]

I too have had difficulty printing before tasking is started with uC/OS-II.  

 I believe it will always cause uC/OS-II to hang if a pend call is made from main. This happens because the scheduler ends up getting started in the pend call. So it is almost equivalent to calling OSStart (without initializing properly).  Labrosse (author of uC/OS-II) suggests that one shouldn&#39;t start tasks from within main, but rather from within a task. This would also fix your problem. The reason Labrosse suggests it, is because the statistics task won&#39;t work properly if the tasks are started before OSStart.  In my application we have a short lived task which is basicly the equivalent of your main and we only start the one task from within main.  Hope this helps.

[Altera_Forum]

Thanks for the suggestion.  

<div class='quotetop'>QUOTE </div>  --- Quote Start ---  Labrosse (author of uC/OS-II) suggests that one shouldn&#39;t start tasks from within main, but rather from within a task. This would also fix your problem. The reason Labrosse suggests it, is because the statistics task won&#39;t work properly if the tasks are started before OSStart.[/b]  --- Quote End ---  If thats the recommended way of building a system, and who should know better than the author, the sample applications created by the NIOS II IDE environment ought to be updated to reflect this detail.