printf_P intermittant not included with a compile

Go To Last Post

9 posts / 0 new

Author

Message

MaxK

Level: Hangaround

Joined: Wed. Jul 25, 2001

Posts: 324 View posts

Location: Few feet away from a grunting watercooled ATMEGA aware of imminant detonation.

Posted by MaxK: Sun. Sep 23, 2007 - 01:52 PM

Ive not been using AVRGCC frequently lately, but I had a serious hard time not to question my own abilities with this possible bug.

All ive done is place a few printf_P rapidly following each other. The end result is that when compiled only some are actually added to the elf and output hex files.

troubled code:

	printf_P(PSTR("\r\n1 Test firmware t.01\r\n"));
	spi_Init();
	printf_P(PSTR("\r\n2 Test firmware t.01 \r\n"));
	spi_Init();
	printf_P(PSTR("3 this is a super string bladiblah Serial Peripheral Interface:"));
	printf("4 this is a super string bladiblah Serial Peripheral Interface:");
	if (spi_Init() == 0)
	printf_P(PSTR("OK\r\n"));
	else
	printf_P(PSTR("ERROR\r\n"));

//	memtest();

output:

1 Test firmware t.01

2 Test firmware t.01
4 this is a super string bladiblah Serial Peripheral Interface:OK

3rd printf_P has gone into an other dimension? :P

Replacing printf_P for printf solves it, but thats not an option.

Help needed :D

//Steven

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

Tags:

Tools, Compilers and General Programming

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30664 View posts

Location: Wormshill, England

Posted by david.prentice: Sun. Sep 23, 2007 - 02:52 PM

Are you sure you do not have a carriage-return lurking somewhere. So your third string is immediately overwritten by the 4th string ?

On a normal stdio program, a fprintf(stderr, "..") can interfere with a fprintf(stdout, "xxx") but that is because the stderr and sdout streams can have different buffering. Your problem is always writing to stdout. It is just the location of the format string that alters with printf_P().

A mystery.

David

MaxK

Level: Hangaround

Joined: Wed. Jul 25, 2001

Posts: 324 View posts

Location: Few feet away from a grunting watercooled ATMEGA aware of imminant detonation.

Posted by MaxK: Sun. Sep 23, 2007 - 03:17 PM

ive placed a breakpoint in the avr-studio simulator at the isr- tx character routine.... Not seen that string pass there!

Its seemingly ignored by the compiler.

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

JohanEkdahl

Level: 10k+ Postman

Joined: Wed. Mar 27, 2002

Posts: 26945 View posts

Location: Lund, Sweden

Posted by JohanEkdahl: Sun. Sep 23, 2007 - 05:20 PM

Ideas:
What does printf_p return?
What happends id you shorten the thirs string to eg "3 short".

What if the strings with missing \n's are causing the printf buffer to overflow?
What happends if you insert \n's in the strings that miss them?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

MaxK

Level: Hangaround

Joined: Wed. Jul 25, 2001

Posts: 324 View posts

Location: Few feet away from a grunting watercooled ATMEGA aware of imminant detonation.

Posted by MaxK: Sun. Sep 23, 2007 - 06:31 PM

JohanEkdahl wrote:

Ideas:
What does printf_p return?
What happends id you shorten the thirs string to eg "3 short".

What if the strings with missing \n's are causing the printf buffer to overflow?
What happends if you insert \n's in the strings that miss them?

short strings seem to be ignored at various code configurations as well. there doesnt seem to be a direct \r\n relationship to the strings.

:shock:

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

JohanEkdahl

Level: 10k+ Postman

Joined: Wed. Mar 27, 2002

Posts: 26945 View posts

Location: Lund, Sweden

Posted by JohanEkdahl: Sun. Sep 23, 2007 - 06:40 PM

Careful with the \r's as they are exactly the Carriage-Return's that David warns about.

Any chance you could post a short but complete avr-gcc project that exhibits the bahaviour?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Sun. Sep 23, 2007 - 06:48 PM

Well I just built this code then checked the .lss and found:

