Create ICSP Programmer for Embedded Micro Controller Chips

[+mytek]

I started talking about this over in the TK-II thread and thought it best to create its own thread. So my thinking is to possibly create an ICSP (In Circuit Serial Programmer) for a specific PIC micro controller chip made by Microchip, and using the Atari 8 as the actual programmer to re-flash the PIC device. So to see what is involved check out this diagram (courtesy: www.learningaboutelectronics.com).

 

 

So imagine if you will that what is shown as the PIC Programmer, would be interfaced to the joystick port on the Atari 8, with one exception, that being a means of generating the higher Vpp voltage to initiate programming mode. For the specific PIC I have in mind (PIC16F1847), Vpp would need to be 9 VDC (older PICs require 13 VDC). There are Charge Pump IC's that'll double the 5 V available at the Joystick port, and Maxim is one of the manufacturers of just such a device (MAX1682/1683).

 

 

These are good for about 98% conversion efficiency so the output should yield about 9.75 VDC. If that output is then switched by a transistor via a joystick I/O pin, that should bring us very close to 9 V factoring in the semiconductor losses of the switching transistor (example below).

 

 

 

Besides this little bit of circuitry, everything else can be a direct connect to the joystick pins, thus keeping the hardware end of this project ultra simple (substitute a 9 V battery for the charge pump and it gets even simpler).

 

So it appears that the hardware requirements are rather easily met, what about the ICSP programming (flashing) software?

 

Well the nice thing is that the HEX files generated by most all of the PIC compilers is an ASCII coded file, and it contains all of the parameters required by the chip, including what are called configuration bit or fuse settings. At this time I don't totally understand the protocol requirements when sending this data to the PIC chip, but when I dive into this project later, hopefully I wont find it too difficult to understand for implementation from the Atari point of view.

 

 

Some Reference Material:

 

Microchip In Circuit Serial Programming Guide

Microchip PIC16F1847 Memory Programming Specification

 

- Michael

Edited December 23, 2015 by mytekcontrols

[Stephen J. Carden]

I started talking about this over in the TK-II thread and thought it best to create its own thread. So my thinking is to possibly create an ICSP (In Circuit Serial Programmer) for a specific PIC micro controller chip made by Microchip, and using the Atari 8 as the actual programmer to re-flash the PIC device. So to see what is involved check out this diagram (courtesy: www.learningaboutelectronics.com).

 

 

So imagine if you will that what is shown as the PIC Programmer, would be interfaced to the joystick port on the Atari 8, with one exception, that being a means of generating the higher Vpp voltage to initiate programming mode. For the specific PIC I have in mind (PIC16F1847), Vpp would need to be 9 VDC (older PICs require 13 VDC). There are Charge Pump IC's that'll double the 5 V available at the Joystick port, and Maxim is one of the manufacturers of just such a device (MAX1682/1683).

 

 

These are good for about 98% conversion efficiency so the output should yield about 9.75 VDC. If that output is then switched by a transistor via a joystick I/O pin, that should bring us very close to 9 V factoring in the semiconductor losses of the switching transistor (example below).

 

 

 

Besides this little bit of circuitry, everything else can be a direct connect to the joystick pins, thus keeping the hardware end of this project ultra simple (substitute a 9 V battery for the charge pump and it gets even simpler).

 

So it appears that the hardware requirements are rather easily met, what about the ICSP programming (flashing) software?

 

Well the nice thing is that the HEX files generated by most all of the PIC compilers is an ASCII coded file, and it contains all of the parameters required by the chip, including what are called configuration bit or fuse settings. At this time I don't totally understand the protocol requirements when sending this data to the PIC chip, but when I dive into this project later, hopefully I wont find it to be too difficult to understand and implement this from the Atari point of view.

 

 

Some Reference Material:

 

Microchip In Circuit Serial Programming Guide

Microchip PIC16F1847 Memory Programming Specification

 

- Michael

 

 

Way cool Idea Michael!!! I want to be your tester on this project! I would love to see this work!!!

[+mytek]

 

Way cool Idea Michael!!! I want to be your tester on this project! I would love to see this work!!!

 

Yeah I figure this would be a cool project as well, and what better place to start then by making a programmer that could program the TK-II chips. Assuming this can be made to work, all kinds of possibilities exist to expand this into use for other micro controllers, although the Vpp requirements might need to change dependent on the chip requirements (perhaps add an additional Charge Pump?).

 

- Michael

[Stephen J. Carden]

 

