N
Neiwiertz said: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!
piratao2 said: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?
piratao2 said: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?
3) Should I need to concern about checksums? If so, how they work?
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.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.
Ok sorry, synchronous means no control bits.As I said before, it's a syncronous protocol, none of those terms apply, there are NO control bits.
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.3) Should I need to concern about checksums? If so, how they work?
piratao2 said: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.
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.
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?
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)
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 ********?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.
piratao2 said: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...
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?