Standalone Pic Programmer Using ICSP or RS232

[Neiwiertz]

We are two students from holland
At school we have just started a project (2 days)

The goal of the project is to make a standalone programmer for in the field. We are using for standalone programmer (source) and target device the 18F452. We planning that the source device contains in his memory the hex file for the target device.
We would like to use icsp for programming. This is the main goal. But the first task is to understand a bootloader. Any information is welcome!

Greetings Dennis en Sebastiaan

 

[Nigel Goodwin]

We are two students from holland
At school we have just started a project (2 days)

The goal of the project is to make a standalone programmer for in the field. We are using for standalone programmer (source) and target device the 18F452. We planning that the source device contains in his memory the hex file for the target device.
We would like to use icsp for programming. This is the main goal. But the first task is to understand a bootloader. Any information is welcome!

ICSP and bootloading are very different systems, for ICSP your source device needs to be programmed to act as a programmer (which for the 18F series is quite complicated), the target device can be blank, but the target board must be designed specifically for ICSP.

With bootloading the source device just needs to act as an RS232 serial connection, with suitable handshaking - but the target device must be previously programmed with the bootloader system. The target board needs to be designed to have an RS232 port, but it may well have this anyway, and it can still be used normally as well as for bootloading.

Of the two systems I would suggest bootloading would be far easier, see my post in the other thread you asked in.

 

[TiagoSilva]

in other words, if you also need to build up a board for your project i think that putting a ICSP port there would make little diference, you can also programm with the board devices all working since when the MSLR is at 12v ( programming voltage ) the uC stops executing the code and starts the programming mode it's faster and easyer when you don't have any more programmer at hand to put the bootloader first.

 

[piratao2]

Standalone programmer

I need to use the ICSP approach... Could you please give me any information about that? I've tried to take a look on the pdf from microchip regarding the programming specifications, but:
1-I did not get the big picture of what is needed on the circuit.
2-I did not understand how (protocol, bitrate, format, etc) the data is transferred from the source PIC to the target one.
3-How the information should be saved on the source PIC so it can be transferred to the target one?
4-In my understanding, the source PIC will need to have the program that is responsible for sending the data to the target PIC. If my program is already using most of the memory available on the PIC, could I use another bigger PIC to have the source data and the program that sends the data to the target PIC?

thanks.

 

[Nigel Goodwin]

I need to use the ICSP approach... Could you please give me any information about that? I've tried to take a look on the pdf from microchip regarding the programming specifications, but:
1-I did not get the big picture of what is needed on the circuit.
2-I did not understand how (protocol, bitrate, format, etc) the data is transferred from the source PIC to the target one.

It's NOT RS232, you need to read (and understand) the programming datasheet, which explains everything you need to know. There are a fairly large number of different programming algorithms used, depending on the PIC you're hoping to program. The 18F series though are COMPLETELY different to any that have gone before.

Essentially the transfer is a syncronous serial protocol with a varying word length, different parts of the same PIC even use different word .lengths

3-How the information should be saved on the source PIC so it can be transferred to the target one?

I would suggest it's stored in an EEPROM, and the programmer PIC reads it from there and transfers it to the target.

4-In my understanding, the source PIC will need to have the program that is responsible for sending the data to the target PIC. If my program is already using most of the memory available on the PIC, could I use another bigger PIC to have the source data and the program that sends the data to the target PIC?

See 3).

 

[piratao2]

Ok, let me clarify some details about my project:
The PIC that I expect to be able to copy (or clone) without a PC is the 16F628(a) and the 16F819. No problem about designing 1 standalone programmer for each model of PIC if this makes the project easier...
The objective is to be able to burn just one source PIC with my computer (unprotected obviously) and then put it on a socket on the standalone programmer board. Then, I should have an intermediate PIC that would be responsible for reading from the source PIC and then writing on the target PIC. Let's call this intermediate PIC as the programmer PIC.
The target PIC would be a clone of the source PIC, except for the configuration word, since the target PIC would need to be protected. I believe the configuration work can be generated by the programmer PIC and then writen to the target PIC at the end of the cloning, right?