Yeah I figure this would be a cool project as well, and what better place to start then by making a programmer that could program the TK-II chips. Assuming this can be made to work, all kinds of possibilities exist to expand this into use for other micro controllers, although the Vpp requirements might need to change dependent on the chip requirements (perhaps add an additional Charge Pump?).

 

- Michael

 

Hi Michael!

Most of the logic chips I have used lately a 16v8 handles the logic I have used and I have a hardware project that would work out great with an ISP Logic chip. Once the basic ISP Chip is picked and a basic circuit for programing is designed and built the ISP and Programing Circuit could be ported to a lot of things. This would be the next big jump for the Atari hardware design.

 

Take Care! Way Cool Idea!

Stephen J. Carden

 

http://www.realdos.net

[ricortes]

Is there a reason you are going PIC over AVR?

[+mytek]

Is there a reason you are going PIC over AVR?

 

Because before there even was an AVR, I started learning to program PIC chips, and I guess old habits die hard. Of course in this forum I could ask "is there any reason you are going Atari 8 over C64?". It just comes down to what a person is comfortable with, and/or finds better for their uses. I have nothing against AVR's, and can see the advantages, but a person only has so much time on their hands (or in their life). However if this works, there is no reason that it couldn't be adapted to AVR's as well. Look at the key words I chose and the lack of a specific chip type in this thread's title, and you will see that I left this open.

 

- Michael

[dmsc]

Hi!,

 

I started talking about this over in the TK-II thread and thought it best to create its own thread. So my thinking is to possibly create an ICSP (In Circuit Serial Programmer) for a specific PIC micro controller chip made by Microchip, and using the Atari 8 as the actual programmer to re-flash the PIC device. So to see what is involved check out this diagram

What is the exact PIC model that you plan to program?

 

Most newer PIC support low-voltage-programming (LVP), to program those you only need 5V, so it is more simple that the shown (the PIC16F690 is too old).

 

As you need only 4 pins to program a PIC using ICSP, and newer PICs work from 2V onward, I think that simply connecting the pins to the four joystick inputs should be enough,

 

....

Well the nice thing is that the HEX files generated by most all of the PIC compilers is an ASCII coded file, and it contains all of the parameters required by the chip, including what are called configuration bit or fuse settings. At this time I don't totally understand the protocol requirements when sending this data to the PIC chip, but when I dive into this project later, hopefully I wont find it too difficult to understand for implementation from the Atari point of view.

 

Some Reference Material:

Microchip PIC16F1847 Memory Programming Specification

There it is the full protocol, should be straightforward to implement.

[+bob1200xl]

The data sheet shows a Vpp range of 8 - 9 volts, min 8v and max 9v (Vihh in the spec). I wouldn't get too far out of this range. It may work on most systems, but cause nasty bugs on a few.

 

Bob

 

 

 

I started talking about this over in the TK-II thread and thought it best to create its own thread. So my thinking is to possibly create an ICSP (In Circuit Serial Programmer) for a specific PIC micro controller chip made by Microchip, and using the Atari 8 as the actual programmer to re-flash the PIC device. So to see what is involved check out this diagram (courtesy: www.learningaboutelectronics.com).

 

 

So imagine if you will that what is shown as the PIC Programmer, would be interfaced to the joystick port on the Atari 8, with one exception, that being a means of generating the higher Vpp voltage to initiate programming mode. For the specific PIC I have in mind (PIC16F1847), Vpp would need to be 9 VDC (older PICs require 13 VDC). There are Charge Pump IC's that'll double the 5 V available at the Joystick port, and Maxim is one of the manufacturers of just such a device (MAX1682/1683).

 

 

These are good for about 98% conversion efficiency so the output should yield about 9.75 VDC. If that output is then switched by a transistor via a joystick I/O pin, that should bring us very close to 9 V factoring in the semiconductor losses of the switching transistor (example below).

 

 

 

Besides this little bit of circuitry, everything else can be a direct connect to the joystick pins, thus keeping the hardware end of this project ultra simple (substitute a 9 V battery for the charge pump and it gets even simpler).

 

So it appears that the hardware requirements are rather easily met, what about the ICSP programming (flashing) software?

 

Well the nice thing is that the HEX files generated by most all of the PIC compilers is an ASCII coded file, and it contains all of the parameters required by the chip, including what are called configuration bit or fuse settings. At this time I don't totally understand the protocol requirements when sending this data to the PIC chip, but when I dive into this project later, hopefully I wont find it too difficult to understand for implementation from the Atari point of view.

 

 

