Jump to content

Photo

Create ICSP Programmer for Embedded Micro Controller Chips

PIC Atmel AVR Arduino Micro Controllers ICSP

177 replies to this topic

#26 ricortes OFFLINE  

ricortes

    Dragonstomper

  • 606 posts

Posted Mon Dec 28, 2015 6:49 PM

+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.



#27 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Mon Dec 28, 2015 9:55 PM

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:
attachicon.gifatari-pic-prog.v2.png

This is a screenshot from my monitor showing that the program correctly reads the device id "0FCB":
attachicon.gifatari-pic-prog-demo.jpg

And this is a photo of the circuit:
attachicon.gifatari-pic-prog.v2.jpg

Attached is my source code.

 

Dang :mad: !! 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  :grin: 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 by mytekcontrols, Mon Dec 28, 2015 9:56 PM.


#28 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Mon Dec 28, 2015 9:59 PM

+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



#29 lemiel OFFLINE  

lemiel

    Chopper Commander

  • 231 posts
  • Location:Tychy, Poland

Posted Tue Dec 29, 2015 1:17 AM

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. ;)

#30 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Tue Dec 29, 2015 6:11 PM

Hi!,
 

Dang :mad: !! 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  :grin: 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):

DS1Z_QuickPrint17.png

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.

#31 Kyle22 OFFLINE  

Kyle22

    River Patroller

  • 3,136 posts
  • Location:McKees Rocks (Pittsburgh), PA

Posted Tue Dec 29, 2015 7:35 PM

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.



#32 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Tue Dec 29, 2015 8:03 PM

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  :grin:

 

- Michael



#33 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Tue Dec 29, 2015 9:19 PM

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:
atari-pic-prog-v3.jpg

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 :)

Attached Thumbnails

  • atari-pic-prog.v2.png

Attached Files



#34 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Tue Dec 29, 2015 10:21 PM

It just keeps getting better  ;-)

 

- Michael



#35 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Tue Jan 5, 2016 8:40 PM

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:
atari-pic-prog-v4.png

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.

Attached Files



#36 Van OFFLINE  

Van

    Moonsweeper

  • 285 posts
  • Location:Maryland

Posted Tue Jan 5, 2016 11:59 PM

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

Yogi 



#37 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Wed Jan 6, 2016 12:19 AM

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 ☺

#38 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Wed Jan 6, 2016 10:30 AM

 

...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



#39 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Wed Jan 6, 2016 12:26 PM

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 ;)

#40 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Wed Jan 6, 2016 2:09 PM

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  :thumbsup:  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



#41 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Wed Jan 6, 2016 4:48 PM

Got it  :thumbsup:  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/...y-/180815543490????

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

Edited by dmsc, Wed Jan 6, 2016 4:49 PM.


#42 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Wed Jan 6, 2016 8:26 PM

Or perhaps this: http://www.ebay.com/...y-/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 by mytekcontrols, Wed Jan 6, 2016 8:38 PM.


#43 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Wed Jan 6, 2016 9:30 PM

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.

#44 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Thu Jan 7, 2016 2:45 AM

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  :-D

 

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  :thumbsup:  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.

Attached Files


Edited by mytekcontrols, Thu Jan 7, 2016 2:52 AM.


#45 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Thu Jan 7, 2016 6:34 PM

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  :grin:  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  :D  :D  :D  our Atari's can now program PIC microcontroller chips!!!!!!


Edited by mytekcontrols, Thu Jan 7, 2016 7:26 PM.


#46 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Thu Jan 7, 2016 7:54 PM

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

s-l500.jpg

 

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

 

- Michael



#47 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 275 posts
  • Location:Viņa del Mar, Chile

Posted Thu Jan 7, 2016 9:56 PM

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!

Attached Files



#48 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Fri Jan 8, 2016 12:08 AM

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  :thumbsup:


Edited by mytekcontrols, Fri Jan 8, 2016 12:34 AM.


#49 mytekcontrols OFFLINE  

mytekcontrols

    River Patroller

  • Topic Starter
  • 2,190 posts
  • Location:Santa Rosa, CA

Posted Fri Jan 8, 2016 12:27 PM

 

"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



#50 bob1200xl OFFLINE  

bob1200xl

    River Patroller

  • 2,485 posts

Posted Fri Jan 8, 2016 1:01 PM

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







Also tagged with one or more of these keywords: PIC, Atmel, AVR, Arduino, Micro Controllers, ICSP

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users