Correct me if I'm wrong but I believe I can afford this project by using a 16F628A as the programmer PIC. I would use then 2 i/o from it, one to read data from the source PIC and the other to write data on the target PIC. The same pin from the programmer pic that reads data from the source PIC needs to be used to send the command to read the data, right? And the same applies when writing the data to the target PIC, right?
The standalone board would use a 12v power source for VPP and a lm7805 regulating voltage at 5v for the VDD.
Some LEDs would also be used to indicate data flow and activity.
After the 1st design is tested and working, I could also add some jumpers/switches on the programmer PIC so it is able to clone more models of PIC, in the case of the need to have different programming commands/techniques for different models.

Ok, then, some doubts arise:

1) How to generate the clock for the source and target PIC's? Do they should /could be the same clock as the 4mhz crystal that I expect to use to be the oscillator for the programmer PIC? If so, how to wire the crystal to the source and target PIC's? Is there a limit for the clock used for ICSP?

2) How exactly I need to send the bits for a command? I need to know how to send the commands... Are there any control bits (start, parity, stop, etc) needed on the communication between the programmer PIC and the source/target PIC's? The data returned from the source/target PICs will have also the same control bits?

3) Should I need to concern about checksums? If so, how they work?

Thanks!

 

[Nigel Goodwin]

1) How to generate the clock for the source and target PIC's? Do they should /could be the same clock as the 4mhz crystal that I expect to use to be the oscillator for the programmer PIC? If so, how to wire the crystal to the source and target PIC's? Is there a limit for the clock used for ICSP?

OK, this is clearer now, you're using THREE PIC's, one source, one target, and one to actually copy source to the target.

Only ONE PIC needs a clock signal, that's the one that's doing the copying. If either the source or target are running them you can't access programming mode on them.

2) How exactly I need to send the bits for a command? I need to know how to send the commands... Are there any control bits (start, parity, stop, etc) needed on the communication between the programmer PIC and the source/target PIC's? The data returned from the source/target PICs will have also the same control bits?

As I said before, it's a syncronous protocol, none of those terms apply, there are NO control bits.

3) Should I need to concern about checksums? If so, how they work?

It's essential you read (and understand) the programming datasheet for the PIC's in question, they explain all your questions, including how to generate the checksums.

 

[piratao2]

Ok, thanks...

So, there is not anything else to say or understand than what is on the document from Michochip, right?
I'll need to read it again and again until I understand it fully because my doubts still remain.

See, regarding your comments:

OK, this is clearer now, you're using THREE PIC's, one source, one target, and one to actually copy source to the target.

Only ONE PIC needs a clock signal, that's the one that's doing the copying. If either the source or target are running them you can't access programming mode on them.

Sorry for the confusion, but the initial idea changed and I think it is easier to use 3 PIC's like I mentioned in the previous post.
The doubt here is regarding the clock, on the clock pin, for programming mode, both on the source and on the target PIC's. See below in more detail what I wanted to ask about regarding the clock.

As I said before, it's a syncronous protocol, none of those terms apply, there are NO control bits.

Ok sorry, synchronous means no control bits.
Then I understand that as a synchrounous protocol, there should be a shared control line between the PIC's so they can control when the data is transmitted, and/or a shared clock with a minimum time delay before each command.
Then I suppose I have only a shared clock, when in programming mode, between the programming PIC and the other 2 PIC's.
The doubt is how the clock is shared between the 3 PIC's? You said only the programming PIC should have its own oscillator clock, because obviouly it will be the only one not in programming mode. Then, I suppose there is some way for the programming PIC to share the clock with the other 2 PIC's so the data being transferred from/to the other PIC's can be sent synchrounously.
So, If I'm right on my conclusions, I'd like to know what pin of the programming PIC should be connected to the RB6/clock pin on the other 2 PICs to generate the shared programming mode clock for all of them?
Or should I use another kind of clock generator to generate the programming mode clock?
Or I should just connect the RB6/clock pin from the programming PIC to the RB6/clock pins on the other 2 PIC's and this will be enough to generated the clock for the programming mode for all of them?

