• State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 22 subscribers
  • Views 3551 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

bug in strcpy

Johann Kok

I have the following structure:

struct fence_struct	{
  unsigned char	mode;
  char		sitename[13];
  unsigned char	sector_nr;
  unsigned char	sector_tot;
  unsigned int	start;
  unsigned int	feeder_offset;
  unsigned int	len;
  unsigned int	line_len;
  unsigned char	begin_far;
  unsigned int	res_norm;
  unsigned int	res_min;
  unsigned int	res_max;
  unsigned char	wire_amount;
  unsigned char	wire_name[12];
};

xdata struct fence_struct  fence;

I then initialise fence.sitename like this in the function init_vars():
strcpy(fence.sitename, "SITENAME");

and it generates this assembly:
;strcpy(fence.sitename, "SITENAME");
;SOURCE LINE # 1535
MOV  	R0,#LOW (fence+01H)
MOV  	R4,#HIGH (fence+01H)
MOV  	R5,A
MOV  	R3,#0FFH
MOV  	R2,#HIGH (?SC_403)
MOV  	R1,#LOW (?SC_403)
LCALL	?C?STRCPY

WHICH DOESN'T WORK

However, when I call exactly the same line in the function misc_info() it generates the following assembly:
;strcpy(fence.sitename, "SITENAME");
;SOURCE LINE # 4306
MOV  	R0,#LOW (fence+01H)
MOV  	R4,#HIGH (fence+01H)
MOV  	R5,#01H
MOV  	R3,#0FFH
MOV  	R2,#HIGH (?SC_403)
MOV  	R1,#LOW (?SC_403)
LCALL	?C?STRCPY

WHICH WORKS FINE

Why does it generate different assembly for the same source line and how can I rectify it?

Parents
  • 0 in reply to Johann Kok

    OK, so the state of this analysis is that probably the content of the Accu is not the expected 01H if your routine number 1 is called as the consequence of a "going out of PGM mode" condition.

    Among other things, this just might be a hardware bug.

    Without seeing a lot more of your code (or a smaller, self-contained example case that still shows the problem), it'll be quite impossible for anyone but yourself to debug this further. You may have to use an ICE or logic analyser to see what the CPU actually does.

    (BTW: does it work in the Keil simulator?)

Reply
  • 0 in reply to Johann Kok

    OK, so the state of this analysis is that probably the content of the Accu is not the expected 01H if your routine number 1 is called as the consequence of a "going out of PGM mode" condition.

    Among other things, this just might be a hardware bug.

    Without seeing a lot more of your code (or a smaller, self-contained example case that still shows the problem), it'll be quite impossible for anyone but yourself to debug this further. You may have to use an ICE or logic analyser to see what the CPU actually does.

    (BTW: does it work in the Keil simulator?)

Children
  • 0 in reply to HansBernhard Broeker

    Well,

    If the program works after a cold start, I seriously doubt that there is a compiler or code generation problem. In fact, I'd start looking at the state of the device after exiting programming mode.

    However, since your device PROBABLY won't be programmed (in the field) and immediately started running (in the field) I don't think this is a critical issue. I mean, you are going to load the program into the device and send it somewhere (probably unpowered). Once it gets to its destination and powered-up, everything will work fine (since cold starts work OK).

    Jon

  • 0 in reply to Jon Ward

    I agree with you: The fact that it initialises the variables correctly after a cold start or after the 2nd reset shows to me that, contrary to what the datasheet says, the DS5000T DOES NOT execute a complete reset after it's taken out of pgm mode.

    But then again, why does it initialise the numerical variables before and after the strcpy() in question correctly but not the strcpy() itself??