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