Hi, I´m using a programmer that I made based on your hardware revision 0.3.2. The only diference is that I use a 18F4550 instead of a 18F2550.
I'm currently on firmware version 130804 and the corresponding software (amd64 version).
I´m trying to program somo 16F1825 but I´m having different results. The chips are recognized without any problems by the programmer, but when I try to program them most of the time I get an error and it fails to program them, someytimes simply nothing is written to the memory or when it does, it has errors. From time to time I get one correctly programmed.
I use a 9V zener between Vpp and Gnd to prevent damaging the chip.
Any idea of what could be the problem? Is it possible that it could be any timing errors in the writing procedures in the firmware? The wires that I use from the programer to the target chip are short (10 to 12 cm).
I have been using this hardware and your software for a long time programming other types of pic without any problems but trying to use it with the 16F1825 is really driving me nuts...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Franz: I think that the problem could be in the timing in the firmware. I caught the clock signal with a scope, and the first sequence of pulses (the first 6 bits) are ok, but the following 16 always start as shown in the picture, and with long programs and a bit of noise, the first and the last pulses could be missed...
I think that this could be the problem...
With short programs, the programmer works ok, but with long ones it fails.
hi Frans: I tryed it but the problem is still there... after 3 tries I could program one chip, but it is still failing most of the times, specially in data and configuration memory...
Why are those first and last clock pulses shaped in that way just in the 16 bits sequence?
Thanks, Pablo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This piece of code is one that is giving me troubles. I also noticed that the problem gets worst when the code gets bigger. It is wierd but it seems not to have problem with shorter code.
If you want you can give it a try with this attached code.
If you pay attention to the first part of the routine, you only have a clock_delay between PGChigh and PGClow for the first bit, but for the following 14 bits, you have a clock_delay plus a payload>>=1 between de high and low transition. That explain the difference in the shape of the pulses. (As I understand, clock_delay is just a nop operation, just one instruction)
If you add an additional clock_delay between high and low transition for the first and last bits, perhaps that solve the problem...
What do you think about it?
Regards, Pablo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frans: unfortunately this new firmware didn't change the situation. I'm still having troubles to program a 16f1825.
I observed that the shape of the waveform is still the same. Don´t you think that this could be the problem?
I also noticed that some times an interruption appears during the programming cycle and some bit appears with a longer period...
I attached a capture of the waveform... this happend al the start and end of the 16 clock cycles portion. That perfectly matches with what I told you about the code in prog_lolvl.c
I have made a few fixes today, could you check the latest git version of the firmware (same link as before)?
For me it works more stable now.
I also made some changes in the software (added delay after program cycles, but I don't know whether they improve the situation.
Frans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to be a little more stable, but I still have to try 5 to 6 times to get one programmed. The 16 clock pulses now are perfectly shaped, the groups of 6 pulses before and after them are still been asymetrical, but I don't know if it is causing the problem now. I attached a couple of scope captures to show it.
A friend of mine has just received an usbpicprog programmer that he bought from you (Luis) and I tested this new firmware on it unfortunately with the same result.
When you program this kind of chips, do you always succeed or sometimes it fail?
In my case, the programer is rock solid when programming small pieces of code, the problem appears when the code is of 20% of the rom or more in this type of pic.
Hi Frans... I tryed the new firmware but without any improvement in fail/success ratio.
The failure happens randomly at code, data or configuration memory. It seems that is a kind of event that happens during the writing cycle, like an interruption... are they disabled during it?
Pablo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Pablo,
Somebody else is having the same problems with exactly the same pic. Also similar problems happened with the 16F628A, but this has been fixed. It was a combination of the resent fixes, and forcing the PGM signal to GND.
The PGM signal caused the 628A to become unstable, but the 1825 doesn't have this signal.
I am now reading through the programming specification over and over again, but I still haven't found the solution to the problem.
Frans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It could be that the PIC starts executing code during programming mode entry. To prevent this, I have changed the 16F18XX to VPP first program mode entry. Could you upgrade the firmware one more time with this one? https://raw.github.com/fransschreuder/usbpicprog/master/trunk/uc_code/uc_code.hex
I am sorry it takes so long.
Frans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Frans, I tryed this new firmware but without luck... The problem seems to be worst than with the last firmware... now it always fail when verifying the code memory.
Are you been able to program this chips with this new firmware?
If I just program data and configuration memory everything seems to be ok... the problem is with the code memory...
Pablo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frans: what I still don't understand is why a shorter code is programmed without any problem. When I try with a bigger one not even the data or the configuration memory are written...
Pablo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frans: with this new firmware, if I don't use the 9V zener it works perfectly...
I tryed to program several chips and always succeed to do it.
Thanks...
I only hope not damaging the chips for not using the 9V zener :)
Thanks again for such good application.
Pablo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Frans... I'm here again... with your last firmware I've been programming the 16f1825 without any problema till now. This time the problem seems to be the algorithm used for this kind of chip...
I attached a hex file. I'm not been able to program it on a 1825, but if I add a couple of instruction to the code and compile it again I can program it without any problem.
This behavior happens every time I try to program the chip... this hex never gets programmed and the other always finish ok.
If I try to program the same code in a 16f877A it works ok, so it seems to be something related just to the 16f1825...
Could you try to program this hex to a 1825 and reproduce the problem?
Any idea of what it could be the problem?
It must be the 1825 that still executes software in some cases.
Unfortunately I can't test this week as I am away, I can try to implement the low voltage programming entry method, it probably has a better performance.
I can make changes, but it's difficult to try on hardware this week. Could you test if I make changes?
Frans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frans and Pablo... adding my two cents here. I downloaded the problematic file and got an error: Error programming config memory. Under details, I noticed that it expected 0x80 at 0x0, but read 0xFF. Just to verify a theory, I manually changed the first byte (80) to FF, and tried programming again. This time the device programmed and verified correctly...
Other codes such as 90 also yield positive results, while others, e.g. 70, still result in the same error.
Oddly enough, other programs starting with 80 can be programmed without a hitch, so at this point I can only share these findings, but no logical explanation... I hope that at least this may provide another clue to help solve the issue.
Marcelo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I´m using a programmer that I made based on your hardware revision 0.3.2. The only diference is that I use a 18F4550 instead of a 18F2550.
I'm currently on firmware version 130804 and the corresponding software (amd64 version).
I´m trying to program somo 16F1825 but I´m having different results. The chips are recognized without any problems by the programmer, but when I try to program them most of the time I get an error and it fails to program them, someytimes simply nothing is written to the memory or when it does, it has errors. From time to time I get one correctly programmed.
I use a 9V zener between Vpp and Gnd to prevent damaging the chip.
Any idea of what could be the problem? Is it possible that it could be any timing errors in the writing procedures in the firmware? The wires that I use from the programer to the target chip are short (10 to 12 cm).
I have been using this hardware and your software for a long time programming other types of pic without any problems but trying to use it with the 16F1825 is really driving me nuts...
Franz: I think that the problem could be in the timing in the firmware. I caught the clock signal with a scope, and the first sequence of pulses (the first 6 bits) are ok, but the following 16 always start as shown in the picture, and with long programs and a bit of noise, the first and the last pulses could be missed...
I think that this could be the problem...
With short programs, the programmer works ok, but with long ones it fails.
Regards, Pablo.
Dear Pablo,
Thanks for the input!
Could you try this firmware:
https://raw.github.com/fransschreuder/usbpicprog/master/trunk/uc_code/uc_code.hex
Frans
hi Frans: I tryed it but the problem is still there... after 3 tries I could program one chip, but it is still failing most of the times, specially in data and configuration memory...
Why are those first and last clock pulses shaped in that way just in the 16 bits sequence?
Thanks, Pablo
The clk waveforms seems to be practically the same.
Pablo
Ok, this was a quick fix. I will check with an oscilloscope this afternoon.
Frans
Hi Frans,
This piece of code is one that is giving me troubles. I also noticed that the problem gets worst when the code gets bigger. It is wierd but it seems not to have problem with shorter code.
If you want you can give it a try with this attached code.
Thanks again,
Pablo
Hi Frans: I think that the problem could be in the program prog_lolvl.c
In particular in the function: pic_send_word_14_bits
void pic_send_word_14_bits( unsigned int payload )
{
char i;
PGDlow();
clock_delay();
PGChigh();
clock_delay();
PGClow();
clock_delay();
for( i = 0; i < 14; i++ )
{
if( payload & 1 )
PGDhigh();
else
PGDlow();
PGChigh();
payload >>= 1;
clock_delay();
PGClow();
clock_delay();
}
PGDlow();
clock_delay();
PGChigh();
clock_delay();
PGClow();
clock_delay();
clock_delay();
}
If you pay attention to the first part of the routine, you only have a clock_delay between PGChigh and PGClow for the first bit, but for the following 14 bits, you have a clock_delay plus a payload>>=1 between de high and low transition. That explain the difference in the shape of the pulses. (As I understand, clock_delay is just a nop operation, just one instruction)
If you add an additional clock_delay between high and low transition for the first and last bits, perhaps that solve the problem...
What do you think about it?
Regards, Pablo.
Please try this commit
https://raw.github.com/fransschreuder/usbpicprog/master/trunk/uc_code/uc_code.hex
Frans: unfortunately this new firmware didn't change the situation. I'm still having troubles to program a 16f1825.
I observed that the shape of the waveform is still the same. Don´t you think that this could be the problem?
I also noticed that some times an interruption appears during the programming cycle and some bit appears with a longer period...
I attached a capture of the waveform... this happend al the start and end of the 16 clock cycles portion. That perfectly matches with what I told you about the code in prog_lolvl.c
Thanks again for your patience,
Pablo.
Ok, I will have a closer look. Please give me some more time to have a closer look at it.
Take your time
Thanks
Pablo
Hi Pablo,
I have made a few fixes today, could you check the latest git version of the firmware (same link as before)?
For me it works more stable now.
I also made some changes in the software (added delay after program cycles, but I don't know whether they improve the situation.
Frans
Hi Frans,
It seems to be a little more stable, but I still have to try 5 to 6 times to get one programmed. The 16 clock pulses now are perfectly shaped, the groups of 6 pulses before and after them are still been asymetrical, but I don't know if it is causing the problem now. I attached a couple of scope captures to show it.
A friend of mine has just received an usbpicprog programmer that he bought from you (Luis) and I tested this new firmware on it unfortunately with the same result.
When you program this kind of chips, do you always succeed or sometimes it fail?
In my case, the programer is rock solid when programming small pieces of code, the problem appears when the code is of 20% of the rom or more in this type of pic.
Thanks for your patience
Pablo.
Any news about a solution to this problem?
Pablo
Hi Frans... I tryed the new firmware but without any improvement in fail/success ratio.
The failure happens randomly at code, data or configuration memory. It seems that is a kind of event that happens during the writing cycle, like an interruption... are they disabled during it?
Pablo
Dear Pablo,
Somebody else is having the same problems with exactly the same pic. Also similar problems happened with the 16F628A, but this has been fixed. It was a combination of the resent fixes, and forcing the PGM signal to GND.
The PGM signal caused the 628A to become unstable, but the 1825 doesn't have this signal.
I am now reading through the programming specification over and over again, but I still haven't found the solution to the problem.
Frans
It could be that the PIC starts executing code during programming mode entry. To prevent this, I have changed the 16F18XX to VPP first program mode entry. Could you upgrade the firmware one more time with this one?
https://raw.github.com/fransschreuder/usbpicprog/master/trunk/uc_code/uc_code.hex
I am sorry it takes so long.
Frans
Hi Frans, I tryed this new firmware but without luck... The problem seems to be worst than with the last firmware... now it always fail when verifying the code memory.
Are you been able to program this chips with this new firmware?
If I just program data and configuration memory everything seems to be ok... the problem is with the code memory...
Pablo
Frans: what I still don't understand is why a shorter code is programmed without any problem. When I try with a bigger one not even the data or the configuration memory are written...
Pablo.
Frans: with this new firmware, if I don't use the 9V zener it works perfectly...
I tryed to program several chips and always succeed to do it.
Thanks...
I only hope not damaging the chips for not using the 9V zener :)
Thanks again for such good application.
Pablo
Hi Frans... I'm here again... with your last firmware I've been programming the 16f1825 without any problema till now. This time the problem seems to be the algorithm used for this kind of chip...
I attached a hex file. I'm not been able to program it on a 1825, but if I add a couple of instruction to the code and compile it again I can program it without any problem.
This behavior happens every time I try to program the chip... this hex never gets programmed and the other always finish ok.
If I try to program the same code in a 16f877A it works ok, so it seems to be something related just to the 16f1825...
Could you try to program this hex to a 1825 and reproduce the problem?
Any idea of what it could be the problem?
Thanks, Pablo
Hi Pablo,
It must be the 1825 that still executes software in some cases.
Unfortunately I can't test this week as I am away, I can try to implement the low voltage programming entry method, it probably has a better performance.
I can make changes, but it's difficult to try on hardware this week. Could you test if I make changes?
Frans
Ok... I can try.
Thanks
Frans and Pablo... adding my two cents here. I downloaded the problematic file and got an error: Error programming config memory. Under details, I noticed that it expected 0x80 at 0x0, but read 0xFF. Just to verify a theory, I manually changed the first byte (80) to FF, and tried programming again. This time the device programmed and verified correctly...
Other codes such as 90 also yield positive results, while others, e.g. 70, still result in the same error.
Oddly enough, other programs starting with 80 can be programmed without a hitch, so at this point I can only share these findings, but no logical explanation... I hope that at least this may provide another clue to help solve the issue.
Marcelo