Create ICSP Programmer for Embedded Micro Controller Chips

[ricortes]

+1 to Hias's comment. I once built an EPROM programmer that hung off a single J/S port. I strung three 74LS164 end to end to generate 16 bits of address and 8 bits of data. Damn thing never worked right so I put LEDs on the first 74LS164. It turned out a single clock transition would clock out 1-4 bits of data.

[+mytek]

Hi!,

 

I finally was able to read the device ID from my PIC, I used a transistor to control VDD. I think that my test PIC does not support the VPP after VDD method, as it is an 8 pin device.

 

This is the final circuit:

atari-pic-prog.v2.png

 

This is a screenshot from my monitor showing that the program correctly reads the device id "0FCB":

atari-pic-prog-demo.jpg

 

And this is a photo of the circuit:

atari-pic-prog.v2.jpg

 

Attached is my source code.

 

Dang !! My work place is unfortunately in a shambles (doing a complete tear-down and rebuild), otherwise I would hop right on this and start playing around with what you have done thus far (I love where this is heading). I originally started this topic more as a placeholder for something I really wanted to experiment with down the road, knowing all too well that right now wasn't good for me. When the time is right, you'll probably have the bulk of it done (which I really don't mind). And just so you know, I am very happy that you stepped up to this challenge, and have been making remarkable progress.

 

So it'll be interesting to see if the RC networks on the joystick pins really becomes a problem or not as far as reliability is concerned. But even if it does, Kyle's idea of removing the caps sounds like a good solution for that.

 

- Michael

Edited December 29, 2015 by mytekcontrols

[+mytek]

+1 to Hias's comment. I once built an EPROM programmer that hung off a single J/S port. I strung three 74LS164 end to end to generate 16 bits of address and 8 bits of data. Damn thing never worked right so I put LEDs on the first 74LS164. It turned out a single clock transition would clock out 1-4 bits of data.

 

Ouch! that doesn't sound good at all. But it looks like dmsc is getting better results than that. This can likely be attributed to the Schmidt trigger inputs on the PIC's I/O. Still doesn't mean there won't be a problem as Hias pointed out, but so far so good.

 

- Michael

[lemiel]

When I was using joysticks ports for parallel printer cable it started to work after I add 2,2k pull-up(?) resistors connected to +5V to each line. But this written by all of you earlier in this topic is beyond my knowledge.

[dmsc]

Hi!,

 

Dang !! My work place is unfortunately in a shambles (doing a complete tear-down and rebuild), otherwise I would hop right on this and start playing around with what you have done thus far (I love where this is heading). I originally started this topic more as a placeholder for something I really wanted to experiment with down the road, knowing all too well that right now wasn't good for me. When the time is right, you'll probably have the bulk of it done (which I really don't mind). And just so you know, I am very happy that you stepped up to this challenge, and have been making remarkable progress.

 

So it'll be interesting to see if the RC networks on the joystick pins really becomes a problem or not as far as reliability is concerned. But even if it does, Kyle's idea of removing the caps sounds like a good solution for that.

Before starting, I measured the rise and fall times of the signals on the port, (24us +/- 0.5us) rise time and (0.7us +/- 0.03us) fall time. The imbalance is because this is the output of an NMOS gate.

 

Fortunately, newer logic process (like the PIC inputs) are of very low input current and tolerate a fair amount of variability in voltages, also the PIC outputs are of very low impedance, much better than the Atari ones, so they have good compatibility.

 

Also, the PIC programming protocol is an SPI like communication with the clock input smith-triggered, so by limiting the speed (by adding a sta WSYNC before all clock changes) it is easy to guarantee that the data is stable before the clock toggles. Also, I think that there is no timeouts in the protocol, so the programming can be as slow as needed.

 

In the trace bellow, you can see that a "read from program memory" command takes 4ms, followed by a "increment address" command taking 1ms, so we can read the PIC at 5ms per program word (14bits in this PIC):

 

 

You can see that my first clock pulse (yellow trace) is shorter than the rest, this is because I made the mistake of writing to the port first and then to WSYNC, this must be reversed to generate clock pulses of equal width. The first 6 clock pulses are the command sent to the pic (read program memory), then the next 16 pulses are a start bit, 14 bits read from the PIC and 1 stop bit.

 

Afterwards, there are 6 clock pulses for the next command (increment address), and the cycle repeats again reading the next word.

 

Note that when the PIC drives the input (the 14 data bits), the data signal (cyan trace) is more clean than before and swings wider than the Atari signal.

 

Also, in the zoomed out portion of the trace at the top, you can see the VPP (blue trace) rising from 5V to 10V in about 40ms, then VDD (ping trace) goes from 0V to 5V and the VPP value lowers a little and stabilizes at 8.8V.

 

As I don't have newer PICs (like yours PIC16F1847) I can't test if the "VPP after VDD" programming method could work, and also I don't know if my routines will work, but should based on the programming specification.

 

Note that supporting more than one kind of PIC is difficult as the location of the "configuration word" changes in the HEX file, in my pic is at address $2007, but in yours is at address $8007 and $8008.

[Kyle22]

How about adding the option to select a PIC from a list. Include a small updateable! database in the program with the location of the configuration word for each type of PIC.

[+mytek]

As I don't have newer PICs (like yours PIC16F1847) I can't test if the "VPP after VDD" programming method could work, and also I don't know if my routines will work, but should based on the programming specification.

 

Note that supporting more than one kind of PIC is difficult as the location of the "configuration word" changes in the HEX file, in my pic is at address $2007, but in yours is at address $8007 and $8008.

 

Send me your address via PM, and I'll mail you a few to play with, and I'll also throw one in that is pre-programmed with the latest TK-II firmware. And yes I know you are in the other America, but since the package will be small and lightweight it shouldn't be too bad postage wise. This is worth it to me, since you are obviously adding a lot to this project.

 

 

How about adding the option to select a PIC from a list. Include a small updateable! database in the program with the location of the configuration word for each type of PIC.

 

This isn't a bad idea, and since there are so many variations it would be good to have it in an easily updated "include" file separate from the mainline code. This is how they do in some of the other chip flashing incarnations. Probably best to only support the newer "9V" Vpp devices just to keep the hardware simple as has been done thus far.

 

Its all good

 

- Michael

[dmsc]

Hi!,

 

In the meantime, I updated my program to correctly read all the areas of the PIC and advance through addresses, this is current screenshot:

 

Attached is the source and a booteable ATR with the compiled program.

 

To try the program with a real PIC, use the circuit from my previous post (attached here also), the components needed are:

- 4 diodes 1N4148 or similar.

- 5 capacitors 0.1uF.

- 1 capacitor 1uF (optional, can be left out)

- 1 transistor 2N2907 (or other PNP).

- 1 resistor 1k

 

Next step, try programming some data to the PIC

picprog.asm

picprog.atr

[+mytek]

It just keeps getting better

 

- Michael

[dmsc]

Hi!

 

Well, it was longer than I tough, but I finally could program my PICs (16F690 and 12F675) from the Atari.

 

I made two programs:

- picprog.asm / picprog.com : This is the programming software, reads a "script" with programming instructions from memory, blanks the PIC, programs and verifies all. This does not works alone, as the script must be created before.

- readhex.c / readhex.com : A C program (compile with CC65, "cl65 -tatari readhex.c -o readhex.com") that reads a .HEX file, asks for the PIC model, reads from disk the PICPROG.COM base and writes a new .COM capable of programming the given PIC.

 

Attached are a ZIP with the sources and binaries, and an ATR image with BWDOS, binaries and a sample program for a PIC16F690.

 

Usage:

 

From the bwdos prompt, type:

READHEX SAMPLE.HEX SAMPLE.COM

Now, you see a prompt with the available PIC models. Select the one you wand by entering the number and RETURN.

 

This takes a while, reading "SAMPLE.HEX", the including "PICPROG.COM" and producing "SAMPLE.COM". If you omit the output name in the command line, the default is the same as input with ".COM" instead of any existing extension. If you omit both parameters, the program asks for the input HEX file name.

 

After the end, press RETURN to return to DOS.

 

Now, you have in the disk a new binary, run it to program the PIC:

 

SAMPLE

Now, pressing START begins the programming. The background color flashes to indicate progress.

 

The programming is a little slow, because I have limited the speed to one WSYNC per clock transition, this is about 7.7kbaud, and the programming protocol takes 28bits for each word plus 3ms of "programming time", so 2kword of PIC memory should take about 15 seconds.

 

Hardware:

 

This is the current hardware:

 

I added a transistor at the output of the VPP signal, as the PIC16F690 consumes more current from the VPP input, also added a 2k2 resistor from the DATA line to the PIC, this makes the programming much more reliable, and an optional zener diode to limit the VPP voltage. This is specially important if you want to program newer PIC that don't tolerate more than 10V at VPP input.

picprog.atr

atari-picprog-v4.zip

[Van]

WOW! Truly brilliant This totally seems like a Ciarcia's Circuit Cellar project from a '80s issue of Byte , too cool.

Yogi

[+mytek]

Wow and double wow!! Now I have to get some parts on order and give this a try. This is truly incredible, very inexpensive, and simply amazing that this can be done with a stock unmodified Atari 8 system without even cracking the lid. I wish we still had an electronic parts store besides Radio Shack in our town, although I will give them a try tomorrow to see what they have in stock (the zeners might be a problem, but the other stuff they certainly should have).

 

Thanks dmsc for all your hard work ☺

[+mytek]

 

...and an optional zener diode to limit the VPP voltage.

 

I see the Zener diode is specified as 12 V. This doesn't seem to match the required Vpp of either PIC family (9 or 13 V). Am I missing something?

 

- Michael

[dmsc]

Hi!,

 

I see the Zener diode is specified as 12 V. This doesn't seem to match the required Vpp of either PIC family (9 or 13 V). Am I missing something?

Yes, that was the only zener that I have in my component box, but a specific value for each PIC variant should be used

[+mytek]

Yes, that was the only zener that I have in my component box, but a specific value for each PIC variant should be used

 

Got it Jameco p/n 178837 is a 9.1 V zener which should work perfect for the lower Vpp requirements of something like a PIC16F1847. Unfortunately Radio Shack doesn't have anything close to this, but the store in my area does have all the other parts shown in your schematic.

 

- Michael

[dmsc]

Got it Jameco p/n 178837 is a 9.1 V zener which should work perfect for the lower Vpp requirements of something like a PIC16F1847. Unfortunately Radio Shack doesn't have anything close to this, but the store in my area does have all the other parts shown in your schematic.

- Michael

Or perhaps this: http://www.ebay.com/itm/10-x-1N4740A-1N4740-Zener-Diode-10V-1W-SALE-Good-quality-/180815543490????

 

I would use multiple zeners (or diode + zener) in series to match the voltage, perhaps then you will find parts available locally.

Edited January 6, 2016 by dmsc

[+mytek]

Or perhaps this: http://www.ebay.com/itm/10-x-1N4740A-1N4740-Zener-Diode-10V-1W-SALE-Good-quality-/180815543490????

 

I would use multiple zeners (or diode + zener) in series to match the voltage, perhaps then you will find parts available locally.

 

I think 10 V is getting too high.

 

Voltage Spec for PIC16F1847:

High voltage on MCLR/VPP for

Program/Verify mode entry = 8.0 - 9.0 V

 

Yep I was originally thinking about using two 5 V zeners since that is what Radio Shack had in stock, but then I remembered that 9 V was the maximum recommended Vpp voltage. Several years ago we had a place called HSC which was a surplus electronics store, they had all kinds of zener diodes, as well as a lot of other useful stuff. But now we only have RS as a local source which is pitiful. Anyway I got the 9 V zeners on order from Jameco. Usually stuff gets here within a couple of days.

 

However I have been playing around with the software app, but I must admit that I'm not 100% sure of how to take a PIC hex file and turn it into a form that picprog will utilize. Part of the problem is that I've never used CC65 before, or any other C compiler, so there is a little bit of a learning curve. Presently I think I have a version of CC65 installed on my Linux box, but I'll be darned if I can find where to launch it, or even what it expects. I know there is also a version native to the A8, so maybe that would be a better one to use. Any thoughts?

 

 

- Michael

 

EDIT: Ahh I think I got it figured out, it's a command line parameter that needs to be entered via terminal mode in Linux I may still have some more questions later on.

Edited January 7, 2016 by mytekcontrols

[dmsc]

Hi!,

 

However I have been playing around with the software app, but I must admit that I'm not 100% sure of how to take a PIC hex file and turn it into a form that picprog will utilize. Part of the problem is that I've never used CC65 before, or any other C compiler, so there is a little bit of a learning curve. Presently I think I have a version of CC65 installed on my Linux box, but I'll be darned if I can find where to launch it, or even what it expects. I know there is also a version native to the A8, so maybe that would be a better one to use. Any thoughts?

 

If you use the supplied ATR image, you don't need any other software.

 

Boot the disk in the atari, copy your .hex to the disk and run the supplied program with your hex file as argument, all in the atari.

 

To simplify the copy, I mount the ATR disk in atari800 emulator, running on Linux:

 

atari800 picprog.ATR -H1 path/to/hex/folder/

 

Then, inside the emulator, in the BWDOS prompt, you can copy the hex file:

 

COPY H:myfile.hex D:FILE.HEX

 

(note that the H: device is case sensitive in atari800 emu).

And in the same prompt you can generate the programming code (also inside the emulator)

 

READHEX FILE.HEX PROG.COM

 

Now you have a new "PROG.COM" executable in the disk image, run it in the same prompt:

 

PROG

 

The ATR image can be mounted in a real Atari and booted any time.

 

Hope it is clearer now,

 

Daniel.

[+mytek]

Daniel thanks for the streamlined explanation.

 

I think I got a successful HEX file build using the atari800 emulator and dmsc's new PIC programming utility, although at first I couldn't get BeWe-DOS to COPY a file. Not being familiar with this DOS, and having been away from using A8's for a very long time, I finally figured out that this was an external command and required a file called COPY.COM to be on that ATR disk image (which it wasn't). So I found and downloaded a full version of BeWe-DOS, used makeATR to extract COPY.COM and then inserted that into the picprog.atr. After that success

 

So then I proceeded to use the READHEX program to create a new executable for the latest version (1.4) of TK-II-OS that I copied to the picprog.atr from my Linux hard drive, selecting the PIC16F1847 from the list. It cranked away for quite sometime (big HEX file) and then prompted me to write it to disk which I did. The end result was a new program on the picprog.atr disk I had named TKPROG.COM (I also renamed the picprog.atr to TKprog.atr). Executing this program took me to a prompt to either program the chip (START), or abort to DOS (SELECT). Since I wasn't running on real hardware, I aborted. Daniel has created a pretty slick and easy to use PIC programming application Now I just need to assemble the joystick hardware, and then program a PIC chip for real and see what happens.

 

- Michael

 

I attached the new ATR that contains COPY.COM and my TK-II-OS_V1_4.HEX file build.

TKprog.atr

Edited January 7, 2016 by mytekcontrols

[+mytek]

OK I built the Joystick programmer hardware per the version 4 schematic, and on the first attempt I got "ERROR invalid device ID. Detected $3F43, expected $1480 writing address $0006". Then I believe it was on the 2nd or 3rd attempt the chip started to program (Vdd was 5V, and Vpp was at 9 V without any zener). However it wouldn't complete and would throw another error "ERROR at memory verify...". I could keep hitting START and it would proceed and then throw another similar error, but with a different address each time. it appeared to be trying real hard, but just couldn't make it all the way through the programming process.

 

This first test was with a PIC16F1847 on an XEGS.

 

So I transferred everything over to a 1200XL, and just kept getting the original ID error. So I cut out the capacitors on the joystick input (C74, 75, 83, 84), and tried it again. Same result mismatched ID. Then I went back to XEGS and removed the inductor/capacitor networks and jumpered the joystick connections across where these were. Now when I run the program, all I get is an ID error. Unfortunately I kind of destroyed the inductor/capacitor networks, so there is no putting them back in. Although I can't see how removing them would hurt anything (should be better without, since delays have been eliminated).

 

I went back through the circuit verifying connections and everything checks out fine. Also tried this with 3 different chips. Quite frankly I am stumped as to how I should proceed.

 

- Michael

 

EDIT (SUCCESS!!!!): I got it working Had to add a 2.2K pull-up on the PIC CLK line as well. I've programmed 6 chips in a row on both the modified XEGS (with removed Inductor/Capacitor networks), and on my 1200XL (I restored the capacitors). Programming time is approximately 68 seconds (6477 words). I popped a few of the programmed chips into my TK-II's and everything worked like a champ! As far as I'm concerned, what Daniel has created is absolutely fantastic and appears to be quite reliable with the addition of the extra pull-up resistor. And it also appears that the Vpp is self limited due to the low current available from the voltage tripler circuit, so no zener appears to be required.

 

Yahoo Yipee our Atari's can now program PIC microcontroller chips!!!!!!

Edited January 8, 2016 by mytekcontrols

[+mytek]

OK now that we have a good hardware/software solution, it's time to start thinking about creating a JOY2ICSP PCB. This is where I can add some of my creativity to the project since Daniel has obviously done an excellent job of getting the hardware/software design and development under way. So what I have in mind is to create a very tiny board with an integral D-Sub 9-pin female joystick connector, and an industry standard 6-pin ICSP header. It'll be able to do In Circuit Programming, and/or with the addition of a separate ICSP adapter board, it'll also be able to program a loose unmounted chip.

 

ICSP Adapters

 

I'll present more info as this comes together. Expect to see the PCB boards available from OSH Park in the near future.

 

- Michael

[dmsc]

Hi!

 

Good to see you got it working!!!!

 

:)

 