3) Should I need to concern about checksums? If so, how they work?

I'd like to have a brief explanation about what is the purpose of the checksum. The formula for the calculation is obvious, very simple, but it is not mentioned anywhere what is the purpose of the checksum since I did not see where it should be saved on the PIC. Then, I thought it could maybe used only for code verification at the end of the programming mode (end of burning)??? If it is not essential that is is burnt on the PIC, I can just leave it uncalculted for the simplify the first prototype.

Another doubt regarding the checksum is: If it is used only for code verification at the end of burning, would it be the better way to program the entire target PIC, save its checksum on a register, then read the entire source PIC and compare its checksum with the saved one? (obviously the PIC executing these tasks would be the programming PIC, which is the only one not in programming mode)

Thanks.

 

[Nigel Goodwin]

So, there is not anything else to say or understand than what is on the document from Michochip, right?
I'll need to read it again and again until I understand it fully because my doubts still remain.

See, regarding your comments:

Sorry for the confusion, but the initial idea changed and I think it is easier to use 3 PIC's like I mentioned in the previous post.

Yes, or two PIC's and an EEPROM, basically one PIC does the actual programming, reading data from the source (either another PIC or EEPROM) and writing it to the target PIC. Most PIC's can't read their own program space, so you couldn't have one reading itself and copying to another one.

Such devices were common many years ago, I have one here that copies a source 16C84 to a target 16C84 - there's a turned pin socket for the source, and a ZIF for the target, the copying PIC (presumably another 16C84?) is soldered on the bottom of the single sided PCB and covered in epoxy resin.

The doubt here is regarding the clock, on the clock pin, for programming mode, both on the source and on the target PIC's. See below in more detail what I wanted to ask about regarding the clock.

Ok sorry, synchronous means no control bits.
Then I understand that as a synchrounous protocol, there should be a shared control line between the PIC's so they can control when the data is transmitted, and/or a shared clock with a minimum time delay before each command.

I would suggest using completely seperate lines for both source and target PIC's, it's probably possible to do it with common clock and data, but you would need to repeatedly switch them between the source and target.

So you need Vdd, Vpp, Clock, Data for each PIC, that's 8 I/O lines.

It goes like this:

Set source PIC to programming mode and read.
Set target PIC to programming mode and write.
Read word from source
Write word to target
Repeat until done.

You need to do the same for data EEPROM and config fuses etc. as well.

Then I suppose I have only a shared clock, when in programming mode, between the programming PIC and the other 2 PIC's.
The doubt is how the clock is shared between the 3 PIC's? You said only the programming PIC should have its own oscillator clock, because obviouly it will be the only one not in programming mode. Then, I suppose there is some way for the programming PIC to share the clock with the other 2 PIC's so the data being transferred from/to the other PIC's can be sent synchrounously.
So, If I'm right on my conclusions, I'd like to know what pin of the programming PIC should be connected to the RB6/clock pin on the other 2 PICs to generate the shared programming mode clock for all of them?
Or should I use another kind of clock generator to generate the programming mode clock?

You're confusing your clocks! - the copying PIC has a clock oscillator, nothing else does - the 'clock' used for the syncronous data transfer is generated by the copying PIC on an I/O pin.

Or I should just connect the RB6/clock pin from the programming PIC to the RB6/clock pins on the other 2 PIC's and this will be enough to generated the clock for the programming mode for all of them?

NO - as I said NO CLOCKS FOR THE TARGET AND SOURCE!.

I'd like to have a brief explanation about what is the purpose of the checksum. The formula for the calculation is obvious, very simple, but it is not mentioned anywhere what is the purpose of the checksum since I did not see where it should be saved on the PIC. Then, I thought it could maybe used only for code verification at the end of the programming mode (end of burning)??? If it is not essential that is is burnt on the PIC, I can just leave it uncalculted for the simplify the first prototype.

