PIC "In-Circuit" Programming?

[Jidis]

I couldn't help but notice you rarely see mention of that here. Is there some reason not to use it?

Seems like without a ZIF socket, those of us who screw around with our apps a lot might not be doing our PIC legs much good. ;)

Might stick one on this board I'm using.

Thanks!

George

[Synapsys]

If you use the MIOS boot loader you can compile the application code and download it to the PIC via the MIDI port. This means you don't need a seperate programmer. This is why an in-circuit programmer is rarely mentioned.

I use the Microchip ICD2 module to program and debug PIC code in-circuit. Since ICP uses two pins on port B a jumper setup like is on the core schematic is needed to allow programming and use of these pins for the LCD.

To avoid having to use the jumper setup I run my LCD in 4-bit mode so port B bits 6 and 7 are free. Then I can use the ICD2 and the LCD at the same time. :D

Regards,

Synapsys

[Jidis]

Synapsys,

Thanks!

I would probably be using mine for tweaking apps for use on another box, so I probably wouldn't want to be running an alternate LCD setup, but I've got a pile of DIP switches and headers here, so arranging the regular wiring shouldn't be a problem.

Just wondering if ICSP is known to make reliable burns or if there are any "tricks" to it.

FWIW- I normally do most of my app transfers by MIDI in MIOS Studio, but somehow I've had way too many occasions where I've mangled my PIC contents and haven't been able to get back to an accessible loader without re-burning. Considering that, it probably wouldn't be safe for me to trap the PIC in a box. I may just have bad luck in that area.

???

George

[Sasha]

As my display feature suddanly stopped working (display module is OK) I am also thinking of onboard programming as convenient feature and I am also interested is there I should know about that.

[stryd_one]

somehow I've had way too many occasions where I've mangled my PIC contents and haven't been able to get back to an accessible loader without re-burning. Considering that, it probably wouldn't be safe for me to trap the PIC in a box. I may just have bad luck in that area.

I think you may have bad luck, or maybe a badly soldered board, or maybe the bootloader is not being burned properly... I don't know. As TK has said, and as the code will show, it is almost impossible for the bootloader code to be overwritten. Perhaps, instead of deciding that there is a problem with MIOS or the bootloader, you might want to take a look at other factors.

[Synapsys]

Just wondering if ICSP is known to make reliable burns or if there are any "tricks" to it.

There is only one way to program a PIC (other than using something like the bootloader) and that is to use the PGD, PGC and MCLR pins. Whether you are doing the programming 'In-Circuit' or in a prgrammer the actual process of programming the chip is the same.

If you look at the PIC Burner schematic on uCApps you will notice that only pins RB6,RB7 and MCLR are actually used to program the chip. If you wanted to do ICSP you could build the PIC burner and instead of having a socket have a short cable that connects to these pins on your board.

Make sure that the PGD,PGC and MCLR pins do not have any other circuitry connected to them while programming is taking place.

The other thing to be careful about is the pulldown resistors on RB5 (18F) and RB3 (16F). These are required to assure that the low voltage programming (LVP) mode is disabled. Alternatively, there is a configuration bit that disables LVP mode. This is how the ICD2 module works.

So, ICSP is just as reliable as using an external programmer.

Hope this helps.

Regards,

Synapsys

[Jidis]

Synapsys and all,

I still haven't had a chance to get any ICSP going here. I've got a JDM and a Willem here which have ICSP connectors. I also want it for 16f84's and stuff.

Wasn't there some weird stuff which needed to be opened/closed in the regular PIC/Core connections during that procedure? I'm planning to add the ICSP pins to a Core mod here, and have considered figuring out a way to use some board mounted DIP switches or something, so I wouldn't have to do a bunch of disconnecting and jumpering.

Also, do you think the ICSP would be any different (better?) with regard to the notorious JDM issues, or any other programmer's voltage flaws? I may even just run a small JDM circuit inside the boxes, with a D-sub input, so I could program directly into the MB. ;D

Thanks!

George 

[Synapsys]

I still haven't had a chance to get any ICSP going here. I've got a JDM and a Willem here which have ICSP connectors. I also want it for 16f84's and stuff.

I am not going to comment on the JDM other than to point out that there have been a great many posts here by people that have had trouble getting it to work with various PCs. I think you should consider the MBHP PIC Burner instead. I built one and it worked perfectly from the start.

Wasn't there some weird stuff which needed to be opened/closed in the regular PIC/Core connections during that procedure?

Nothing really weird here. Go to the uCApps site and check out the schematic for the core module. Connector J3 has jumpers that need to be removed to utilize the ICSP feature. This connector gives you access to the PGD,PGC and MCLR pins as I indicated in my prior reply.

stryd_one said:

I think you may have bad luck, or maybe a badly soldered board, or maybe the bootloader is not being burned properly... I don't know. As TK has said, and as the code will show, it is almost impossible for the bootloader code to be overwritten. Perhaps, instead of deciding that there is a problem with MIOS or the bootloader, you might want to take a look at other factors.