OK I built the Joystick programmer hardware per the version 4 schematic, and on the first attempt I got "ERROR invalid device ID. Detected $3F43, expected $1480 writing address $0006". Then I believe it was on the 2nd or 3rd attempt the chip started to program (Vdd was 5V, and Vpp was at 9 V without any zener). However it wouldn't complete and would throw another error "ERROR at memory verify...". I could keep hitting START and it would proceed and then throw another similar error, but with a different address each time. it appeared to be trying real hard, but just couldn't make it all the way through the programming process.

 

This first test was with a PIC16F1847 on an XEGS.

I see, I'm trying now with my unmodified 800XL and a PIC16F1936 that I could get and the clock input is less tolerant than in my PIC16F690... I solved the reliability issue by simply adding a 4.7nF capacitor from the clock input in the PIC to ground.

 

Do you still have one unmodified joystick port to try?

 

Now that you succeeded programming a PIC16F1847, I'm confident that we can add support for more "midrange" PICs, to do that you need to edit the C source "readpic.c", adding at line 44 new lines with:

- name : the device name,

- device_id : the device id as HEX, this is from the programming datasheet.

- max_addr : the amount of program memory words in the chip.

- id_addr : the address of the "configuration memory" in the PIC, this is 0x2000 for the old PICs and 0x8000 for the "enhanced midrange" PICs