Some Reference Material:

 

Microchip In Circuit Serial Programming Guide

Microchip PIC16F1847 Memory Programming Specification

 

- Michael

[+David_P]

I believe there's a low voltage option for programming that uses only the normal power supply (2.1 to 5.5V).

 

1.1.2 LOW-VOLTAGE ICSP PROGRAMMING In Low-Voltage ICSP™ mode, these devices can be programmed using a single VDD source in the operating range. The MCLR/VPP pin does not have to be brought to a different voltage, but can instead be left at the normal operating voltage.

 

1.1.2.1 Single-Supply ICSP Programming The LVP bit in Configuration Word 2 enables singlesupply (low-voltage) ICSP programming. The LVP bit defaults to a ‘1’ (enabled) from the factory. The LVP bit may only be programmed to ‘0’ by entering the HighVoltage ICSP mode, where the MCLR/VPP pin is raised to VIHH. Once the LVP bit is programmed to a ‘0’, only the High-Voltage ICSP mode is available and only the High-Voltage ICSP mode can be used to program the device.

[+mytek]

Hi!,

 

 

What is the exact PIC model that you plan to program?

 

Most newer PIC support low-voltage-programming (LVP), to program those you only need 5V, so it is more simple that the shown (the PIC16F690 is too old).

 

As you need only 4 pins to program a PIC using ICSP, and newer PICs work from 2V onward, I think that simply connecting the pins to the four joystick inputs should be enough,

 

....

 

There it is the full protocol, should be straightforward to implement.

 

Good point, but I've noticed a lot of negative feedback on-line about using the LVP option. I'll have to verify what the problem is with doing this, and if it's just a bunch of Hoo Hoo then you are correct that this would make things much simpler.

 

 

The data sheet shows a Vpp range of 8 - 9 volts, min 8v and max 9v (Vihh in the spec). I wouldn't get too far out of this range. It may work on most systems, but cause nasty bugs on a few.

 

Bob

 

Good info Bob. The best way to handle this would be to incorporate a suitable zener into the Vpp circuit, and hold it between these two values.

 

 

I believe there's a low voltage option for programming that uses only the normal power supply (2.1 to 5.5V).

 

 

Dmsc brought up the same point, and yes it certainly is a possibility.

 

 

Thank you all for your feedback, and it looks like we have suitable interest at making something like this into a reality

 

- Michael

 

 

BTW; the PIC16F690 was not my choice, it just happened to be on the image I pasted into this thread. My first choice is to program a PIC16F1847.

Edited December 24, 2015 by mytekcontrols

[+mytek]

Some Reference Material:

Microchip PIC16F1847 Memory Programming Specification

 

There it is the full protocol, should be straightforward to implement.

 

I just caught this. Yes if and when I really take the time to read it completely instead of just skimming through it, you are probably 100% correct

 

But if it is truly "straightforward to implement" then I guess someone else will beat me to it, and I'll wake up tomorrow and all the work will be done

 

What I've discovered in all my years, is that when something is assumed to be easy, it rarely ever is. Which is unfortunate, but none the less true a good percentage of the time. But just so you know, I do understand what you meant, and hopefully it will be relatively easy.

 

- Michael

[_The Doctor__]

Nothing wrong with trying to support full and low voltage programming, you never know when you would need one or the other..... as often is the case in this brave new retro world....

[+mytek]

Nothing wrong with trying to support full and low voltage programming, you never know when you would need one or the other..... as often is the case in this brave new retro world....

Yep I think HV programming needs to be retained. Because after reading the section that David_P quoted, it appears that high Vpp programming is required to change the state of the LVP bit in the PIC. So if it were previously cleared, low voltage programming would no longer be an option. And since you can't change this while Vpp is at logic level (5V), you would be SOL.

 

- Michael

[HiassofT]

What I've discovered in all my years, is that when something is assumed to be easy, it rarely ever is.

This is so true, so I thought I'd better warn you about a possible gotcha: the heavy lowpass filtering on the joystick port lines will be killing signal edges.

 

About a decade ago we had a similar idea: build a simple 4-wire joystick port cable that plugs into the JTAG port of the TurboFreezer 2005 so people can easily program logic updates into the Lattice CPLD.

 

Everything worked just fine, but only if we connected the cables directly to the PIA pins. Using the pins on the joystick port resulted in all sorts of errors.

 

