Hi, > static volatile char xxx[19]; => static volatile char xxx[20]; > and with the value 19 it works and 20 it does not.
This is an ideal situation for debugging. Good work. > So I took the diff of the maps produced by the compiler (see bottom): > > My guess is , seeing that I'm right at the limit where variables > overflow the first bank 0000-0100 to 0200 and upwards (just > beyond the stack), that this has something to do with it. But > what? > > An other thing I noticed is that (see the diff file execrt here): > > < udata_stepper_6 udata 0x0000fe data 0x000001 > > udata_stepper_6 udata 0x000200 data 0x000001 [edited for clarity] > So some (what?) stepper_6 gets pushed to a different page. > Looking at the stepper.asm file I see: > > 00319 > 00320 udata_stepper_6 udata > 00321 _stepperDump_t_1_1 res 36 > 00322 The .map file fragment states that udata_stepper_6 is 1 byte long < udata_stepper_6 udata 0x0000fe data 0x000001 > udata_stepper_6 udata 0x000200 data 0x000001 and (by address) is in both cases filled with cntr from stepper.asm < _cntr 0x0000fe data extern ../obj/stepper.asm > _cntr 0x000200 data extern ../obj/stepper.asm In the given excepts I cannot make out any over-/multiple allocation issues, everything looks good to me. The fragment from stepper.asm does not match the .map file, are you sure the two resulted from the same build? [While writing this I got the idea that this might be a gplink bug, more details below.] > So this is a largish reservation, which I guess originates from this > (from stepper.c): > > stepperState t; > USE_STEPPER(CRITICAL(memcpy(&t,&STEPPER,sizeof(stepperState));)); Seemingly stepperState is a typedef'ed structure with a total size of 36 bytes, and it is declared in a function stepperDump. Now I wonder: Do you have multiple modules (.c files) called stepper, so that more than one of them allocate data in sections called udata_stepper_XXX, which are subsequently overlaid (incorrectly) by the linker? Try grep -Hn data_stepper_ * in your build dir to find out. You could also post the complete .map files (both working and failing) tar'ed and compressed (or zipped) > But why would this matter? And without realy understanding what > is going on I would have thought that moving this variable to > all on page would be better...?! > > Or wait a minute, I see that: > > < udata_usartd_0 udata 0x000201 data > 0x000001 > --- >> udata_usartd_0 udata 0x000202 data > 0x000001 > > So when stepperDump_t_1_1 is at 0x00fe it extends to the next page > (stack) which it should not (?) do but it does not matter since I > do not use that much stack, so probaply no collision there. However, > when it get pushed to 0x0200 then the variable udata_usartd_0 is > right there in the next address so where is my 36 bytes dude? So > the memset overwrite everything after that?! As pointed out above, I doubt the allocations are as you believe (the .map file fragments do not include any 36 byte size allocation), so ... > Could this be it? this is likely not to be it, but *if* your .map file and the .asm file result from the same build, you might have run into a gplink bug. What gputils version are you using? Can you try the latest svn? > Have I analyzed this correctly? If so why there is no linker warning? If things are as you state, this is a bug---probably that's why there is no warning. You could post your stepper.asm and the complete .map files (failing and working) so that I can double check this before reporting this to the gputils team. I would be interested to find out if (1) all udata_stepper_XXX sections are found in the .map and (2) if their sizes match (declared in .asm = allocated in .map) I think you are closing in on this one, good work so far. Regards, Raphael ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
