Hi Mauricio,

Thanks for your post. TBH I've been doing that for the last few days.
(divide and conquer - the most basic debug approach of course.) It's proving
extremely hard to pin down though. Keep plugging away I know! ;)

The fact that no one so far has said "yes, HiTech C can cause trouble
sometimes with local vars" indicates at least it is probably my fault and
not the compiler, so I am in a position to deal with it I think.

James


> -----Original Message-----
> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu]On Behalf
> Of Mauricio Jancic
> Sent: 27 April 2005 13:17
> To: 'Microcontroller discussion list - Public.'
> Subject: RE: [PIC] HiTech C and Local Variables
>
>
> Why don't you start eliminating routines and parts of code until
> the problem
> solves. Then, start again allowing the code to run. That might help
> identifying where the problem is in the code...
>
> Regards,
>
> Mauricio Jancic
> Janso Desarrollos - Microchip Consultants Program Member
> info@janso.com.ar
> www.janso.com.ar
> (54) 11 - 4542 - 3519
>
>
> > -----Original Message-----
> > From: piclist-bounces@mit.edu
> > [mailto:piclist-bounces@mit.edu] On Behalf Of Michael Rigby-Jones
> > Sent: Wednesday, April 27, 2005 5:23 AM
> > To: Microcontroller discussion list - Public.
> > Subject: RE: [PIC] HiTech C and Local Variables
> >
> >
> >
> > >-----Original Message-----
> > >From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu]
> > >Sent: 26 April 2005 13:44
> > >To: Microcontroller discussion list - Public.
> > >Subject: [PIC] HiTech C and Local Variables
> > >
> > >
> > >I'm wondering if anyone else has come across strange behaviour
> > >sometimes when using local function variables with HiTech's PIC C
> > >compiler (latest version - 8.05PL2, and also 8.03PL3)?
> > >
> > >The contents of temporary local variables in some of my
> > functions are
> > >getting overwritten without reason. By changing them to
> > static it fixes
> > >the problem.
> > >
> > >I'm having to allocate a lot of the other variables in 3 of
> > the banks,
> > >so I'm wondering if that is a cause? I've turned off all
> > optimization
> > >and it still happens. At no point does any of my code write to an
> > >address in RAM except via a pointer to a variable, so I
> > can't see how
> > >these variables are getting overwritten.
> > >
> >
> > I think that statement might be a little optimistic.  Even if
> > you only use pointers to access all your variables (which in
> > itself seems unlikely), then you still have to initialise the
> > pointer which will be stored in RAM.
> >
> > >What makes it so much harder to track down is that it
> > doesn't happen in
> > >the MPLAB similuator but only when I program the PIC, of
> > course! ;) So
> > >I'm debugging with a scope and some diagnostic pin output...
> >
> > If it dosen't happen in MPLAB then either you aren't
> > simulating enough states/inputs or you are hitting a silicon
> > bug in the real part.
> > However, as the 16F876A is now quite a mature part I would
> > think that the former is more likely.
> >
> > >
> > >I've been using this compiler for a couple of years without this
> > >trouble before, but with this code it's happening all over
> > the place.
> > >I've never targeted this PIC (16F876A) before, but I doubbt that's
> > >central to it.
> > >
> > >I could raise this on HiTech's forum but that gets little
> > traffic. I'm
> > >really looking for any experiences from people here that
> > could backup
> > >or otherwise what I think I'm seeing!
> > >Many thanks.
> > >
> >
> > I would email support@htsoft.com with an example of code that displays
> > the problem.  They tend to resolve problems very quickly if you go
> > through this route.  They don't always look at the forum on a regular
> > basis so bug reports on there take longer.
> >
> > Regards
> >
> > Mike
> >
> > ==============================================================
> > =========
> > This e-mail is intended for the person it is addressed to only. The
> > information contained in it may be confidential and/or protected by
> > law. If you are not the intended recipient of this message, you must
> > not make any use of this information, or copy or show it to any
> > person. Please contact us immediately to tell us that you have
> > received this e-mail, and return the original to us. Any use,
> > forwarding, printing or copying of this message is strictly
> > prohibited.
> > No part of this message can be considered a request for goods or
> > services.
> > ==============================================================
> > =========
> >
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist