Searching \ for '[PIC]: 18C452 code works in simulator, not in prog' 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=pic
Search entire site for: '18C452 code works in simulator, not in prog'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 18C452 code works in simulator, not in prog'
2000\11\09@152654 by Andrew E. Kalman

flavicon
face
Hi All.

For some time now I've been unable to resolve a PIC18C452 problem, so
I thought I'd ask the list for help.

I've created an application with MPLAB and MPLAB-C18 that basically
uses PORTB for some visuals and a single interrupt (TMR2). It works
great in the (albeit sloooooow) MPLAB-SIM simulator. All the timing
is fine, PORTB is changing as I expect, etc.

HOWEVER, when I program a JW windowed part and put it on a PICDEM-2
board, only part of the program works. The interrupt is happening at
the right rate (I have it toggle an LED on PORTB) down to the
millisecond, and a counter that is being incremented "in the main
loop" is reflected properly on some more LEDs hanging off PORTB, but
the rest of the program just ain't happening.

My best guess is that there is some issue w/regard to memory access
that is not the same between the simulator and the actual chip, and
therefore the rest of the code is "silent."

I've checked the errata, and there's nothing suspicious there.  I've
disabled all the options (e.g. Watchdog timer) when programming the
part through a PICSTART Plus. I've even sucked the code back from the
chip into MPLAB and simulated it, and it works fine in the simulator.

Any ideas on why it works in the simulator and not in the actual part?

Thanks,
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   spam_OUTaekTakeThisOuTspampumpkininc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@155551 by Thomas C. Sefranek

face picon face
"Andrew E. Kalman" wrote:

{Quote hidden}

Been there!

Done that!

Take heart, the chip really does work.

I've too often suspected the ICE-2000 for my 452 design difficulties,
and most times "I" was at fault.

Problems so far encountered...

Trying to use table read without invoking the FIX patch in the ICE-2000.
Trying to use the PICstart with just defaults and getting the Wrong clock
source.
Trying to use LFSR command... Forget it, it messes up the target RAM.
bad socket connections PLCC to DIP.

In every case of it works in the simulator and not in silicon, it was MY
fault.
(I have had the opposite!  IT WORKS in SILICON but the ICE-2000
overheats.)

If you send your code perhaps I can spot a problem..




{Quote hidden}

--
 *
 |  __O    Thomas C. Sefranek  tcsspamKILLspamcmcorp.com
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@175058 by Andrew E. Kalman

flavicon
face
Tom suggested:


>Trying to use table read without invoking the FIX patch in the ICE-2000.
>Trying to use the PICstart with just defaults and getting the Wrong clock
>source.
>Trying to use LFSR command... Forget it, it messes up the target RAM.
>bad socket connections PLCC to DIP.

I don't have an ICE-2000, but I checked and double-checked the other
issues and they don't seem to be the problem.  There are two LFSRs in
the MPLAB-C18 startup code, but the program gets past the startup OK,
so I don't think that's it.

I've narrowed it down to this: main() has an infinite loop that
reflects a counter to the outside world and an idle task blinks one
of those LEDs:

main()
{
       unsigned long counter;
       ...
       for (;;)
       {
         OSSched();
         PORTB = counter >> 8;
       }
}

...

OSIdleTaskHook (void)
{
       PORTB ^= 0x80;
}

OSSched() dispatches the idle task, which toggles PORTB:7. If I leave
this toggling in the code, I can see that it happens _once_, and then
never again, _and_ bit 0 of PORTB no longer shows bit 8 of the
counter -- it's stuck low. If I comment out the toggling, then the
counter works fine.

Now that I think about it, and remembering the weird stuff I saw
earlier today, it's as if togglings of PORTB (i.e. PORTB ^= 0x80) are
not "staying with the bit that I specified." Yet it compiles to a
simple MOVLW 0x80, XORWF 0xF81, so it can't possibly be corrupted at
runtime.

This is very odd ...

--

 ______________________________________
  Andrew E. Kalman, Ph.D.   .....aekKILLspamspam.....pumpkininc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@205746 by Andrew E. Kalman

flavicon
face
I have made progress ...

I was really stuck trying to figure out what was wrong in MPLAB-C18,
so I switched to HI-TECH's PIC18 C compiler.

The code didn't even work in the simulator! A quick message to Jeff @
HI-TECH revealed that the indirect function call that's in my test
code fails on the PIC18 because you can't MOVFF to the PCL, and
that's how the PIC18 C library function is currently written (a known
bug). So as per Jeff's suggestion I rewrote indir_func and lo and
behold, it now works in the SIM and in the chip. The PORTB weirdness
was mainly an oversight on my part.

So, here we have the following situation: in PIC18 C, indir_func (as
written in the library, known bad) works in MPLAB-ICE but not in the
chip, nor in the SIM.  Rewriting it to conform to the restrictions of
the MOVFF instruction makes it work in the SIM and in the chip (and
in MPLAB-ICE, I presume).

So Tom was right, the chip works!

Now I need to figure out why MPLAB-C18 doesn't generate code that
runs on the chip -- perhaps it also implements indirect function
calls incorrectly ...

Both MPLAB-C18 and PIC18 C are still relatively new, so it's not
surprising that these kinds of bugs pop up with stuff like indirect
fuinction calls ...

Regards, and thanks for the help!
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   EraseMEaekspam_OUTspamTakeThisOuTpumpkininc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\10@003808 by hard Prosser

flavicon
face
With the JW part - I've seen reports that not covering the window can cause
problems.
Also - is the clock working OK - if this is unreliable then it can cause
problems.
Brownout detector problem - DC voltage problem?,
And I had a problem with a solder short on the reset line - most confusing
- when the PIC perfomed its main action it suddenly reset itself!

Richard P

"Andrew E. Kalman" wrote:

{Quote hidden}

--
 *
 |  __O    Thomas C. Sefranek  @spam@tcsKILLspamspamcmcorp.com
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\10@084418 by Olin Lathrop

flavicon
face
> With the JW part - I've seen reports that not covering the window can
cause
> problems.

Yes, I want to second that.  When I was first learning about PICs, I tried
to do something quick and dirty with a 16C77 UV windowed part.  It would
sometimes work, and sometimes not.  I traced it down to the oscillator not
always running right.  After a while I noticed that it worked right only
when I had my hand within about 10cm of it.  While I was doing a mental
"what the ..." trying to understand how this minute change in capacitance
could possibly make a difference, someone else walked over about a meter
away and it worked fine whether my hand was there or not.  It turns out he
and my hand were blocking just enough of the light coming in from a nearby
window.  The oscillator didn't work unless the chip was kept sufficiently
dark.  Normal indoor room illumination was dark enough, but light from an
overcast sky was too bright.  I've religiously put stickers of the UV
windows of programmed parts ever since then.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinKILLspamspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\10@125959 by Mark Willis

flavicon
face
Olin Lathrop wrote:
> > With the JW part - I've seen reports that not covering the window can
> cause
> > problems.
>
> Yes, I want to second that.

<Snip>
Also RAM initialization is done "for free" (if very unreliably!) for /JW
parts, by ambient light - then when you later burn an OTP Part it won't
work as no initialization.  I always cover windows, AL foil embedded in
electrical tape is one way, it's pretty opaque <G>  (Unsure how UV
opaque electrical tape is, it's not IR opaque.)  Lots of other options
(see the archives <G>)

 Mark

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




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