Another doubt regarding the checksum is: If it is used only for code verification at the end of burning, would it be the better way to program the entire target PIC, save its checksum on a register, then read the entire source PIC and compare its checksum with the saved one? (obviously the PIC executing these tasks would be the programming PIC, which is the only one not in programming mode)

From what I can recall there's no great need for the checksum?, and isn't it only a check of the HEX file you load from disk?, and not involved in the PIC code?.

You're undertaking a pretty complicated project, even more so because it's both hardware and software, so it's VERY difficult to know where your problems might lay.

I would suggest you do it in stages, for a start try and read a PIC and send the data to the computer via RS232 - for a start just the first few data words would do, then progress until you can reliably read an entire PIC.

Next, try and do the same writing a PIC, send RS232 data to the PIC and try and write to a target device. Again, once you've got this working expand until you can write the entire memory, including data EEPROM and fuses.

Next, combine the two, so you have a fully functional RS232 PIC programmer, confirm that you can read and write a PIC. You might try copying a PIC like this, read it back to the PC and write it back to another one.

Last, remove the PC, get rid of the RS232 routines (although it's probably worth keeping them, so you can use it as a programmer as well), and connect the read and write parts together - it's not quite as simple as that, as you need to do it a word at a time, but it should be fairly straight forward to do.

 

[piratao2]

Thanks for your answers...

Actually I dont think it is so difficult to do the software on the programming PIC. This is easy to me but I need to know what the program needs to do.

Just for reference, I've done some very complex programs including realtime processing of packets of bytes coming in and out of a PIC in manchester protocol, using bit bang techiniques. The program takes the timing from the input pin to generate the ouput bits simulatenously as data comes. I've also done another simpler one that converts serial data from the computer to manchester data and vice-versa. Although, I'm not very good with hardware and electronics since I don't work with electronics...
Electronics and PIC's are just a hobby for me, but I'm very very dedicated and I'll do that project, since I need it for a friend. In some aspects I'm more than a newbie, on other ones I'm very advanced PIC programmer.
So please, correct me when I say something stupid, I just like to think about the projects so I can learn...

Ok, coming back on my doubts:

I would suggest using completely seperate lines for both source and target PIC's, it's probably possible to do it with common clock and data, but you would need to repeatedly switch them between the source and target.

So you need Vdd, Vpp, Clock, Data for each PIC, that's 8 I/O lines.

Ok, but I thought VDD and VPP could be shared and constantly on while I turn on the circuit board. This simplifies the things, because once the PICs are there, I just turn on the standalone programmer and then it will already put both source and target PIC on programming mode. Is that possible or ********?
Regarding the clock data, I don't know how I could set an I/O pin to generate clock data other that setting it high and low at a constant frequency. So, I thought the RB6/clock pin was already responsible for generating clock cycles so the PICs can be in sync. So, after reading your response I suppose they are only for input of the clock pulses while in the programming mode, and that I will need to generate the clock pulses for the synchrounous communication other way, right?
What I wanted to do is to somehow take the clock pulses from the crystal used as the XT oscillator for the programming PIC to generate the clock pulses needed on the RB6/clock pin of the source/target for the synchrounous communication. The objective is to not have use cycles from the programming PIC to generate clock pulses for the source and the target. The clock pulses would then be constant all the time.
Then, if the above is possible, I would need only 2 i/o pins on the programming pic that would be used for output of the commands for the source/target PIC's and also for sending and receiving data from one to the other.
So the sequence would be like this:
Turn off the circuit with a switch.
Put both the source and the target PICs at their respectives sockets.
Turn on the circuit.
VPP is applied to both the source and the target PIC's.
Then VDD is applied both programming, source and target PIC's.
At this time, the clock pulses on RB6/clock pin of both the source and the target PIC's will be constant.
Then the programming PIC starts its routines which consists:
Set the 1st i/o pin to output and send the "read data" command for the source PIC;
Set the 1st i/o pin as input, loading data from the source;
Set the 2nd i/o pin as output and send the "load data" command for the target PIC with the data that was copied from the source to the target PIC through the 2nd i/o pin;
Increase the PC so the next address is read on the source PIC until it achieves the end.
Repeat until the end. The same for EEPROM memory.

Please I don't know if I'm wrong about the above concepts... Let me know your opinion...

My understanding is that the clock pulses for the programming mode on the RB6 pin for both the source and target PICs can be constant, even with not data is being writen/read. Also, I believe once the VPP is applied to source and target they are still in programming mode.

Please correct me/comment anything if I'm wrong...

Thanks...

 

[Nigel Goodwin]

Ok, but I thought VDD and VPP could be shared and constantly on while I turn on the circuit board. This simplifies the things, because once the PICs are there, I just turn on the standalone programmer and then it will already put both source and target PIC on programming mode. Is that possible or ********?

You need to switch Vdd and Vpp individually from the copying PIC, in order to select and de-select programming mode - it would probably be helpful if you could do this independently - bear in mind this is all done by the copying PIC.

Regarding the clock data, I don't know how I could set an I/O pin to generate clock data other that setting it high and low at a constant frequency. So, I thought the RB6/clock pin was already responsible for generating clock cycles so the PICs can be in sync. So, after reading your response I suppose they are only for input of the clock pulses while in the programming mode, and that I will need to generate the clock pulses for the synchrounous communication other way, right?
What I wanted to do is to somehow take the clock pulses from the crystal used as the XT oscillator for the programming PIC to generate the clock pulses needed on the RB6/clock pin of the source/target for the synchrounous communication. The objective is to not have use cycles from the programming PIC to generate clock pulses for the source and the target. The clock pulses would then be constant all the time.

You're STILL thinking clocks - NO CLOCKS, EVEN THROW YOUR WATCH AWAY!.

What the CLOCK actually means for a syncronous transfer:

OK, we're sending a number of bits to a PIC, using two pins one as 'data', one as 'clk'.

To start BOTH pins are low.

You place the first bit on 'data' (either 0 or 1)
You switch the 'clk' pin HIGH, wait a short while, and switch it LOW again, this action has 'clocked' the single data bit into the PIC.

You repeat for all the other bits, until a complete word is tranferred, paying a ttention to the programming datasheet for how many bits you need, and (sometimes) how many dummy clock pulses you might need to send at the end of the data transfer.

That's what the 'clock' pin is for!.

Then, if the above is possible, I would need only 2 i/o pins on the programming pic that would be used for output of the commands for the source/target PIC's and also for sending and receiving data from one to the other.
So the sequence would be like this:
Turn off the circuit with a switch.
Put both the source and the target PICs at their respectives sockets.
Turn on the circuit.
VPP is applied to both the source and the target PIC's.
Then VDD is applied both programming, source and target PIC's.
At this time, the clock pulses on RB6/clock pin of both the source and the target PIC's will be constant.
Then the programming PIC starts its routines which consists:
Set the 1st i/o pin to output and send the "read data" command for the source PIC;
Set the 1st i/o pin as input, loading data from the source;
Set the 2nd i/o pin as output and send the "load data" command for the target PIC with the data that was copied from the source to the target PIC through the 2nd i/o pin;
Increase the PC so the next address is read on the source PIC until it achieves the end.
Repeat until the end. The same for EEPROM memory.

Please I don't know if I'm wrong about the above concepts... Let me know your opinion...

My understanding is that the clock pulses for the programming mode on the RB6 pin for both the source and target PICs can be constant, even with not data is being writen/read. Also, I believe once the VPP is applied to source and target they are still in programming mode.

Please correct me/comment anything if I'm wrong...

Most of it is wrong, consult my previous posts (and this one), and read the programming datasheet - which even gives scope waveforms of how to do the transfers!.

 

[Oznog]

It would seem fairly simple to take an already designed and built programmer and have another PIC talk to it through the serial port. Of course the PIC would not be able to hold an entire image of all possible code space on its own flash because the code to talk to the programmer will itself take up some of the available space. You could carry an external EEPROM (like an I2C) to hold the image for transfer.