Is it alive? Testing a new PIC programmer

Hello all

I'm new to the whole microcontroller scene. I just built, according to a kit (**broken link removed**), a very simple PIC programmer and test board. This was designed for and supplied with a PIC30F84A, which I understand to be and old but faithful member of the PIC family and a suitable starting platform.

Anyway, I built the circuit as per the instructions. Then I ran the (very basic) send program which is supposed to take my assembled program (currently using a supplied example program as advised to) and sends it, via the parallel port, to the PIC. Then the PIC, once brought out of program/verify mode, is supposed to light up a couple of LEDs that are directly wired to its B port.

But... it doesn't. The PIC apparently does nothing. All I/O ports remain low during runtime. Since I'm using a very simple programmer, there's no obvious way I can see to tell where the problem lies - whether it is during the programming or the runtime.

As far as I can tell, the hardware is fine. All solder joints are good and continuity tests show now problems anywhere. Power is being supplied at the appropriate pins. While in program/verify mode, the voltage at MLCR is just shy of 12v, when switched to runtime mode, 5v. There is a RC clock input at the oscillator in pin.

My problem is that I really can't see how to diagnose this problem. I personally suspect the problem lies with the PC's LPT port used for the interface; neither the clock nor data pins used change in the slightest when the program is supposedly being transferred (using an oscilloscope to monitor), they both seem to sit at around 5v, although this might be all I'd be able to see.

There is only one problem I can see at the moment (seems unlikely somehow). The programming voltage is not quite in the 12-14v range. It's hovering at 11.9v, which I figure is close enough... is this a bad assumption? I'm planning to get a more powerful supply tomorrow to push it a little further but I'm not optimistic.

The design is that of EPE magasine 1998. I'm using the "PIC16F84 Programmer" by Derren Crome as my software send program, and I run its PIC configuration wizard, but similarly I have no idea if it's working. I've attached my program listing, I'm wondering if there's a simpler program, but I'm not yet understanding this code and don't feel up to changing it just yet...

Any ideas on how to test and work out what's wrong?

Cheers!

What operating system do you use? XP, 2000?

It's a programmer designed in 1996. The software may not know how to handle the printer port in XP or 2000. (there is a driver out there to allow programs to access the ports in XP or 2000)

Windows 95 & 98 + DOS should be fine.

Yeah, I'm running XP on both machines I've tested with. Think this is a problem? Not sure if I can get my hands on some old stuff though, do you know of a programmer software that's more modern and still works over the printer port? I had a quick look at MPLAB but I couldn't see any way to configure it for a 'generic' programmer like this.

Also, I tried a second power supply and still no joy, ruling out the 11.9v prgram/verify mode problem.

Have a look at This Page. This software supports lots of programmers and can be configured for many more.

Mike.

I'll see if I can find the original article, but (from what I can remember) the Darren Crome programmer published in EPE was rather obscure? - it was like he had never seen a PIC programmer before?, and didn't come up with a very good solution!.

Interestingly enough, EPE hadn't heard of MPASM back then either!, they used a peculiar shareware assembler configured to do PIC's.

We have a heartbeat!

Unfortunately, quite literally; if I understood my program right it was supposed to turn on all the LEDs. It doesn't so much: one blinks, another is on but flickers, and two are off. This is the PIC's output.

Don't get me wrong, this is great! It means my hardware is good and I can start playing around with it! William, you were right, XP was blocking my LPT port. Pommie's WinPIC website made mention of a I/O interface for XP called PortTalk, so I gave that I try first, and lo, light lit.

Nigel Goodwin... that rings a bell - did I see you credited in the EPE archives? A disassembler I think it was?

I see what you're saying about the programmer. Also, it works with .OBJ rather than .HEX which, if I understand right, is the norm. As such, once I feel confident I know what's happening here, I'll switch to winPIC and HEX files. I also like the idea of being able to read back the stored program..

Thanks, guys, I'll keep you posted. As I was saying, this is all new territory for me, so you're sure to see more of me

F*SH said:

Nigel Goodwin... that rings a bell - did I see you credited in the EPE archives? A disassembler I think it was?

Click to expand...

Yes, I wrote them a stand alone DOS version of my PIC disassembler. I also told them about MPASM 8)

I see what you're saying about the programmer. Also, it works with .OBJ rather than .HEX which, if I understand right, is the norm. As such, once I feel confident I know what's happening here, I'll switch to winPIC and HEX files. I also like the idea of being able to read back the stored program.

Click to expand...

Yes, the OBJ files are produced by the strange shareware assembler, you can download a PIC Toolkit from EPE which converts between the two formats, and gives suitable source code for either assembler.

Well, I don't see any real reason compelling to stay with Mr. Crome's programmer and winPIC seems quite capable. I'd prefer to move to this as I think I'll understand it better, and it can provide me with more information about what's going on. That, and converting HEXs into OBJs seems like too much effort to be worth it.