- last_addr : the last address of configuration memory.

 

Attached is a new version of the C program with my new test PIC added, two new programs to test the programmer, "PICREAD" that reads and displays the PIC, "SETVPP" that generates the VPP voltage allowing to measure with a multimeter.

 

Also, a new ATR image is attached with all the compiled programs and a README at boot, try it!

picprog.atr

picprog-20160107.zip

[+mytek]

Hi Daniel,

 

 

Do you still have one unmodified joystick port to try?

 

Yes I restored the capacitors that I had previously disconnected on the 1200XL, and I was able to do 6 successful burns to 6 different chips. Can't really restore the XEGS, but I have a 2nd one that is still stock so I'll test with that one as well.

 

 

 

..."PICREAD" that reads and displays the PIC, "SETVPP" that generates the VPP voltage allowing to measure with a multimeter.

 

Yes that is what I needed earlier today (thank you).

 

 

 

I see, I'm trying now with my unmodified 800XL and a PIC16F1936 that I could get and the clock input is less tolerant than in my PIC16F690... I solved the reliability issue by simply adding a 4.7nF capacitor from the clock input in the PIC to ground.

 

Did you try adding the 2.2K pull-up on the clock input? This fixed my problems completely.

 

 

 

Also, a new ATR image is attached with all the compiled programs and a README at boot, try it!

 

I will do that, thank you .

 

- Michael

 

EDIT: Just checked it out in atari800 emulator. I like the added ReadMe at boot, very nice. Also adding the PIC16F1936 to the device list is a good choice, since it shares many common traits with the PIC16F1847, but gives you a lot more I/O. Great stuff

Edited January 8, 2016 by mytekcontrols

[+mytek]

 

"SETVPP" that generates the VPP voltage allowing to measure with a multimeter.

 

My SETVPP results:

 

No Chip (no load) = 13.55 V

w/PIC16F1847 Chip = 9.0V

 

These results really lead me to believe that the chip internally clamps the voltage (perhaps internal zener). What do you see with the PIC16F1936, 12F675, or PIC16F690?

 

If this is the case, then no hardware configuration such as in switching in or out zeners will be required (which would be great).

 

- Michael

[+bob1200xl]

More likely the junction breaking down. You might want to measure Vpp with a scope rather than a meter. Measure it while it is programming, since that is when the Vpp would be loaded.

 

There does not seem to be any chip parameter that addresses the source impedance of the Vpp voltage, just the voltage level. So, if you had a zener on the input in the chip itself, there would be no current limiting in force and a very high current could flow into the device (if you supplied it).

 

Something to think on...

 

Bob