Back then I didn't have a scope so I just did some ballpark calculations and IIRC the lowpass filter resulted in edges somewhere in the microsecond range, not nanosecond range as required by the chip. IIRC I also tried regenerating the edges somewhat by adding schmitt triggers but that didn't quite help either.

 

I didn't investigate this further, for one the goal was to create a very simple and cheap cable that we could just ship out together with the TurboFreezer at almost no additional cost. Having neither a scope nor a logic analyzer wasn't making things easier so I gave up on this.

 

so long,

 

Hias

[+mytek]

Great info Hias, and something I never even considered. I'll have to look at what the timing window looks like for the PIC and see if it would support slower clock and data rates. If it's anything like the PS/2 serial connection, so long as the data is stable before the clock toggles, all is well. Of course PS/2 serial Host-to-Device protocol has no timeout, so you can take all the time you need. The same is likely not true for the PIC programming protocol, although I seem to recall that there are data latches within the chip, so it might be made to work (have to dig into this a bit more to know).

 

Anyway thanks again for pointing out this potential problem.

 

- Michael

Edited December 24, 2015 by mytekcontrols

[HiassofT]

I'll have to look at what the timing window looks like for the PIC and see if it would support slower clock and data rates. If it's anything like the PS/2 serial connection, so long as the data is stable before the clock toggles, all is well.

Back then I hadn't thought about possible signal-edge issues either.

 

One of the key issues is that we absolutely have to meet the rise/fall time specs of the clock signal, if we violate them we'll get false/multiple clocking - this is true for all clocked circuits.

 

If a signal transitions too slowly the receiver side usually will see alternating low/high signals when the input is around the switching point - due to signal noise, internal effects of the input implementation etc.

 

This can be really bad, not only the chip might see more than the single edge you are expecting, in addition to that you'll also be violating minimum signal duration / cycle time constraints - the chip might have a minimum clock cycle time of a few 10 or 100ns, but the clock's jumping between lo and hi every vew ns. Ouch.

 

Yeah, electronic books tell you about all that but sometimes you must run into those issues by yourself until you recognize their importance - BTDT several times, I guess this is called learning :-)

 

BTW: a very simple test is to hook up a RC circuit, like you often use for power-on-reset generation, to a digital input that's not a schmitt-trigger and then check both the input signal and the signal seen by the chip (bring out the signal to a spare pin of your PLD or just watch the output of the 74xx chip) with your scope.

 

The input will be slowly ramping up from 0V to VCC as set by the time constant of the RC circuit. The output will be a stable low until the switching point, then jumping between lo/hi around the switching point for some time and stable high afterwards. This can upset some chips, BTDT as well

 

so long,

 

Hias

[+mytek]

Hias these are all very good and excellent points you bring up. Thanks again for doing so.

 

On a slightly different topic...

 

I discovered one other consequence of utilizing the Low Voltage Programming method, and that is with the PIC16F1847 (as well as others) you lose the I/O function for the MCLR pin.

 

While in Low-Voltage ICSP mode, MCLR

is always enabled, regardless of the
MCLRE bit, and the port pin can no longer
be used as a general purpose input.

 

With the approach taken in TK-II I needed every bit of I/O the chip had to offer. So this seals the deal for me, and that is to utilize the High Voltage Vpp programming method. Of course this assumes that using the joystick pins will even work properly.

 

- Michael

Edited December 24, 2015 by mytekcontrols

[Kyle22]

Removing the capacitors on the PIA port should help the signal. We do it all the time on the SIO port to support high speed.

[+mytek]

Removing the capacitors on the PIA port should help the signal. We do it all the time on the SIO port to support high speed.

 

Good suggestion Kyle, but first I'll see if I can get something working with the stock set-up. I have no doubt that with the caps removed it'll work fine, but it would be nice to not have to modify anything.

 

- Michael

[+bob1200xl]

The PIC inputs are Schmitt triggers, so you have a lot of hysteresis working for you.

 

Aren't they? (they better be...)

 

Bob

[dmsc]

Hi!,

 

But if it is truly "straightforward to implement" then I guess someone else will beat me to it, and I'll wake up tomorrow and all the work will be done

Well, I made a little test using a simple diode network to generate the VPP voltage, and implemented a little test program.

 

This is my test circuit:

 

The test setup was this:

 

As you see from the schematic, the programming protocol needs controlling VDD, so I used one output as VDD to the PIC. This was a problem, as the PIC consumes too much current during programming.

 

This is a trace of the full programming start:

 