But, of course, winPIC isn't working straight off either. I'm not sure if it's communicating at all. It doesn't seem to be able to initialise the programmer (not sure what this means - in any case I'm guessing this programmer is too simple to need be initialised). Any attempts to write a HEX fail, or at least the verify stage does. However, it does seem to think it can read the PIC's stored program, but I'm pretty sure it can't: it just returns a repeating h0001 pattern. There should at least be 23 words of the program I loaded via Mr. Crome's programmer, which still executes.

There are two problems I can see. First, I'm not sure the parallel port is being used right. winPIC seems to have built-in support for the PortTalk driver as well as something called SMPORT, but I can't see any way of testing to see if they work.
The other thing is that winPIC claims the programmer is not initialised. Not sure what this means, but it suggests to be that winPIC is not seeing the programmer or PIC. I tried to create a new interface definition file but was at a loss to understand the settings do.

Any ideas for troubleshooting?

Addendum:
The parallel port seems functional and correctly configured. When I set the interface mode to "PIC Flash prog by SM6LKM" or "Microchip AN589" and possibly others, the data line stays low but there is a definate if brief voltage deflection up. This shows the physical connection is good.
What is programer initialisation? Is it needed for programming? I ask because the previous programmer didn't seem to require any startup, it just wrote the program...

OK, so I played around further with the interface settings and finally created a simple but apparently working custom interface profile. WinPIC can now read the Data line correctly and can also set both the Data and Clock lines. The other mandatory setting, VppOnOff, I set to a non-used value, as Vpp is hardware-controlled (ie, I flip a switch to rise the MCLR voltage to put the PIc into program/verify mode).

However, verify continues to fail and the read operation seems to think that the PIC is empty ("maybe blank"), which it certainly shouldn't be. Additionally, while a slowed read operation was occurring I was watching the Data line and noticed that the voltage maintained a steady voltage, somwhere right in between high and low (presumably being read as low though, if the device is supposedly empty).

I'm at a loss to explain this. One thing I read that might explain it is Code protection, which, as I understand it, would give me an apparently blank device and so verify would continue to fail. Although now I don't touch the setting due to what I've read about it, there's a good chance I may have enabled it before, not realising what it was. If I have set it on, is there any way to unset it short of buying a new device? Is there any way to test to see if it has been enabled?

F*SH said:

I'm at a loss to explain this. One thing I read that might explain it is Code protection, which, as I understand it, would give me an apparently blank device and so verify would continue to fail. Although now I don't touch the setting due to what I've read about it, there's a good chance I may have enabled it before, not realising what it was. If I have set it on, is there any way to unset it short of buying a new device? Is there any way to test to see if it has been enabled?

Click to expand...

The configuration fuses are erased each time you program the PIC, to test if it's set simply read the contents, the fuses read as normal, so you can see if it's set.

I've been doing a little checking, the original Darren Chrome design was published in Feburary 1996, but there was a PIC Toolkit published in 1998. I've found the 98 article, but not the 96 one - the 96 one used a DOS program called 'Send' to progrm the PIC, and (from what I can remember) the hardware didn't support reading the PIC?.

Can you scan and post the circuit?.

Hmm, can't scan it but attached shows what I've got built. A very simple programmer, as you can see, with 4 LED outputs in the B port I'm using for testing.

You're right about 'send.exe'. All it can do is load the program and configuration word. No reading or verfiying, but I assumed that was a limitation of the software, not the of the hardware, as I figured the data/clock lines worked in both directions.

F*SH said:

You're right about 'send.exe'. All it can do is load the program and configuration word. No reading or verfiying, but I assumed that was a limitation of the software, not the of the hardware, as I figured the data/clock lines worked in both directions.

Click to expand...

The pins on a standard parallel port are either an input, or an output, but can't be both - so with the data pin of the PIC connected to an output you can only write the chip, and not read or verify it.

Modern parallel ports do have various bi-directional facilities, but I've not seen a PIC programmer that uses them - no point, as proper hardware design prevents it being required.

Ah, I see.

The 'easy' solution to this as I see it would be to simply connect the data line to a second, opposite direction, parallel pin. Would this work or would I need to start using diodes and the like to prevent conflicts?

This would explain why I can't read or verify, but I'm pretty sure I also can't write. I say this because I'm trying to load some of your tutorial programs but none seem to do anything. Rather, it continues to execute the program I loaded way back with the programmer described in EPE...

F*SH said:

Ah, I see.

The 'easy' solution to this as I see it would be to simply connect the data line to a second, opposite direction, parallel pin. Would this work or would I need to start using diodes and the like to prevent conflicts?

Click to expand...

You need to isolate the connections, it's usual to use an open-collector buffer between the output of the port and the input of the PIC, along with a pull-up resistor. When this buffer is turned OFF the data line is free to work the other way.

This would explain why I can't read or verify, but I'm pretty sure I also can't write. I say this because I'm trying to load some of your tutorial programs but none seem to do anything. Rather, it continues to execute the program I loaded way back with the programmer described in EPE...

Click to expand...

Assuming you're using WinPic, it sounds like it's not working properly?.

Ah yes of course. Shouldn't be hard to modify my circuit to do this as soon as I can get my hands on a pair of buffers. However, that's going to be several days, and I imagine I can get started with the programming without being able to read the controller.

Yeah, I'm using WinPIC, and something doesn't seem to be working.The hardware between the PIC and the winPIC seems good and I can manipulate the voltage at the data and clock pins via the interface test in the software. So the problem in my mind lies either with the PIC or winPIC and its configuration. Even the 'erase' command doesn't: after one, I've still got an LED connected to the B3 port lit - the function of the previous program that is apparently still loaded in memory.

Unfortunately I've not got another PIC lying around to be able to test the PIC for fault, but I can't see any reason it would be damaged. I've taken good care of it so far and we know it works at least partially. So I'm thinking I've misconfigured winPIC, which also strikes me as odd considering the apparent success of low-level communications.

F*SH said:

Ah yes of course. Shouldn't be hard to modify my circuit to do this as soon as I can get my hands on a pair of buffers. However, that's going to be several days, and I imagine I can get started with the programming without being able to read the controller.

Click to expand...

All you need for a buffer is an NPN transistor and two resistors, one as a collector pull-up, the other as a current limiter feeding the base.

Picprogrammers usually switch both Vdd and Vpp by software, that programmer does neither, which could well be a problem. The software usually verifies as it goes as well, and this will obviously fail as there's no reading possible.