Searching \ for '[PIC] HiTech C and Local Variables' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'HiTech C and Local Variables'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] HiTech C and Local Variables'
2005\04\26@084159 by James

flavicon
face
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.

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...

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.

James

2005\04\27@042021 by Alvaro Deibe Diaz

picon face
Hi, James.

I had troubles with RAM in F877's some time ago. PICC 8.05PL2, and MPLAB5.x.

It was a difficult problem to track, as yours, but in my case i was
experimenting resets now and then... impossible to track with the emulator.
Only happening in the "real" environment.

Finally i came across a problem with a vector index getting crazy (my guilt,
of course). PICC uses the FSR to access vectors, so a wrong index can access
anywhere in the RAM. In my case, it was accessing the program counter, and
that was the cause for the resets.

PICC puts local and static variables in different places, thus changing your
local variable to static can get it away from the problem. But the problem
is still there.

I've updated past month to 8.03PL3 (untill the end of some projects), so I
have little experience with this release. But no problem so far.

Regards,

Alvaro Deibe Diaz.

{Quote hidden}

> -

2005\04\27@042355 by Michael Rigby-Jones

picon face


{Quote hidden}

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.

{Quote hidden}

I would email EraseMEsupportspam_OUTspamTakeThisOuThtsoft.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.
=======================================================================

2005\04\27@081717 by Mauricio Jancic

flavicon
face
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
infospamspam_OUTjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519


> {Original Message removed}

2005\04\27@095207 by James

flavicon
face
Hi Alvaro,

Thanks for your feedback. I did suspect an index might be going crazy as you
suggest, but I haven't tracked anything down so far. I'll give it another
careful look.

James

> {Original Message removed}

2005\04\27@095408 by James

flavicon
face
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 removed}

2005\04\27@100510 by Michael Rigby-Jones

picon face


{Quote hidden}

James,

Yes, Hitech can cause trouble sometimes with local vars!  However, only
under very specific circumstances.  If you enable optimisations, the
compiler attempts to use as many redundant (for that function) SFR's as
possible to contain local variables, such as PRODH, PRODL, FSRx etc.  If
you include inline assembly that uses these registeres, the compiler
can't "see" it, so local variables can get scrubbed unintentionaly.

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.
=======================================================================

2005\04\27@101247 by Gerhard Fiedler

picon face
James wrote:

> 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.

> 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.

As you've been told already, since you are using pointers, nothing in the
PIC's address space is safe anymore :)

Local automatic (non-static) variables are only valid as long as you are
executing the function that declares them or any function called by it. So
it's likely that the problem is in one of these places.

If for example a function called by the one of which the local variables
get overwritten uses a pointer to its own local variables and the pointer
goes out of bounds, it could easily overwrite the local variables of the
calling function -- they may be right next to the function's own local
variables. Of course, declaring those overwritten variables removes /that/
symptom of the problem, but doesn't really solve the problem :)


> 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've found that it's worth it to use the forum. It may have less traffic
overall than this list, but it's more targeted.

Gerhard

2005\04\27@102946 by James

flavicon
face
{Quote hidden}

Hi Mike,

Thank you for the info! That is interesting. I did try turning off all
optimizations, (compiler and assembler) in case it might be the cause of the
trouble, but it made no difference in my case - more evidence that it's my
code at fault, somewhere...

James

2005\04\27@133825 by James

flavicon
face
{Quote hidden}

Thanks Gerhard. I'll take a very close look, statically, at the code to see
what might be happening. I'm guessing it will be obvious _once_ I see it!

James

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...