LAST printf always missing ?

[JulyJim]

Have been running 1.6.0 Nov build on Due and just noticed this.
I am reluctant to "upgrade" to 1.6.3 "just because" since 1.6.0 works for me so far.
I can hack this problem by duplicating the last printf lines but would like to know what COULD be the real cause of this.

Here is a simple test of printf and its output
The problem is - LAST printf is always missing from monitor output.

1. Number of for iterations makes no difference
2. monitor baud rate makes no difference
3. removing the "count blank " line will make the previous for loop miss the past printf.

# define DEBUG

void setup() {
  // put your setup code here, to run once:
  //Serial.begin(115200);
  Serial.begin(9600); 

  delay(1000);

  for (int i = 0; i <= 5; i++)
    printf("\n Count %i ", i);
# ifdef DEBUG

  for (int i = 0; i <= 5; i++)
    printf("\n Count %i ", i);
# endif

  for (int i = 0; i <= 5; i++)
    printf("\n Count %i ", i);

  printf("\n Count blank ");   // missing from output 
}

Sample code

 Count 0 
 Count 1 
 Count 2 
 Count 3 
 Count 4 
 Count 5 
 Count 0 
 Count 1 
 Count 2 
 Count 3 
 Count 4 
 Count 5 
 Count 0 
 Count 1 
 Count 2 
 Count 3 
 Count 4 
 Count 5 

[matthijskooijman]

Uhm, by default printf doesn't actually work on Arduino AFAIK? Your sketch also doesn't have a loop function. Could you provide a minimal, but complete example showing the problem?

To take a guess at the cause: perhaps you are disabling interrupts and never re-enable them? That would cause the printed bytes to stay queued and never be actually sent.

[JulyJim]

Thanks for replay.I have been using "officially published by Arduino " print class on thousandths of printf functions. The snippet provided is just one of the ways I have tested this.The for loop was just another way and it ALWAYS missed LAST iteration on LAST for loop.
I am not looking for detailed analysis, just SOME clue what may be wrong.
BTW I bypassed the code modification of print class and printf still worked. I need to verify if I actually modified the correct file! While doing that found that stdio.h is included in print file, and what is really puzzling is that Arduino explanation for printf not working because "stdio.h" in NOT part of Arduino code core! But it is included in print.h! Probably another Due  fluke. 

There are no interrupts involved and as I said - it will ALWAYS fail the last printf. I just did bare bones like this and it fails the second printf.

 void setup() {  Serial.begin(115200);  delay(1000); 
   printf("\n Count blank output 1 \n");   terminating the printf with \0 won't make any difference   fflush(stdout);   delay(1000); 
  printf("\n Count blank output 2 \0"); }

[matthijskooijman]

Ah, I missed you were on a Due, I don't know too much about the core implementation there :-)

No clue what's going on there, though. Does the issue happen if you use Serial.print instead of printf?

Does it happen if you add \n at the end of the last print? I'm wondering if there is some sort of line buffering somewhere in the stdio/printf stack.

[PaulStoffregen]

This is really interesting. Apparently buried in all the ASF & CMSIS stuff is more hardware serial code.

It appears to be doing line buffering, holding prior text until you print a newline. For example, if you try running this, you'll get the last line.

void setup() {
  Serial.begin(9600);
  delay(1000);
  for (int i = 0; i <= 5; i++)
    printf("\n Count %i ", i);
  for (int i = 0; i <= 5; i++)
    printf("\n Count %i ", i);
  printf("\n Count blank \n"); // NOT missing from output  :)
}

void loop() {
}

[JulyJim]

Hey Paul, I just took a break painting piano room ( honeydo) and guess what, came up with same idea.Build EXACT same code as you did (looks familiar !) and pasted it over Arduino BareMinimum sketch and it works!YES, I am still working on the USB video and have ASF code all over the place ( based on USBHost etc.)  and this shows up after I get USB into CONFIGURING state. Maybe sooner, but that is where I first noticed this. I am using interrupts after all the USB configuring is finished, but this shows up before that.  I am not thru analyzing the interrupt, sorry , that is still "TO DO". 
I am using both Serial and printf, but have not tried using Serial in same block which I know is giving me this grief. I'll do that soon.Maybe this will also explain why some of the "foreign" (ASF?) trace macros do not work.
Adding \n or \0 makes no difference when it fails. 
Did you modify the print.h?
I really need to remove the print.h modification FOR SURE.Due ( 1.6.0) Print.h has stdio included and SHOULD not need the mod.
Thanks for looking into this, appreciate the help.Vaclav 

[JulyJim]

Here is printf and Serial test
Code snippet added to main() of my USB program

 printf("\n LAST printf Count blank output 2 \0"); // %i ", i);
  Serial.println("\n LAST Serial Count blank output 2 \0");
 printf("\n LAST printf Count blank output 2 \0"); // %i ", i);
  Serial.println("\n LAST Serial Count blank output 2 \0");
for(;;); 

And here is the output - should be 2 of each Serial & printf .
I am sure it will work OK on BareMinimum sketch , but it is too late today to try it.

LAST Serial Count blank output 2 
 LAST printf Count blank output 2 

 LAST Serial Count blank output 2 

[JulyJim]

Here is a result of "programming while you sleep" .
This is a shameless half hack Mickey Mouse style.
Now if I can figure out how to pass parameters to Serial it will be full hack usable in my main program.

It obviously "works" only in BareMinimum sketch without parameters.

void setup() {
  Serial.begin(115200);
  delay(1000);
  //#define x
#define printf Serial.println          //(x)
  for (int i = 0; i <= 5; i++)
    printf("\n printf Count %i "); //, i); 

#define printf Serial.print           //remove ln  to  check if really using Serial 
  for (int i = 0; i <= 5; i++)
    printf("\n Count %i "); // , i);
  printf("\n Count blank \n"); 
}

void loop() {}

[bperrybap]

This seems like normal behavior to me for buffered standard i/o - that same thing can happen in real operating systems.
I'm assuming since they are doing buffered i/o that they will also support fflush() to flush out the buffered data - which is the normal way to ensure that all your data gets sent.

[JulyJim]

Here is a partial copy of one my previous posts when I used fflush() with same failure.
I have added fflush AFTER the failing (last) printf and it prints! .

So the solution is to add fflush to the Arduino print class modification.
SOLVED Thanks

There are no interrupts involved and as I said - it will ALWAYS fail the last printf. I just did bare bones like this and it fails the second printf.

 void setup() {  Serial.begin(115200);  delay(1000); 
   printf("\n Count blank output 1 \n");   terminating the printf with \0 won't make any difference   fflush(stdout);   delay(1000); 
  printf("\n Count blank output 2 \0"); }
fflush(stdout);