I agree with this. The boot loader has code that prevents it from overwriting itself. They only way it could (normally) be overwritten is if you wrote code in an application that performs writes to program memory and uses addresses in the boot space. Up coming changes may even make this impossible by utilizing the boot protect configuration bits. I think it would be advisable to consider using the boot loader (or a derivative) in preference to ICSP. Not only is it more convenient, it is much faster.

Regards,

Synapsys

[moebius]

Also, do you think the ICSP would be any different (better?) with regard to the notorious JDM issues, or any other programmer's voltage flaws? I may even just run a small JDM circuit inside the boxes, with a D-sub input, so I could program directly into the MB. ;D

Basicly NO - You can expect problems with ANY programmer without proper signal buffering or NOT - Broccoli18 is a fine example, simpler than anything, but You'll need parallel port that works with it ;)

Moebius

[Jidis]

Moebius,

Thanks!

I haven't been getting in much box time lately, as I've moved my electronics crap out of the studio to keep from wasting my whole night not doing any music stuff. ;)

Yeah, on the JDM, I just didn't know if the supply lines with a JDM were weaker or something, since it was "port powered", and if it may share any pins with the core, while it was doing an in-circuit deal, making it more reliable. Doesn't sound that way. :'(

There's a Willem here, which I'll probably use for the more frequent stuff. I'd really like to get away from things that don't use ZIF sockets as much as possible, but I guess even the core will have a regular one, so ICSP will be a good thing. I will however, probably try to find a means of dip-switching the connection somehow, so I don't have to keep re-jumpering,etc. I did a bunch of MIDI crap on an 18-pin 16F84 a while back, and it was moved from programmer to breadboard so many times, I'm surprised it still had legs.

I'm looking toward being able to work with a few different ones also. My books don't deal with 40pin PIC's, and they're a bit large for me right now. I'll probably do a common connection for ICSP on all my test boards.

BTW---> I think I asked before, but this one serial book deals with a 16C54 a bunch. I've run into it before, and it appears to require some weird programming method, as do some of the other older "mid-range" PIC's. Something sounded like it might be an application issue.

Does anyone know what needs to be used for those?

- Much Thanks!

George

[moebius]

I haven't been getting in much box time lately, as I've moved my electronics crap out of the studio to keep from wasting my whole night not doing any music stuff. ;)

;D

There's a Willem here, which I'll probably use for the more frequent stuff. I'd really like to get away from things that don't use ZIF sockets as much as possible, but I guess even the core will have a regular one, so ICSP will be a good thing. I will however, probably try to find a means of dip-switching the connection somehow, so I don't have to keep re-jumpering,etc. I did a bunch of MIDI crap on an 18-pin 16F84 a while back, and it was moved from programmer to breadboard so many times, I'm surprised it still had legs.

I was happy to see usually expensive ELFA to carry cheapish (that's under 20e) ZIF sockets. I should build Willem too as I need to program some EPROMs along uCs..

BTW---> I think I asked before, but this one serial book deals with a 16C54 a bunch. I've run into it before, and it appears to require some weird programming method, as do some of the other older "mid-range" PIC's. Something sounded like it might be an application issue.

IC-Prog pages suggests "TAIT" style programmer to work with these (it's buffered) - but on the other hand Why would you work with these old one time programmable PICs?

Moebius

[Jidis]

I should build Willem too as I need to program some EPROMs along uCs..

Look into that first. Seems people have started "mass producing" them. You can get ones on eBay now with USB, parallel, and a bunch of the optional adapter sockets on-board, for less than the parts probably cost. There was a thread here recently on it. It's almost not worth thinking about making one anymore.

IC-Prog pages suggests "TAIT" style programmer to work with these (it's buffered) - but on the other hand Why would you work with these old one time programmable PICs?

I thought I had checked that app, and either my hardware didn't support it, or IC-Prog didn't. ???  I've got a PICall or something around here, that used P16Pro in DOS. I thought  it was a TAIT-style, but I haven't used it in a while. It was relatively simple looking, so it may not be the right one. There's also a PCB that came with a book here (called an "el-cheapo", I believe). I'll look into that one too. The serial book uses the old PIC, so if I try any of that stuff, and there isn't a code/pin/clock-compatible current model, I'm probably not into trying to port the apps at this stage.

Thanks!

George

[moebius]

Hi.

Look into that first. Seems people have started "mass producing" them. You can get ones on eBay now with USB, parallel, and a bunch of the optional adapter sockets on-board, for less than the parts probably cost. There was a thread here recently on it. It's almost not worth thinking about making one anymore.

Thanks for the tip.. I'm still probably building one, I have a source (here in Finland) for the PCB and for that cheapish ZIF socket. Other parts probably can be recycled from the junk I have.

There's also a PCB that came with a book here (called an "el-cheapo", I believe). I'll look into that one too. The serial book uses the old PIC, so if I try any of that stuff, and there isn't a code/pin/clock-compatible current model, I'm probably not into trying to port the apps at this stage.

Hmm.. Maybe porting code from 16C54 to 16F84 would be good way to learn stuff. Aren't the instructions sets pretty similar? Then you'd have to figure out differences in the innards ect.

Moebius