int main(void){
  f2:	8b e9       	ldi	r24, 0x9B	; 155
  f4:	90 e0       	ldi	r25, 0x00	; 0
  f6:	9f 93       	push	r25
  f8:	8f 93       	push	r24
  fa:	41 d0       	rcall	.+130    	; 0x17e 
  fc:	83 b1       	in	r24, 0x03	; 3
	printf_P(PSTR("\r\n1 Test firmware t.01\r\n")); 
   spi_Init(); 
   printf_P(PSTR("\r\n2 Test firmware t.01 \r\n")); 
  fe:	81 e8       	ldi	r24, 0x81	; 129
 100:	90 e0       	ldi	r25, 0x00	; 0
 102:	9f 93       	push	r25
 104:	8f 93       	push	r24
 106:	3b d0       	rcall	.+118    	; 0x17e 
 108:	83 b1       	in	r24, 0x03	; 3
   spi_Init(); 
   printf_P(PSTR("3 this is a super string bladiblah Serial Peripheral Interface:")); 
 10a:	81 e4       	ldi	r24, 0x41	; 65
 10c:	90 e0       	ldi	r25, 0x00	; 0
 10e:	9f 93       	push	r25
 110:	8f 93       	push	r24
 112:	35 d0       	rcall	.+106    	; 0x17e 
   printf("4 this is a super string bladiblah Serial Peripheral Interface:"); 
 114:	80 e0       	ldi	r24, 0x00	; 0
 116:	91 e0       	ldi	r25, 0x01	; 1
 118:	9f 93       	push	r25
 11a:	8f 93       	push	r24
 11c:	1c d0       	rcall	.+56     	; 0x156 
 11e:	83 b1       	in	r24, 0x03	; 3
   if (spi_Init() == 0) 
 120:	2d b7       	in	r18, 0x3d	; 61
 122:	3e b7       	in	r19, 0x3e	; 62
 124:	28 5f       	subi	r18, 0xF8	; 248
 126:	3f 4f       	sbci	r19, 0xFF	; 255
 128:	0f b6       	in	r0, 0x3f	; 63
 12a:	f8 94       	cli
 12c:	3e bf       	out	0x3e, r19	; 62
 12e:	0f be       	out	0x3f, r0	; 63
 130:	2d bf       	out	0x3d, r18	; 61
 132:	88 23       	and	r24, r24
 134:	41 f4       	brne	.+16     	; 0x146 
	   printf_P(PSTR("OK\r\n")); 
 136:	8c e3       	ldi	r24, 0x3C	; 60
 138:	90 e0       	ldi	r25, 0x00	; 0
 13a:	9f 93       	push	r25
 13c:	8f 93       	push	r24
 13e:	1f d0       	rcall	.+62     	; 0x17e 
 140:	0f 90       	pop	r0
 142:	0f 90       	pop	r0
 144:	07 c0       	rjmp	.+14     	; 0x154 
   else 
   	printf_P(PSTR("ERROR\r\n")); 
 146:	84 e3       	ldi	r24, 0x34	; 52
 148:	90 e0       	ldi	r25, 0x00	; 0
 14a:	9f 93       	push	r25
 14c:	8f 93       	push	r24
 14e:	17 d0       	rcall	.+46     	; 0x17e 
 150:	0f 90       	pop	r0
 152:	0f 90       	pop	r0
 154:	ff cf       	rjmp	.-2      	; 0x154

This contains rcall's to printf_P passing the following addresses: 009B, 0081, 0041, 0100, 003C and 0034. Another part of the LSS shows these to contain:

00000034 <__c.1560>:
  34:	45 52 52 4f 52 0d 0a 00                             ERROR...

0000003c <__c.1558>:
  3c:	4f 4b 0d 0a 00                                      OK...

00000041 <__c.1556>:
  41:	33 20 74 68 69 73 20 69 73 20 61 20 73 75 70 65     3 this is a supe
  51:	72 20 73 74 72 69 6e 67 20 62 6c 61 64 69 62 6c     r string bladibl
  61:	61 68 20 53 65 72 69 61 6c 20 50 65 72 69 70 68     ah Serial Periph
  71:	65 72 61 6c 20 49 6e 74 65 72 66 61 63 65 3a 00     eral Interface:.

00000081 <__c.1554>:
  81:	0d 0a 32 20 54 65 73 74 20 66 69 72 6d 77 61 72     ..2 Test firmwar
  91:	65 20 74 2e 30 31 20 0d 0a 00                       e t.01 ...

0000009b <__c.1552>:
  9b:	0d 0a 31 20 54 65 73 74 20 66 69 72 6d 77 61 72     ..1 Test firmwar
  ab:	65 20 74 2e 30 31 0d 0a 00                          e t.01...

The 0100 is because that's a RAM address, not a code address because the "4" string in the code above is printed with printf() and not printf_P() and therefore this string literal will have been copied to RAM.

Bottom line is that code builds to output ALL the strings given.

You may want to verify this in your own LSS

Cliff

MaxK

Level: Hangaround

Joined: Wed. Jul 25, 2001

Posts: 324 View posts

Location: Few feet away from a grunting watercooled ATMEGA aware of imminant detonation.

Posted by MaxK: Sun. Sep 23, 2007 - 07:13 PM

Holy Frac!

I found it, (i think).

I had the following code in my generic variable declaration header file. (vartypes.h)

#ifndef printf_P
#define printf_P printf
#endif

stupidly enough, it sometimes compiled correctly, sometimes parts of the code worked, sometimes i got complete shit over the screen.... Probably ive found it.

What is the correct pre-processor statement for detecting AVR-GCC?

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

abcminiuser

Level: Raving Lunatic

Joined: Fri. Jan 23, 2004

Posts: 9845 View posts

Location: Melbourne, Australia

Posted by abcminiuser: Sun. Sep 23, 2007 - 11:54 PM

Quote:

What is the correct pre-processor statement for detecting AVR-GCC?

Check to see if "__GNUC__" is defined, to see if the compiler is GCC.

Doing an "avr-gcc -E -dM Empty.c" on an empty C file yielded the following list of preprocessor defines in the latest WinAVR distribution:

#define __DBL_MIN_EXP__ (-125)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 32767
#define __DBL_DENORM_MIN__ 1.40129846e-45
#define __FLT_EVAL_METHOD__ 0
#define __DBL_MIN_10_EXP__ (-37)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 2
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 3.40282347e+38L
#define __UINTMAX_TYPE__ long long unsigned int
#define __LDBL_MAX_EXP__ 128
#define __SCHAR_MAX__ 127
#define __USER_LABEL_PREFIX__ 
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __DBL_DIG__ 6
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 1.17549435e-38L
#define __DECIMAL_DIG__ 9
#define __AVR_2_BYTE_PC__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 4
#define __DBL_MAX__ 3.40282347e+38
#define __DBL_HAS_INFINITY__ 1
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __DBL_MAX_EXP__ 128
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MIN__ 1.17549435e-38
#define __DBL_HAS_QUIET_NAN__ 1
#define __REGISTER_PREFIX__ 
#define __AVR_ARCH__ 2
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.1.2 (WinAVR 20070525rc2)"
#define __SIZE_TYPE__ unsigned int
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.19209290e-7L
#define __AVR 1
#define __LDBL_DIG__ 6
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __FLT_HAS_INFINITY__ 1
#define __LDBL_MANT_DIG__ 24
#define AVR 1
#define __WCHAR_TYPE__ int
#define __AVR__ 1
#define __FLT_DIG__ 6
#define __INT_MAX__ 32767
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 24
#define __WINT_TYPE__ unsigned int
#define __LDBL_MIN_EXP__ (-125)
#define __LDBL_MAX_10_EXP__ 38
#define __DBL_EPSILON__ 1.19209290e-7
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define __GNUC_MINOR__ 1
#define __DBL_MAX_10_EXP__ 38
#define __LDBL_DENORM_MIN__ 1.40129846e-45L
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __LDBL_MIN_10_EXP__ (-37)

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Jump To

Search form

printf_P intermittant not included with a compile

Tags: