On Thu, Aug 21, 2003 at 12:16:17PM -0400, Jai Dhar wrote:
> Ok, here are the results.
>
>
>First, I tested just the parport with the PSU disconnected. I am using the
>Computer PSU as I mentioned. With it disconnected, each pin registered a high
>of about 4.4V and a low of 90 mV. Connecting the PSU, but having it off
>resulting in wierd readings (a high would be 2.2V for example).. but I
>considered this insignificant since I would be only operating with the PSU
>on. With it on, I achieved the same results on the parport pins 2 through 5 -
>High = 4.4V and low = 90 mV.

OK. That sounds fine.

>
>Now, the voltage directly across the PSU's pins was 5.2V. +Vcc on the HCT
>(and yes, it is a 74HCT573 exactly) was 5.2V, along with +Vdd on the Pic.

Good. 5.2V is no problem for either the PIC or the HCT573.

>Also, pin 11 on the HCT was +5.2V (LE). GND on both the HCT and PIC were 0mV,
>and same with Pin 1 on the HCT (OE).

That takes care of the control signals.

>Now, I tried the voltages at the PIC
>pins (first I tried with just the parport remember). I did this with the PIC
>removedl.

As you should! ;-)

> For each pin (RB6/7, MCLR and PGM), a high was 5.2V and a low
>anywhere from 0.2 - 1.6 mV.

I presume that the pins matched up to the settings on the Debug page right?
Also are you absolutely sure that each of those pins are showing positive
polarity? I believe that David has the TLVP setting correct, but it's always
worth double checking.

> The Q4/Pin 10 on the parport test showed a 5.2V
>high and a 32 mV reading. And the READ pin did follow RB7 correctly when
>using Debug.

Cool.

And I presume that it still didn't work when you attempted to program. Right?

>I am using RB4, not RB3 as I am supposed to. So out of all of this, it
>seems the potential problem is the high of 5.2V instead of 5 as you
>suggested.

It isn't a problem.

> Maybe this isn't a problem, but this is hte only thing I can see.

It isn't a problem.

>I also switched PICs, again, and still didnt work.

The next step is threefold:

1) Switch machines and test on a new parallel port if possible.
2) Switch parallel port 10 to parallel port 11 and change the corrsponding
   config for DATA IN on FPP.
3) Take the RB7/DATA socket and try successively grounding and tying to VCC
   with a jumper. Try reading with FPP with no PIC in the socket. Verify that
   a full read of the program memory generates all 0's and all 1's
   respectively.
4) Next put the PIC back in, clear the FPP ram, then read the PIC.

One thing you'll want to do to help yourself is to stop trying to program
the part. A lot of info can be gathered simply by reading it. You can detect
if everything is working simply be reading the chip in:

* If the part is working then valid memory addresses will read as 0x3FFF.
  If not then they'll read as 0xFFFF.
* If the part is working then address 0x2006 and 0x2007 will have the values
  of the device ID and the config fuses. The ID locate will start with 0x072X.

One last thought. If somehow these parts have been programmed before and
LVP is disabled, then the LVP programmer will never work because it'll never
go into programming mode. At this point we may need to start thinking about
this as a possibility. We can move to the next stage and add HVP capability
removing all doubt. It'll require one NPN transistor and another resistor
along with a 12V power source, which you already have.

Another possibility is the fact that an unloaded PC power supply may have
difficulties maintaining regulation at light loads. Many articles suggest
driving the 5V line with some load (lamp, resistor, etc) to guarantee
regulation.

>I think that ISO idea
>would be a great thing (not only for me), since it would enable live testing.

I'll work on it. Do you have a CD Burner?

>I am so stumped.

As am I.

> You should develop some FreeBSD code :-) I have only used
>their ppi interface so far... pretty easy.

I'm a Linux guy but the principles are the same.

Except for the low level I/O interface which is pretty well encapsulated I
can't see any reason why picprg2.3 wouldn't run under FreeBSD as it's a console
app with an ncurses interface.

Another reason why picprg2.3[cde] is useful is that I added auto chip detection
to the front end. So if a 16F628, 16F877, or 16F84 is installed in the socket
and everything is wired correctly, it'll autodetect and you'll have a pretty
good idea that everything is working before you even attempt to download some
code to it.

>
>
> Anyway, maybe all my testing might tip you off. Let me know.

My blood is boiling at this point. No tip at all. Did you ground OSC1? It's
pin 16 on the PIC socket.

>
> Oh, btw, I am using a pot for the 1k resistor since I dont have a 1k on
>hand... and making a combo out of others is too annoying at this point. I
>have verified 1k on the pot though.  >

That's on one end and the middle wiper right?

BAJ

> Thank you,
>
> Jai
> On Sat, Aug 24, 2002 at 04:24:31PM -0400, Byron A Jeff wrote:
> > On Thu, Aug 21, 2003 at 07:56:34AM -0400, Jai Dhar wrote:
> > > Hello all,
> > >
> > >Despite all the things I have tried in the last few months, I STILL
> > >have not got a successful program loaded into my 16f628.
> >
> > Oh dear!
> >
> > > I am using TLVP with
> > >David Tait's FPP. I HAVE verified that the parport works by using FPP's debug
> > >function, and every pin works out as it should. I have rewired numerous times
> > >from scratch to ensure no errors.
> >
> > If you've verified pin operation at the socket and it's right, then no amount
> > of rewiring will matter.
> >
> > > Initially, I had a longer parport cord
> > >(6'), but I made my own that was much shorter.
> >
> > Good.
> >
> > > I thought maybe this was the
> > >problem, but it works with the debug feature.. I verified each pin's voltage
> > >high
> >
> > What voltage? It needs to be between 4 and 5 volts.
>
>
> >
> > > and low
> >
> > Same here. It needs to be between 0 and 1 volts.
> >
> > > with a DMM while switching them with FPP's debug feature. Even
> > >the read pin works fine, as it shows in the debug section.
> >
> > That's good.
> >
> > > I have increased
> > >the cycle delays to mad numbers that are extremely high, and still nothing
> > >works.
> >
> > Cycle delays won't help if the problem is elsewhere.
> >
> > > It just sais Read: 3FFF expected: 2828 (as 2828 was the first code to
> > >program). What is going on? I am getting desparate here for nothing has
> > >worked. I have even switched PIC's.
> >
> > Jai,
> >
> > It's not supposed to be this hard. I'm so sorry that you are having all these
> > troubles. Maybe we can setup a chat somewhere so that you and I can go over
> > this together.
> >
> > I'm going with the only one presumption:
> >
> > * That you are using a parallel cable of 2 feet or less.
> >
> > Let's go through it one more time:
> >
> > * Are you sure that the PIC has 5V power? And it's grounded?
> > * Are you using a 74HCT573? The HCT is critical for level conversion.
> > * Are you sure that the HCT573 has power and its control signals are wired
> >   correctly. Power needs to be 5V. BTW where are you getting that from?
> > * You have RB4 pin 10 wired as the PGM pin right? Not RB3.
> > * You verified each signal pin (RB7/DATA, RB6/CLK, RB4/PGM, MCLR) to make sure
> >   that they toggle between 0-1V for low and 4-5V for high?
> > * You double checked the polarity of each of the control signals?
> > * You double checked that the READ IN pin follows the DATA OUT pin.
> > * You have the resistor in place between Q0 (pin 19) of the HCT573 and RB7/DATA
> >   of the PIC?
> > * Have you checked the voltage between Q4 (pin 15) of the HCT573 and pin 10
> >   of the parallel port to ensure that it's between 0-0.8V for low and above
> >   2.0V for high?
> >
> > Note that the voltages are critical because if they are not above the required
> > thresholds, then you won't get the desired effect.
> >
> > I think I'm going to start working on a TLVP debugging floppy/iso using
> > picprg2.3e. One thing I think that both FPP and picprg are missing is the
> > ability to sigle step through the programming process. Because then I would
> > suggest verifying each step during a live programming session so that you can
> > see using the DVM what's actually going on.
> >
> > Don't rewire again. Changing for change's sake isn't going to help. Take one
> > more crack at configuring FPP while I try to get a simple floppy/iso image
> > together that can facilitate debugging the programmer.
> >
> > We will get this thing working. We must!
> >
> > Again I am deeply sorry at your frustration. I will do my best to help you get
> > it working.
> >
> > BAJ
> >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > mailto:piclist-unsubscribe-request@mitvma.mit.edu
> >
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu