Searching \ for '[PIC] Do an evil ghost live in my PIC18FxxJxx ? -' 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/devices.htm?key=18F
Search entire site for: 'Do an evil ghost live in my PIC18FxxJxx ? -'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Do an evil ghost live in my PIC18FxxJxx ? - '
2007\08\28@163130 by Ruben Jönsson

flavicon
face
>
> > 5. Does it show up in both debug and release? (does this even exist on  
> > 18F
> > compilers?)
>
> I am not sure what you mean vith debug and release?
>

In environments with enough resources (like a PC, pocket PC or higher end
embedded processors) the code in the libraries for standard functions are
written to behave somewhat differently depending on one or more preprocessor
symbols by the use of conditional compilation (#if, #ifdef, #else, #end and so
on).

During development, the compiler and linker can, by declaring a preprocessor
symbol (_DEBUG for example), be set to make more debug friendly code which
includes things like trace messages, validation of parameters, initialization
of allocated memory and so on. This is called the debug version of the program.

When the development and testing is finished, the code is compiled and linked
as a release version, which excludes a lot of the code that whas useful during
development and testing. The release version and the debug version should be
substantially identical regarding the inteded operations of the produced
functions. However, things like initialization of allocated memory in the debug
version could make the code operate differently in the release version if the
side effects of the debug version has been taken for granted by the programmer.

I don't know if this feature even exists for the PIC 18F C compilers, but it
could be a reason to why a program works during development but not standalone.

/Ruben


==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
spam_OUTrubenTakeThisOuTspampp.sbbs.se
==============================

2007\08\29@034349 by Morgan Olsson

flavicon
face

Thank you for the explanation, Ruben :)
I we have not seen that debugcode option in the compiler.

I built a 4-bit D/A on some pins to which we for example can dump a signature value for where the program is (one value for each interrupt for example) and track with analog or digital oscilloscope, and we use other pins directly, and also use ICD2.

Using Microchip C18 compiler and REAL-ICE you can select some events and variables to track while the CPU is running full speed, but AFAIK you cannot track everything that happens.

Better than nothing i bought REAL-ICE and we are changing from CCS PCWH to C18.
BTW, Hitec will begin to support REAl-ICE in next version coming in a month or two.

/Morgan

Den 2007-08-28 22:31:37 skrev Ruben Jönsson <.....rubenKILLspamspam@spam@pp.sbbs.se>:

{Quote hidden}

--
Morgan Olsson

2007\08\29@040806 by Xiaofan Chen

face picon face
On 8/29/07, Morgan Olsson <.....ost011KILLspamspam.....osterlen.tv> wrote:
> Using Microchip C18 compiler and REAL-ICE you can select
> some events and variables to track while the CPU is running
> full speed, but AFAIK you cannot track everything that happens.

I have not used Real-ICE but I hear that it is better than
ICD2. I have used ICE2000 and I think it is quite good.

> Better than nothing i bought REAL-ICE and we are changing
> from CCS PCWH to C18.

Good move! What I hear from my previous colleague was that
CCS was really buggy and the bugs keep changing across
different versions. Last time one of my colleagues specifically
mentioned not to switch CCS version for code maintenance.

CCS may be very good for some people because of the
provided libraries but what I hear is that it is not really up to
the standard of Hitech PICC.

C18 has bugs as well. What I hear is that the libraries are not
good. Normally the user should write his own peripheral
libraries.

> BTW, Hitec will begin to support REAl-ICE in next version
> coming in a month or two.

I have only uese Hitech PICC for the PIC16 series some years
ago. They were really good and should still be very good now.
At that time I used PICC and ICE2000 and I liked them both.
The processor module for ICE2000 is not cheap though. It is
said that PICC18 is also very good but I have never used them.

Regards,
Xiaofan

2007\08\29@045559 by Morgan Olsson

flavicon
face
Den 2007-08-29 10:08:01 skrev Xiaofan Chen <EraseMExiaofancspam_OUTspamTakeThisOuTgmail.com>:

> On 8/29/07, Morgan Olsson <ost011spamspam_OUTosterlen.tv> wrote:
>> Using Microchip C18 compiler and REAL-ICE you can select
>> some events and variables to track while the CPU is running
>> full speed, but AFAIK you cannot track everything that happens.
>
> I have not used Real-ICE but I hear that it is better than
> ICD2. I have used ICE2000 and I think it is quite good.
>
>> Better than nothing i bought REAL-ICE and we are changing
>> from CCS PCWH to C18.
>
> Good move! What I hear from my previous colleague was that
> CCS was really buggy and the bugs keep changing across
> different versions. Last time one of my colleagues specifically
> mentioned not to switch CCS version for code maintenance.

New versions pretty often fix bugs introduced in the former...
We keep install files for a few versions.
Having programmed around some compiler bugs, still this very problem i vent here is the same - even shows up when we changed to last version of elder 3.x series compiler.  That do sound like we have a problem in our code but we have gotten crazy trying to track it down.


> CCS may be very good for some people because of the
> provided libraries but what I hear is that it is not really up to
> the standard of Hitech PICC.
>
> C18 has bugs as well. What I hear is that the libraries are not
> good. Normally the user should write his own peripheral
> libraries.

I would prefer that for quality.  But time is running out on this project.
Thank you for the head-up!

I wish the compiler makers would keep official databases of bugs, so users need not beng into all bugs withput knowing about them until they show up in a bugfix release when having vasted lots of hours...

> I have only uese Hitech PICC for the PIC16 series some years
> ago. They were really good and should still be very good now.


Yes it looks from what i have seen people talk aboiut that it is good.
If i will do more programming myself i might buy the new Hitec compiler when they support REAL-ICE.
Other people find CCS libraries handy, so did we and at first it saved time.
Different compiler suits different needs, so i do not waht to start a discussion of which is best...
Currently we think we need REAL-ICE, and changing compiler means at least changign compiler bugs - it will be interesting...


--
Morgan Olsson

2007\08\29@051312 by Morgan Olsson

flavicon
face
Ah...!

I just realised i broke against the rules here; i forgot to tag the subject!
So i repost it using [PIC]
Sorry.
/Morgan


Den 2007-08-27 23:33:13 skrev Morgan Olsson <@spam@ost011KILLspamspamosterlen.tv>:

{Quote hidden}

--
Morgan Olsson

2007\08\29@064822 by Gerhard Fiedler

picon face
Xiaofan Chen wrote:

> Good move! What I hear from my previous colleague was that
> CCS was really buggy and the bugs keep changing across
> different versions. Last time one of my colleagues specifically
> mentioned not to switch CCS version for code maintenance.

That was my impression also about ten years ago when I checked it out. A
bit surprising -- and then not :) -- that this is still the case.

> I have only uese Hitech PICC for the PIC16 series some years
> ago. They were really good and should still be very good now.

I can second that. I've found the occasional compiler bug, but nothing like
the CCS bug dance.

Gerhard

2007\08\29@072712 by Dave Tweed

face
flavicon
face
Morgan Olsson <KILLspamost011KILLspamspamosterlen.tv> wrote:
> Is there anybody who have experienced anything odd, like functions
> returning wrong value, if statements evaluating erroneously, suspected
> nonprovoked jumps.. *occasionally*  while everything works OK during most
> executions of the same parts of code, then after a random time - bang!??

This has all of the earmarks of a stack overflow problem. The "random"
element is a result of it only happening when interrupts and the calling
sequence of the mainline code happen to stack up in a particular way.

In this case, you have to worry about both the hardware return stack in
the CPU as well as any software data stack that the compiler sets up.

For the hardware stack, you need to do an analysis of the maximum calling
depth of your mainline code + deepest interrupt sequence. Beware of any
recursion, and high/low priority interrupt nesting. CCS may have tools to
assist with this. You can also see whether STKFUL (stack full) and/or
STKUNF (stack underflow) are set when the error occurs.

I don't know what tools CCS provides for monitoring data stack usage. One
simple approach is to fill the stack area with some easily-recognized data
value before running the program, running it for a while, and then seeing
whether all of the stack locations got overwritten with other things.

-- Dave Tweed

2007\08\29@082707 by Russell McMahon

face
flavicon
face
>> Is there anybody who have experienced anything odd, like functions
>> returning wrong value, if statements evaluating erroneously,
>> suspected
>> nonprovoked jumps.. *occasionally*  while everything works OK
>> during most
>> executions of the same parts of code, then after a random time -
>> bang!??

> This has all of the earmarks of a stack overflow problem. The
> "random"
> element is a result of it only happening when interrupts and the
> calling
> sequence of the mainline code happen to stack up in a particular
> way.

Watchdog can also do something like this.
Long ago I had code which seemed to be operating perfectly but I found
that it was continually being reset by the watchdog timer. The nature
of the task was such that it would do it's thing for N.X cycles of the
total task and then be reset and, on average, the result was that all
worked apparently OK. It would be very easy for this sort of thing to
work often but not always.


       Russell


2007\08\29@084539 by Morgan Olsson

flavicon
face
Den 2007-08-29 13:27:11 skrev Dave Tweed <RemoveMEpicTakeThisOuTspamdtweed.com>:
> This has all of the earmarks of a stack overflow problem.

I think we tried what we could in this direction.
Forwarding to my programmer guy anyway.
Thanks

We are in the works moving the project to C18 and will probably not try CCS again on this source code.

--
Morgan Olsson

2007\08\29@125316 by Morgan Olsson

flavicon
face
Den 2007-08-29 14:13:44 skrev Russell McMahon <spamBeGoneapptechspamBeGonespamparadise.net.nz>:

> Watchdog can also do something like this.
> Long ago I had code which seemed to be operating perfectly but I found
> that it was continually being reset by the watchdog timer. The nature
> of the task was such that it would do it's thing for N.X cycles of the
> total task and then be reset and, on average, the result was that all
> worked apparently OK. It would be very easy for this sort of thing to
> work often but not always.
>
>
>         Russell

Thanks for your input.

We do have destruction of passed variables between function while it is running, and we do not have it resetting.

And watchdog is turned off now until we get the system running.



--
Morgan Olsson

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