problem with strcpy

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have just upgraded from AVR3.2 to AVR3.3 (the winavr released 9/13)
I am seeing some strange behavior in strcpy that seems to be new. I don't know if I'm doing something wrong or there is a bug. Take a look at the following dissassemby chunk:

239: strcpy(szret,"!3\n");
+0000010C: E281 LDI R24,0x21 Load immediate
+0000010D: E393 LDI R25,0x33 Load immediate
+0000010E: E0AA LDI R26,0x0A Load immediate
+0000010F: E0B0 LDI R27,0x00 Load immediate
+00000110: C009 RJMP +0x0009 Relative jump
244: strcpy(szret,"!4\n");
+00000111: E281 LDI R24,0x21 Load immediate
+00000112: E394 LDI R25,0x34 Load immediate
+00000113: E0AA LDI R26,0x0A Load immediate
+00000114: E0B0 LDI R27,0x00 Load immediate
+00000115: C004 RJMP +0x0004 Relative jump
249: strcpy(szret,"DN\r");
+00000116: E484 LDI R24,0x44 Load immediate
+00000117: E49E LDI R25,0x4E Load immediate
+00000118: E0AD LDI R26,0x0D Load immediate
+00000119: E0B0 LDI R27,0x00 Load immediate
+0000011A: 8389 STD Y+1,R24 Store indirect with displacement
.........................................

266: strcpy(szret, "VERSION");
+00000145: E088 LDI R24,0x08 Load immediate
+00000146: 01DE MOVW R26,R28 Copy register pair
+00000147: 9611 ADIW R26,0x01 Add immediate to word
+00000148: E0EB LDI R30,0x0B Load immediate
+00000149: E0F1 LDI R31,0x01 Load immediate
+0000014A: 9001 LD R0,Z+ Load indirect and postincrement
+0000014B: 920D ST X+,R0 Store indirect and postincrement
+0000014C: 958A DEC R24 Decrement
+0000014D: F7E1 BRNE +0x7C Branch if status flag cleared
267: break;

Most of the strcpy work fine, but the strcpy of the "VERSION" places a series of 255's in szreturn. What is wrong?
Thanks,
Marc Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

offtopic:
maybe its better to use strcpyP(c,PSTR("somestring"));
because other strings consumes RAM.(even "static const char[]="somestring";")

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I took the same code and compliled in 3.2 and do not see the error. So is there a problem with the new library?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Most of the strcpy work fine, but the strcpy of the "VERSION" places a series of 255's in szreturn"

How did you determine this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I made an extended coff file and ran the program on an STK501 with the JTAG ICE , put a breakpoint at the beginning of the strcpy and stepped through the dissassembled code.
Note I did this only after seeing strange results on our target platform.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried doing?:
strcpy_P(szret, PSTR("VERSION")); // include

In looking at the avr-libc CVS, the code for the function strcpy hasn't changed since it's initial commit at 20020630. And, this function is written in assembly, i.e. it's not compiled from C so there isn't anything strange happening with the compiler.

I don't always trust a debugging environment. Are you sure your "strange results on [the] target platform" can be attributed to something like strcpy() that hasn't changed in over a year (and probably longer)? Perhaps something else is trashing the memory with 0xFFs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Marc,
It would be more helpfull if you could provide a small test source including Makefile which reproduces this error.

How is variable szret defined ? char szret[8];

Note: szret must be at least 8 bytes, in order to store string "VERSION".

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I had time to get back and exam this and apparently the problem is something in the debug environment. I don't see it stuffed with ffs otherwise. In fact it behaves properly. So the problem is either in the coff file or in the avrstudio debug environment. strcpy seems to be fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that the current ELF to COFF (or Extended COFF) converter is in *Beta*, and AVR Studio 3 *and* 4 are known to have problems. You should not completely trust a simulator environment.