>Re:
>
>>In an effort to try to debug the program that I am having trouble with, I
>>have stripped it down to the very basic essentials. It is now a program
>
>etc.
>
>Again, you have a typo:
>
>>         while(1)  // loop forever
>>         {
>>                 RC6=1;
>>                 DelayMs(2) ;
>>                 if (RA4 = 1)
>>                 {
>
>..
>
>should be if (RA4 == 1)
>
>Anyway, your _existing_ program toggles RD7 and RD6 every 92us on a
>PIC16C77 @ 20MHz.
>
>If you are running with a _crystal_, then there are a variety of
>reasons why it might not start, though frankly I've never had any
>problems with PICs and xtals.  If you're running with an external
>oscillator-in-a-can (like what's on the PICDEM-2 board), that
>eliminates yet more variables. The schematic in our Assembly Guide
>AG-1 available on our website may be useful to you ...
>
>One problem I've had with windowed parts is that they behave very
>strangely if they are nut fully UV erased prior to (re-)programming.
>
>You  don't mention what your "board" is ...
>
>--
>
>  ______________________________________
>Andrew E. Kalman, Ph.D.
>
>
>Salvo(TM), The RTOS that runs in tiny places(TM)
>Pumpkin, Inc.
>750 Naples Street
>San Francisco, CA 94112
>tel: (415) 584-6360
>fax: (415) 585-7948
>web: http://www.pumpkininc.com
>email: .....aekKILLspam@spam@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

>>I have corrected the typo, although that would not have stopped something
>>from toggling. I checked my circuit, and it is basically the same as yours.
>>The only difference is that I hardwired ~MCLR to +5 volts. The rise time is
>
>
>etc.
>
>I can only offer a few more suggestions:
>
>1) Use an even simpler program for the test. e.g.
>
>main() {
>     TRISD = 0x00;
>     PORTD = 0x55;
>here:
>     goto here;
>}
>
>No matter what else is going on in the system, PORTD should get stuck
>at 0x55, and resets won't affect that.
>
>2) Are you sure you're building the application for the 1674B? It
>might be for another chip ...
>
>Regards,
>
>--
>
>  ______________________________________
>   Andrew E. Kalman, Ph.D.   .....aekKILLspam.....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

> Incredible!! Even this does not work. I am doing something incredibly
> stupid, but I can't figure out what it is. Either that, or my programmer (a
> Topmax) is totally bad, and saying that it is programming chips, and
> verifying them, but not, and I can't believe that. Basically, I am now
> using a 16F874 chip, because it is quick and easy to erase, and I cannot
> get any code to work, although everything I try works fine in the
> simulator. Also, I have noticed that in spite of putting in a line
> TRISD=0x00, (or TRIS whatever), all ports appear to be tristated and
> sitting at 0, since a 10k pullup resistor easily pulls them to high. The
> only ports on my device that are at 1 are RD0 and RD1, because they are
> pulled up by external pullups. (But, nothing I do can get them to 0.)
>
> At this point, I am suspecting some strange hardware or programmer problem.
> Does anyone have a simple (even as simple as the code attached below), that
> is compiled for a 16F874. All I need is the hex file, and a brief
> explanation of what it does, as long as the hex file is known to work on
> actual hardware? Then, I could load that into one of my devices and see
> what it does on the actual board.
>
> TIA,
> Ed
> At 11:35 AM 8/6/2001 -0700, you wrote:
> >>I have corrected the typo, although that would not have stopped something
> >>from toggling. I checked my circuit, and it is basically the same as yours.
> >>The only difference is that I hardwired ~MCLR to +5 volts. The rise time is
> >
> >
> >etc.
> >
> >I can only offer a few more suggestions:
> >
> >1) Use an even simpler program for the test. e.g.
> >
> >main() {
> >     TRISD = 0x00;
> >     PORTD = 0x55;
> >here:
> >     goto here;
> >}
> >
> >No matter what else is going on in the system, PORTD should get stuck
> >at 0x55, and resets won't affect that.
> >
> >2) Are you sure you're building the application for the 1674B? It
> >might be for another chip ...
> >
> >Regards,
> >
> >--
> >
> >  ______________________________________
> >   Andrew E. Kalman, Ph.D.   EraseMEaekspam_OUTTakeThisOuTpumpkininc.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
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>

>Maybe I'm coming in late on this one, but...
>
>Is your oscillator oscillating?  Can I safely assume you've tried a
>different (lower frequency maybe even) xtal?  It *is* a parallel resonant
>xtal and not series resonant, right?
>
>Dale
>
>On Tue, 7 Aug 2001, Ed Troy wrote:
>
> > Incredible!! Even this does not work. I am doing something incredibly
> > stupid, but I can't figure out what it is. Either that, or my programmer (a
> > Topmax) is totally bad, and saying that it is programming chips, and
> > verifying them, but not, and I can't believe that. Basically, I am now
> > using a 16F874 chip, because it is quick and easy to erase, and I cannot
> > get any code to work, although everything I try works fine in the
> > simulator. Also, I have noticed that in spite of putting in a line
> > TRISD=0x00, (or TRIS whatever), all ports appear to be tristated and
> > sitting at 0, since a 10k pullup resistor easily pulls them to high. The
> > only ports on my device that are at 1 are RD0 and RD1, because they are
> > pulled up by external pullups. (But, nothing I do can get them to 0.)
> >
> > At this point, I am suspecting some strange hardware or programmer problem.
> > Does anyone have a simple (even as simple as the code attached below), that
> > is compiled for a 16F874. All I need is the hex file, and a brief
> > explanation of what it does, as long as the hex file is known to work on
> > actual hardware? Then, I could load that into one of my devices and see
> > what it does on the actual board.
> >
> > TIA,
> > Ed
> > At 11:35 AM 8/6/2001 -0700, you wrote:
> > >>I have corrected the typo, although that would not have stopped something
> > >>from toggling. I checked my circuit, and it is basically the same as
> yours.
> > >>The only difference is that I hardwired ~MCLR to +5 volts. The rise
> time is
> > >
> > >
> > >etc.
> > >
> > >I can only offer a few more suggestions:
> > >
> > >1) Use an even simpler program for the test. e.g.
> > >
> > >main() {
> > >     TRISD = 0x00;
> > >     PORTD = 0x55;
> > >here:
> > >     goto here;
> > >}
> > >
> > >No matter what else is going on in the system, PORTD should get stuck
> > >at 0x55, and resets won't affect that.
> > >
> > >2) Are you sure you're building the application for the 1674B? It
> > >might be for another chip ...
> > >
> > >Regards,
> > >
> > >--
> > >
> > >  ______________________________________
> > >   Andrew E. Kalman, Ph.D.   @spam@aekKILLspampumpkininc.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
> >
> > --
> > http://www.piclist.com hint: The PICList is archived three different
> > ways.  See http://www.piclist.com/#archives for details.
> >
> >
>
>--
>A train stops at a train station.  A bus stops at a bus station.
>On my desk I have a workstation...
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.

>At 05:12 PM 8/7/01 -0400, Ed Troy wrote:
>>Incredible!! Even this does not work. I am doing something incredibly
>>stupid, but I can't figure out what it is. Either that, or my programmer (a
>>Topmax) is totally bad, and saying that it is programming chips, and
>>verifying them, but not, and I can't believe that.
>
>Try this:
>
>Erase all .hex files, and re-assemble/compile.
>Maybe you aren't generating new code to put in the chips!
>(Or even any code at all!)
>
>If you find a .hex after that, open it with notepad, and see if it looks
>rational.
>Not full of 00s, or FFs,
>
>
>
>--
>Dave's Engineering Page: http://www.dvanhorn.org
>
>I would have a link to http://www.findu.com/cgi-bin/find.cgi?KC6ETE-9 here
>in my signature line, but due to the inability of sysadmins at TELOCITY to
>differentiate a signature line from the text of an email, I am forbidden to
>have it.
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.

>Hi Ed,
>
>My MegaMax programmer maybe similar to your TopMax
>programmer, and I have to manually tell it to program the config
>fuses. Even if I hit the "Auto" button, it programs an verifies OK but
>does not program the config bits untill I tell it to. Try it in the circuit
>and it just doesn't do anything, go back to the programmer and burn
>the config fuses and it's all go! This has caught me out heaps of
>times, usually when I have been programming 8051's for ages and
>forget what I have to do with PICs. I have nominated it to go on the
>100 factoids about PICs list.
>
>Brent Brown
>Electronic Design Solutions
>16 English Street
>Hamilton, New Zealand
>Ph/fax: +64 7 849 0069
>Mobile/text: 025 334 069
>eMail:  KILLspambrent.brownKILLspamclear.net.nz
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.