Bug in Teensy AVR Print class

B

bperrybap

Well-known member
Paul,
The Teensy AVR print class has a bug in the printNumberHex(unsigned long) function. This shows up when you print uint32_t variables.
If you print a number that is 8 hex digits, you won't get the proper output and it also looks like there is a buffer/stack overflow as well.
Anyway, it looks like the issue is the buffer is exactly 8 bytes which is ok since the code is calling write() with a length vs a C null terminated string,
however it looks like there is an issue with the way the p pointer is handled and then how write() is called once the buffer is built.

Here is a minimal sample sketch that shows the problem:

Code: 
void setup(void)
{
	Serial.begin(9600);
	while(!Serial);

	Serial.print(0x12345678, HEX);
}

void loop(void){}

This same issue may also exist in the other printNumberxxx() functions since the all look to use a similar methodology.

--- bill
 
Your code doesn't go bad on my 3.1? (96mhx Opt or not) - I added more to see what might show as odd and it looks okay?

I added a var and repeat prints +=0x10 and it shows 8 digits. Same as 7 digits - no leading 0x right? Tried with my var inside and global to setup().
 
That is because Teensy 3.1 is an ARM processor and not an AVR.
Like I said this is a bug in the Print class in the teensy AVR core code.
The Print class Teensy AVR code is different from the IDE supplied AVR code and is different from the Teensy ARM code.

--- bill
 
Alternative that I use instead of Serial.print... for the case being discussed
uint32_t n = 0x12345678;
Serial.printf("In hex, n is %08X\n", n);
 
Work arounds are easy and sure printf() is better, and also WAY better, IMO, than the goofy streaming stuff since you can do real formatting
but I ran into this bug when using an example using sketch in library code I didn't write and when things went wonky I tracked it down to a Print class bug.

I fixed the Print class code in my tree to avoid having the issue crop again.
But yeah, I agree with you that printf() is WAY better than all print() or streaming stuff.

Unfortunately, if you write a library and want it work on more than just the teensy boards
you can't depend on having the better routines available and must write the examples to use
the lowest common denominator, so I understand why print() was being used in this sketch.

--- bill
 
All true bill, arm for me and it shouldn't fail in the lib under normal use.

If you post the fix maybe it will inspire an update.

How did the crash show up? No blue screen here.
 
BlueScreen? Huh? we aren't talking about Windows or anything running on a PC host.
We are talking about code running on an AVR.

The AVR Print class code has a bug. I posted a small sample sketch which demonstrates the bug which is that the output generated will not be what it is supposed to be.
The bug needs to fixed.
There are several ways it can be fixed, all of which are easy and obvious once you know that there is bug.
I'll leave how it is fixed up to Paul since it is his code.

--- bill
 
Bill - I was joking of course there is no 'blue screen' . . . I was asking how you saw the error exhibit itself - did it just hang or do something odd on the USB output?

I under stand now the bug is in AVR and not in ARM as it worked for me. Since you have seen the issue and coded a fix - if you have the details of your fix at hand, posting it might help it get understood and addressed more quickly - if I understand how this 'place' works. Given Paul's exhibited skills I expect he could fix it as fast as he sneezes - having a pointer though might make it more timely for him to look that way. Altogether It might give others (myself) insight into recognizing and repairing underlying operations which would be cool.
 
You must log in or register to reply here.
Back
Top