Re: [Sdcc-user] PIC18F4550 Using larger variables - more clues

[Raphael N. <rn...@we...>]

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