The dark blue trace is VPP, it goes up to 9.8V (enough to enter programming mode), the pink trace is VDD, I added a big capacitor so the voltage raises slowly to 3.2V (the diode limits the voltage), but the PIC does not enter programming mode always. This is a trace of the times where the PIC does not appears to be responding:

 

But, sometimes the PIC responds and then VDD lowers too much, see this:

 

There are actually changes in the DATA line (the yellow trace) from the PIC, so it must be responding. But VDD lowers to 1.4V, ruining the communication.

 

I think that with a proper power source and a couple of transistors this could work.

 

Attached is the source code of the test program that tries reading the first 128 program words from the PIC.

outport.asm

[+mytek]

The PIC inputs are Schmitt triggers, so you have a lot of hysteresis working for you.

 

Aren't they? (they better be...)

 

Bob

 

Yes they are

 

 

Dmsc all I can say is WOW and thank you

 

Yeah no surprise that the VDD requirements exceeded what that circuit could do, especially considering that it was derived from an I/O pin. Any reason that you didn't just tie it to +5V (pin 7) on the joystick port? There is a programming mode that supports Vdd being present, before Vpp, and this is also the way I program one of my boards which has an ICSP connection. So there should be no need to switch this On & Off. Looks like Vpp stays steady, so the Mclr/Vpp pin is strictly sensing and not pulling any current (nice).

 

My week is a bit hectic coming up, so it'll be a few days until I get a chance to check out that code, and I'll also want to set up my own test circuit as well. What assembler was used?

 

BTW, Great job!

 

- Michael

Edited December 28, 2015 by mytekcontrols

[dmsc]

Hi!,

 

Dmsc all I can say is WOW and thank you

 

Yeah no surprise that the VDD requirements exceeded what that circuit could do, especially considering that it was derived from an I/O pin. Any reason that you didn't just tie it to +5V (pin 7) on the joystick port?

Well, I'm using an old joystick cable that only has 6 pins wired :-)

 

There is a programming mode that supports Vdd being present, before Vpp, and this is also the way I program one of my boards which has an ICSP connection. So there should be no need to switch this On & Off. Looks like Vpp stays steady, so the Mclr/Vpp pin is strictly sensing and not pulling any current (nice).

I'm testing with a PIC12F675, so I read the programming specifications from http://ww1.microchip.com/downloads/en/DeviceDoc/41191D.pdfand I was following figure 2-2, that shows VDD *after* VPP. I tried leaving VDD always on and it didn't read anything from the PIC...

 

I now tried using a 2N2907 transistor in the VDD line and it seems that I can read the chip.... tomorrow I will try further.

 

 

What assembler was used?

MADS, but the code does not use any macros, so any assembler will do.

[+mytek]

OK here is what I found pertaining to the two High Voltage Program and Verify modes Entry and Exit (From: Microchip PIC16F1847 Memory Programming Specification Section 4.x).

VPP – FIRST ENTRY MODE

To enter Program/Verify mode via the VPP -first method
the following sequence must be followed:

1. Hold ICSPCLK and ICSPDAT low. All other pins
   should be unpowered.
2. Raise the voltage on MCLR from 0V to VIHH.
3. Raise the voltage on VDD FROM 0V to the
   desired operating voltage.

The VPP -first entry prevents the device from executing
code prior to entering Program/Verify mode. For
example, when Configuration Word 1 has MCLR
disabled (MCLRE = 0), the power-up time is disabled
(PWRTE = 0), the internal oscillator is selected
(FOSC = 100), and ICSPCLK and ICSPDAT pins are
driven by the user application, the device will execute
code. Since this may prevent entry, VPP -first entry
mode is strongly recommended. See the timing
diagram in Figure 8-2.

VDD – FIRST ENTRY MODE

To enter Program/Verify mode via the VDD -first method
the following sequence must be followed:

1. Hold ICSPCLK and ICSPDAT low.
2. Raise the voltage on VDD from 0V to the desired
   operating voltage.
3. Raise the voltage on MCLR from VDD or below
   to VIHH .

The VDD -first method is useful when programming the
device when VDD is already applied, for it is not
necessary to disconnect VDD to enter Program/Verify
mode. See the timing diagram in Figure 8-1.

PROGRAM/VERIFY MODE EXIT

To exit Program/Verify mode take MCLR to VDD or
lower (VIL). See Figures 8-3 and 8-4.

- Michael

Edited December 28, 2015 by mytekcontrols

[dmsc]

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:

 

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

 

And this is a photo of the circuit:

 

Attached is my source code.

outport.asm