usbpicprog-technical

[Usbpicprog-technical] [usbpicprog-technical] Re: New Pic controller...

[Frans S. <fra...@gm...>]

Hi Patrick,

I also send this to the mailing list, because it might be interesting
for others to read as well.
Have you already tried the other code (28 in stead of 50)? This code is
really a bitshift of the other one, so I think you must have looked
wrong while measuring.
It could also be that the MCLR entry is alright, but that the code for
reading is different from other PIC18F devices.
It is always difficult to introduce a new PIC family. Microchip likes it
to put some slight differences in every programming specification,
probably just to make our life miserable!
I will have a look at the code more thoroughly.

Frans


On 09/22/2010 01:00 AM, Patrick NIES wrote:
>
> Hi Frans,
>
> First, the piece of code I send last time was not good. For the delays
> to work I forget the ''lasttick=tick;'' before the
> ''while((tick-lasttick)<6)continue;'' line.
>
> I've replaced these lines by some ''DelayMs(6)'' but no response of
> the PIC. After five days of work, searching and testing everything I
> can or I think of, still no response.
>
> Tired of that, *I finally buy a PicKit3 !!!*
>
> Of course very nice thing, works without problems with MPLab and it
> permits to confirm that my 27j53 was not (yet) killed by my numerous
> tests, and of course no way to drive it on Linux, back to the very
> irritating Vi$ta 8-(.
>
> I've done some ''reverse engineering'' to try to understand what we do
> wrong on UPP.
>
> I'll try to describe what I find with my very old Tektronix 2236 scope:
>
> The detection of the PicType is OK if I select the good device in the
> configuration menu in MPLab. Otherwise MPLab says the DevID do not match.
>
> The Pic is always supplied by the programmer (when choose in
> settings). I had doubts about that, thought that maybe the entry in
> programming mode was possible just after some VDD Off/ VDD On cycles.
>
> The delays: The MCLR ''high'' pulse have a duration of, approximately,
> 0.5Msec. Follow a MCLR ''low'' of 4Msec and the 32bits key. Not very
> new and conforms to the specs.
>
> More surprising: The 32 bits key is not the same as in the datasheet.
> Instead of 4D 43 48 50 I find 4D 43 24 28 !!! I must confirm that
> because I have just 5 seconds to read my scope screen during PicKit3
> read the code memory of the Pic, and I'm not very certain...
>
> Still searching for the truth !!! ;-)
>
> Have a nice Week End,
>
> Patrick
>
>
>
> Frans Schreuder a écrit :
>> Hi Patrick,
>>
>> I have added your additions to the subversion repository.
>> Thanks!
>>
>> Frans
>>
>> On 09/17/2010 01:29 AM, Patrick NIES wrote:
>>>
>>> Hi Frans,
>>>
>>> Two things:
>>>
>>> The capacitor on the VDDCore Pin must be between 5.4 and 18MF. I put
>>> 10MF here.
>>>
>>> The P19 time is largely greater than the one you have write =>
>>> 4Msec. I have added a 6Msec time to be safe, and another 6Msec
>>> between Vdd rise and first MCLR rise.
>>>
>>> In prog_lolvl.c:/
>>> /
>>>
>>> /
>>> if(picfamily==PIC18J)/
>>>
>>> / {/
>>>
>>> / TRISPGD_LOW = 0;/
>>>
>>> / PGD_LOW = 0; //PGD and PGC to 3.3V mode (output)/
>>>
>>> / TRISPGC_LOW = 0;/
>>>
>>> / PGC_LOW = 0;/
>>>
>>> / VDD=0; //VDD high,/
>>>
>>> */while((tick-lasttick)<6)continue;/*
>>>
>>> / clock_delay(); //P13 = 100ns min/
>>>
>>> / VPP_RUN=1; //VPP to 4.5V/
>>>
>>> / VPP_RUN=0; //and immediately back to 0.../
>>>
>>> */while((tick-lasttick)<6)continue;/*
>>>
>>> / clock_delay(); //P19 = 40ns min/
>>>
>>> / //write 0x4D43, high to low, other than the rest of the commands
>>> which are low to high.../
>>>
>>> / //0x3D43 => 0100 1101 0100 0011/
>>>
>>> / //from low to high => 1100 0010 1011 0010/
>>>
>>> / //0xC2B2 /
>>>
>>> / pic_send_word(0xC2B2);/
>>>
>>> / //write 0x4850 => 0100 1000 0101 0000 => 0000 1010 0001 0010 =>
>>> 0x0A12/
>>>
>>> / pic_send_word(0x0A12);/
>>>
>>> / VPP_RUN=1; /
>>>
>>> / return;/
>>>
>>> / }/
>>>
>>> Not yet tested.
>>>
>>> Cheers,
>>>
>>> Patrick
>>>
>>>
>>> Frans Schreuder a écrit :
>>>> Dear Patrick,
>>>>
>>>> This 32 bit key is implemented, however I have not gotten it to
>>>> work yet.
>>>> I will try to implement the X7J53 devices if you want to try them out.
>>>>
>>>> Frans.
>>>>
>>>> On 09/16/2010 10:13 AM, Patrick NIES wrote:
>>>>>
>>>>> Yes,
>>>>>
>>>>> /Entry into ICSP modes for PIC18F2XJXX/4XJXX family
>>>>> devices is somewhat different than previous PIC18
>>>>> devices. As shown in Figure 2-6, entering ICSP
>>>>> Program/Verify mode requires three steps:
>>>>> 1.   Voltage is briefly applied to the MCLR pin.
>>>>> 2.   A 32-bit key sequence is presented on PGD.
>>>>> 3.   Voltage is reapplied to MCLR and held.
>>>>> *The programming voltage applied to MCLR is VIH, or
>>>>> essentially, VDD*. There is no minimum time requirement
>>>>> for holding at VIH. After VIH is removed, an interval of at
>>>>> least P19 must elapse before presenting the key
>>>>> sequence on PGD.
>>>>>
>>>>> /Although the MCLR pin is 5.5V tolerant, in the programing specs
>>>>> VIH must not exceed VDD.
>>>>>
>>>>> I'll try with a zener diode...
>>>>>
>>>>> Patrick
>>>>> /
>>>>>
>>>>> /
>>>>>
>>>>> Frans Schreuder a écrit :
>>>>>> Dear Patrick,
>>>>>>
>>>>>> It is not that easy, also the 24J10 is not yet recognized. Please
>>>>>> do not connect them yet as I am not even sure if they might be
>>>>>> destroyed by usbpicprog.
>>>>>> I am still considering if it might be necessary to implement
>>>>>> another 3.3V zener diode on VPP while programming the 18FXXJXX
>>>>>> devices.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>>
>>>>>> Frans Schreuder
>>>>>>
>>>>>> On 09/16/2010 01:25 AM, Patrick NIES wrote:
>>>>>>>
>>>>>>> Hi Frans,
>>>>>>>
>>>>>>> Could you please implement the 18f27j53 and the 18f47j53 ?
>>>>>>>
>>>>>>> I begin today some tests with this devices and it would be nice
>>>>>>> if they be recognised by UPP.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Patrick
>>>>>>>
>>>>>>> Frans Schreuder a écrit :
>>>>>>>> Hi Patrick,
>>>>>>>>
>>>>>>>> I will need some more time on the 24J10, but as soon as it is
>>>>>>>> working the 27j53 will be peanuts as well.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Frans
>>>>>>>>
>>>>>>>> On 08/26/2010 01:14 AM, Patrick NIES wrote:
>>>>>>>>> Hi Frans,
>>>>>>>>>
>>>>>>>>> For a new project I would use a 18f27j53. I have seen that you
>>>>>>>>> have implemented and done some tests with 18f24j10 (with same
>>>>>>>>> programming specs) apparently unsuccessful as you mark it as
>>>>>>>>> "not working".
>>>>>>>>>
>>>>>>>>> Do you think it needs a little more time to spend to make it
>>>>>>>>> work or it seems to bee very hard to find what's wrong with
>>>>>>>>> these controllers ???
>>>>>>>>>  
>>>>>>>>> Thanks for your response.
>>>>>>>>>  
>>>>>>>>> Cheers,
>>>>>>>>>  
>>>>>>>>> Patrick
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

Re: [Usbpicprog-technical] [usbpicprog-technical] Re: New Pic controller...

[Frans S. <fra...@gm...>]

Hi Patrick,

That's great news! I am going to try the new code right now!
I will put the new code in subversion (except of course the replacement
of the devid bits)
I have now added all the 2XJXX and 4XJXX to the upp_wx application.

Frans




On 09/23/2010 02:32 AM, Patrick NIES wrote:
> Hi Frans,
>
> Good news, I finally success !!!
>
> The 32 bits key 4D 43 48 50 was alright, I just misinterpreted my
> scope screen.
>
> All the other pieces of code (read, write, erase...) are the same as
> for the 18Fxxxx.
>
> The only thing that we forget was the P12 delay (0.4Msec) before
> sending commands.
>
> I have rewritten all this ICSP entry mode and add a more clear
> specific function to send the key in prog_lolvl.c. However it works
> the same with yours:
> /
> void set_vdd_vpp(PICTYPE pictype, PICFAMILY picfamily,char level)/
> /{/
> / unsigned int i;/
> /
> if(level==1)/
> / {/
>
> / TRISPGC =0; //PGC output/
>  
> / if(picfamily==PIC18J)/
> / {/
> / TRISPGD=0; //needed to refresh, sometimes.../
> / TRISPGC=0;/
> / VPP_RUN=0; //MCLR low/
> / VDD=0; //VDD high,/
> / DelayMs(10); //P13 = 100ns min => far more here for the supply to
> stabilize /
> / TRISPGD_LOW = 0;/
> / PGD_LOW = 0; //PGD and PGC to 3.3V mode (output)/
> / TRISPGC_LOW = 0;/
> / PGC_LOW = 0;/
> /
> /
> / VPP_RUN=1; //VPP to 4.5V/
> / for(i=0;i<300;i++)continue; //aprox 0.5ms/
> / VPP_RUN=0; //and back to 0.../
> / DelayMs(4); //P19 = 4ms min/
> / //write 0x4D43, high to low, other than the rest of the commands
> which are low to high.../
> / //0x3D43 => 0100 1101 0100 0011/
> / //from low to high => 1100 0010 1011 0010/
> / //0xC2B2 /
> ///// pic_send_word(0xC2B2);/
> / //write 0x4850 => 0100 1000 0101 0000 => 0000 1010 0001 0010 => 0x0A12/
> ///// pic_send_word(0x0A12);/
> / pic_send_key(0x4D43,0x4850);/
> /// clock_delay(); //P20 = 50ns min/
> / VPP_RUN=1; //MCLR released /
> / DelayMs(1); //P12 = 0.4Msec min/
>
> / return;/
> / }/
> …
> /
> void pic_send_key(unsigned int keyMsb, unsigned int keyLsb)
> {
> char i;
> for(i=0;i<16;i++)
> {
> if(keyMsb&0x8000)PGD=1;
> else PGD=0;
> PGC=1;
> keyMsb<<=1;
> PGC=0;
> }
> clock_delay();
> for(i=0;i<16;i++)
> {
> if(keyLsb&0x8000)PGD=1;
> else PGD=0;
> PGC=1;
> keyLsb<<=1;
> PGC=0;
> }
> clock_delay();
> } /
>
> I can send you the complete files.
>
> All is OK with a 18F27J53 except the verification of the configuration
> bits. It's normal as I had to replace the DevId of the 27J53 by the
> one of the 45J10 in upp.c:
>
> /case CMD_READ_ID:
> ...
> case PIC18:
> case PIC18J:
> read_code(picfamily,pictype,0x3FFFFE,(unsigned
> char*)output_buffer,2,3); //devid is at location 0x3ffffe for PIC18
> devices
> i*f (output_buffer[0] == 0x60) output_buffer[0] = 0x20;    //replace
> DevIds
> if (output_buffer[1] == 0x58) output_buffer[1] = 0x1C; *
>
> break;
> … /
>
> I have made some tries to add these PICs in the .xml files and
> recompile them but they are still not recognized by the UPP software.
> I don't know how to calculate or where to find the upp_devidmask and
> many other parameters.
>
> For these tests I also modified the hardware to be sure there was no
> 5V or 12V VPP applied to the target device... too long to expain now...
>
> Cheers,
>
> Patrick
>
>
>
>
>
> Frans Schreuder a écrit :
>> Hi Patrick,
>>
>> I also send this to the mailing list, because it might be interesting
>> for others to read as well.
>> Have you already tried the other code (28 in stead of 50)? This code
>> is really a bitshift of the other one, so I think you must have
>> looked wrong while measuring.
>> It could also be that the MCLR entry is alright, but that the code
>> for reading is different from other PIC18F devices.
>> It is always difficult to introduce a new PIC family. Microchip likes
>> it to put some slight differences in every programming specification,
>> probably just to make our life miserable!
>> I will have a look at the code more thoroughly.
>>
>> Frans
>>
>>
>> On 09/22/2010 01:00 AM, Patrick NIES wrote:
>>>
>>> Hi Frans,
>>>
>>> First, the piece of code I send last time was not good. For the
>>> delays to work I forget the ''lasttick=tick;'' before the
>>> ''while((tick-lasttick)<6)continue;'' line.
>>>
>>> I've replaced these lines by some ''DelayMs(6)'' but no response of
>>> the PIC. After five days of work, searching and testing everything I
>>> can or I think of, still no response.
>>>
>>> Tired of that, *I finally buy a PicKit3 !!!*
>>>
>>> Of course very nice thing, works without problems with MPLab and it
>>> permits to confirm that my 27j53 was not (yet) killed by my numerous
>>> tests, and of course no way to drive it on Linux, back to the very
>>> irritating Vi$ta 8-(.
>>>
>>> I've done some ''reverse engineering'' to try to understand what we
>>> do wrong on UPP.
>>>
>>> I'll try to describe what I find with my very old Tektronix 2236 scope:
>>>
>>> The detection of the PicType is OK if I select the good device in
>>> the configuration menu in MPLab. Otherwise MPLab says the DevID do
>>> not match.
>>>
>>> The Pic is always supplied by the programmer (when choose in
>>> settings). I had doubts about that, thought that maybe the entry in
>>> programming mode was possible just after some VDD Off/ VDD On cycles.
>>>
>>> The delays: The MCLR ''high'' pulse have a duration of,
>>> approximately, 0.5Msec. Follow a MCLR ''low'' of 4Msec and the
>>> 32bits key. Not very new and conforms to the specs.
>>>
>>> More surprising: The 32 bits key is not the same as in the
>>> datasheet. Instead of 4D 43 48 50 I find 4D 43 24 28 !!! I must
>>> confirm that because I have just 5 seconds to read my scope screen
>>> during PicKit3 read the code memory of the Pic, and I'm not very
>>> certain...
>>>
>>> Still searching for the truth !!! ;-)
>>>
>>> Have a nice Week End,
>>>
>>> Patrick
>>>
>>>
>>>
>>> Frans Schreuder a écrit :
>>>> Hi Patrick,
>>>>
>>>> I have added your additions to the subversion repository.
>>>> Thanks!
>>>>
>>>> Frans
>>>>
>>>> On 09/17/2010 01:29 AM, Patrick NIES wrote:
>>>>>
>>>>> Hi Frans,
>>>>>
>>>>> Two things:
>>>>>
>>>>> The capacitor on the VDDCore Pin must be between 5.4 and 18MF. I
>>>>> put 10MF here.
>>>>>
>>>>> The P19 time is largely greater than the one you have write =>
>>>>> 4Msec. I have added a 6Msec time to be safe, and another 6Msec
>>>>> between Vdd rise and first MCLR rise.
>>>>>
>>>>> In prog_lolvl.c:/
>>>>> /
>>>>>
>>>>> /
>>>>> if(picfamily==PIC18J)/
>>>>>
>>>>> / {/
>>>>>
>>>>> / TRISPGD_LOW = 0;/
>>>>>
>>>>> / PGD_LOW = 0; //PGD and PGC to 3.3V mode (output)/
>>>>>
>>>>> / TRISPGC_LOW = 0;/
>>>>>
>>>>> / PGC_LOW = 0;/
>>>>>
>>>>> / VDD=0; //VDD high,/
>>>>>
>>>>> */while((tick-lasttick)<6)continue;/*
>>>>>
>>>>> / clock_delay(); //P13 = 100ns min/
>>>>>
>>>>> / VPP_RUN=1; //VPP to 4.5V/
>>>>>
>>>>> / VPP_RUN=0; //and immediately back to 0.../
>>>>>
>>>>> */while((tick-lasttick)<6)continue;/*
>>>>>
>>>>> / clock_delay(); //P19 = 40ns min/
>>>>>
>>>>> / //write 0x4D43, high to low, other than the rest of the commands
>>>>> which are low to high.../
>>>>>
>>>>> / //0x3D43 => 0100 1101 0100 0011/
>>>>>
>>>>> / //from low to high => 1100 0010 1011 0010/
>>>>>
>>>>> / //0xC2B2 /
>>>>>
>>>>> / pic_send_word(0xC2B2);/
>>>>>
>>>>> / //write 0x4850 => 0100 1000 0101 0000 => 0000 1010 0001 0010 =>
>>>>> 0x0A12/
>>>>>
>>>>> / pic_send_word(0x0A12);/
>>>>>
>>>>> / VPP_RUN=1; /
>>>>>
>>>>> / return;/
>>>>>
>>>>> / }/
>>>>>
>>>>> Not yet tested.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Patrick
>>>>>
>>>>>
>>>>> Frans Schreuder a écrit :
>>>>>> Dear Patrick,
>>>>>>
>>>>>> This 32 bit key is implemented, however I have not gotten it to
>>>>>> work yet.
>>>>>> I will try to implement the X7J53 devices if you want to try them
>>>>>> out.
>>>>>>
>>>>>> Frans.
>>>>>>
>>>>>> On 09/16/2010 10:13 AM, Patrick NIES wrote:
>>>>>>>
>>>>>>> Yes,
>>>>>>>
>>>>>>> /Entry into ICSP modes for PIC18F2XJXX/4XJXX family
>>>>>>> devices is somewhat different than previous PIC18
>>>>>>> devices. As shown in Figure 2-6, entering ICSP
>>>>>>> Program/Verify mode requires three steps:
>>>>>>> 1.   Voltage is briefly applied to the MCLR pin.
>>>>>>> 2.   A 32-bit key sequence is presented on PGD.
>>>>>>> 3.   Voltage is reapplied to MCLR and held.
>>>>>>> *The programming voltage applied to MCLR is VIH, or
>>>>>>> essentially, VDD*. There is no minimum time requirement
>>>>>>> for holding at VIH. After VIH is removed, an interval of at
>>>>>>> least P19 must elapse before presenting the key
>>>>>>> sequence on PGD.
>>>>>>>
>>>>>>> /Although the MCLR pin is 5.5V tolerant, in the programing specs
>>>>>>> VIH must not exceed VDD.
>>>>>>>
>>>>>>> I'll try with a zener diode...
>>>>>>>
>>>>>>> Patrick
>>>>>>> /
>>>>>>>
>>>>>>> /
>>>>>>>
>>>>>>> Frans Schreuder a écrit :
>>>>>>>> Dear Patrick,
>>>>>>>>
>>>>>>>> It is not that easy, also the 24J10 is not yet recognized.
>>>>>>>> Please do not connect them yet as I am not even sure if they
>>>>>>>> might be destroyed by usbpicprog.
>>>>>>>> I am still considering if it might be necessary to implement
>>>>>>>> another 3.3V zener diode on VPP while programming the 18FXXJXX
>>>>>>>> devices.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> Frans Schreuder
>>>>>>>>
>>>>>>>> On 09/16/2010 01:25 AM, Patrick NIES wrote:
>>>>>>>>>
>>>>>>>>> Hi Frans,
>>>>>>>>>
>>>>>>>>> Could you please implement the 18f27j53 and the 18f47j53 ?
>>>>>>>>>
>>>>>>>>> I begin today some tests with this devices and it would be
>>>>>>>>> nice if they be recognised by UPP.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Patrick
>>>>>>>>>
>>>>>>>>> Frans Schreuder a écrit :
>>>>>>>>>> Hi Patrick,
>>>>>>>>>>
>>>>>>>>>> I will need some more time on the 24J10, but as soon as it is
>>>>>>>>>> working the 27j53 will be peanuts as well.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Frans
>>>>>>>>>>
>>>>>>>>>> On 08/26/2010 01:14 AM, Patrick NIES wrote:
>>>>>>>>>>> Hi Frans,
>>>>>>>>>>>
>>>>>>>>>>> For a new project I would use a 18f27j53. I have seen that
>>>>>>>>>>> you have implemented and done some tests with 18f24j10 (with
>>>>>>>>>>> same programming specs) apparently unsuccessful as you mark
>>>>>>>>>>> it as "not working".
>>>>>>>>>>>
>>>>>>>>>>> Do you think it needs a little more time to spend to make it
>>>>>>>>>>> work or it seems to bee very hard to find what's wrong with
>>>>>>>>>>> these controllers ???
>>>>>>>>>>>  
>>>>>>>>>>> Thanks for your response.
>>>>>>>>>>>  
>>>>>>>>>>> Cheers,
>>>>>>>>>>>  
>>>>>>>>>>> Patrick
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

Re: [Usbpicprog-technical] [usbpicprog-technical] Re: New Pic controller...

[Frans S. <fra...@gm...>]

Hi Patrick,

I have already put your code in the SVN tree, but I omitted the send_key
function, because it was the same anyway.
It is now also working for me!
I have also added your name in "developers" in the about usbpicprog
dialog :P

Frans

On 09/23/2010 10:31 AM, Patrick NIES wrote:
> OK, I'll try it.
>
> Anyway, only the prog_lolvl.c file has to be updated.
>
> Patrick
>
> Frans Schreuder a écrit :
>> Hi Patrick,
>>
>> It's just replying to usb...@li...
>> and there must be [usbpicprog-technical] in the subject.
>>
>> Did you know that you also have write access to subversion?
>>
>> Frans
>>
>> On 09/23/2010 09:39 AM, Patrick NIES wrote:
>>> Hi,
>>>
>>> How can I post something to the mailing list ? When I'm log in, I
>>> have nowhere to click.
>>>
>>> Maybe should I renew my account ?
>>>
>>> Patrick
>>>
>>> Frans Schreuder a écrit :
>>>> Hi Patrick,
>>>>
>>>> I also send this to the mailing list, because it might be
>>>> interesting for others to read as well.
>>>> Have you already tried the other code (28 in stead of 50)? This
>>>> code is really a bitshift of the other one, so I think you must
>>>> have looked wrong while measuring.
>>>> It could also be that the MCLR entry is alright, but that the code
>>>> for reading is different from other PIC18F devices.
>>>> It is always difficult to introduce a new PIC family. Microchip
>>>> likes it to put some slight differences in every programming
>>>> specification, probably just to make our life miserable!
>>>> I will have a look at the code more thoroughly.
>>>>
>>>> Frans
>>>>
>>>>
>>>> On 09/22/2010 01:00 AM, Patrick NIES wrote:
>>>>>
>>>>> Hi Frans,
>>>>>
>>>>> First, the piece of code I send last time was not good. For the
>>>>> delays to work I forget the ''lasttick=tick;'' before the
>>>>> ''while((tick-lasttick)<6)continue;'' line.
>>>>>
>>>>> I've replaced these lines by some ''DelayMs(6)'' but no response
>>>>> of the PIC. After five days of work, searching and testing
>>>>> everything I can or I think of, still no response.
>>>>>
>>>>> Tired of that, *I finally buy a PicKit3 !!!*
>>>>>
>>>>> Of course very nice thing, works without problems with MPLab and
>>>>> it permits to confirm that my 27j53 was not (yet) killed by my
>>>>> numerous tests, and of course no way to drive it on Linux, back to
>>>>> the very irritating Vi$ta 8-(.
>>>>>
>>>>> I've done some ''reverse engineering'' to try to understand what
>>>>> we do wrong on UPP.
>>>>>
>>>>> I'll try to describe what I find with my very old Tektronix 2236
>>>>> scope:
>>>>>
>>>>> The detection of the PicType is OK if I select the good device in
>>>>> the configuration menu in MPLab. Otherwise MPLab says the DevID do
>>>>> not match.
>>>>>
>>>>> The Pic is always supplied by the programmer (when choose in
>>>>> settings). I had doubts about that, thought that maybe the entry
>>>>> in programming mode was possible just after some VDD Off/ VDD On
>>>>> cycles.
>>>>>
>>>>> The delays: The MCLR ''high'' pulse have a duration of,
>>>>> approximately, 0.5Msec. Follow a MCLR ''low'' of 4Msec and the
>>>>> 32bits key. Not very new and conforms to the specs.
>>>>>
>>>>> More surprising: The 32 bits key is not the same as in the
>>>>> datasheet. Instead of 4D 43 48 50 I find 4D 43 24 28 !!! I must
>>>>> confirm that because I have just 5 seconds to read my scope screen
>>>>> during PicKit3 read the code memory of the Pic, and I'm not very
>>>>> certain...
>>>>>
>>>>> Still searching for the truth !!! ;-)
>>>>>
>>>>> Have a nice Week End,
>>>>>
>>>>> Patrick
>>>>>
>>>>>
>>>>>
>>>>> Frans Schreuder a écrit :
>>>>>> Hi Patrick,
>>>>>>
>>>>>> I have added your additions to the subversion repository.
>>>>>> Thanks!
>>>>>>
>>>>>> Frans
>>>>>>
>>>>>> On 09/17/2010 01:29 AM, Patrick NIES wrote:
>>>>>>>
>>>>>>> Hi Frans,
>>>>>>>
>>>>>>> Two things:
>>>>>>>
>>>>>>> The capacitor on the VDDCore Pin must be between 5.4 and 18MF. I
>>>>>>> put 10MF here.
>>>>>>>
>>>>>>> The P19 time is largely greater than the one you have write =>
>>>>>>> 4Msec. I have added a 6Msec time to be safe, and another 6Msec
>>>>>>> between Vdd rise and first MCLR rise.
>>>>>>>
>>>>>>> In prog_lolvl.c:/
>>>>>>> /
>>>>>>>
>>>>>>> /
>>>>>>> if(picfamily==PIC18J)/
>>>>>>>
>>>>>>> / {/
>>>>>>>
>>>>>>> / TRISPGD_LOW = 0;/
>>>>>>>
>>>>>>> / PGD_LOW = 0; //PGD and PGC to 3.3V mode (output)/
>>>>>>>
>>>>>>> / TRISPGC_LOW = 0;/
>>>>>>>
>>>>>>> / PGC_LOW = 0;/
>>>>>>>
>>>>>>> / VDD=0; //VDD high,/
>>>>>>>
>>>>>>> */while((tick-lasttick)<6)continue;/*
>>>>>>>
>>>>>>> / clock_delay(); //P13 = 100ns min/
>>>>>>>
>>>>>>> / VPP_RUN=1; //VPP to 4.5V/
>>>>>>>
>>>>>>> / VPP_RUN=0; //and immediately back to 0.../
>>>>>>>
>>>>>>> */while((tick-lasttick)<6)continue;/*
>>>>>>>
>>>>>>> / clock_delay(); //P19 = 40ns min/
>>>>>>>
>>>>>>> / //write 0x4D43, high to low, other than the rest of the
>>>>>>> commands which are low to high.../
>>>>>>>
>>>>>>> / //0x3D43 => 0100 1101 0100 0011/
>>>>>>>
>>>>>>> / //from low to high => 1100 0010 1011 0010/
>>>>>>>
>>>>>>> / //0xC2B2 /
>>>>>>>
>>>>>>> / pic_send_word(0xC2B2);/
>>>>>>>
>>>>>>> / //write 0x4850 => 0100 1000 0101 0000 => 0000 1010 0001 0010
>>>>>>> => 0x0A12/
>>>>>>>
>>>>>>> / pic_send_word(0x0A12);/
>>>>>>>
>>>>>>> / VPP_RUN=1; /
>>>>>>>
>>>>>>> / return;/
>>>>>>>
>>>>>>> / }/
>>>>>>>
>>>>>>> Not yet tested.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Patrick
>>>>>>>
>>>>>>>
>>>>>>> Frans Schreuder a écrit :
>>>>>>>> Dear Patrick,
>>>>>>>>
>>>>>>>> This 32 bit key is implemented, however I have not gotten it to
>>>>>>>> work yet.
>>>>>>>> I will try to implement the X7J53 devices if you want to try
>>>>>>>> them out.
>>>>>>>>
>>>>>>>> Frans.
>>>>>>>>
>>>>>>>> On 09/16/2010 10:13 AM, Patrick NIES wrote:
>>>>>>>>>
>>>>>>>>> Yes,
>>>>>>>>>
>>>>>>>>> /Entry into ICSP modes for PIC18F2XJXX/4XJXX family
>>>>>>>>> devices is somewhat different than previous PIC18
>>>>>>>>> devices. As shown in Figure 2-6, entering ICSP
>>>>>>>>> Program/Verify mode requires three steps:
>>>>>>>>> 1.   Voltage is briefly applied to the MCLR pin.
>>>>>>>>> 2.   A 32-bit key sequence is presented on PGD.
>>>>>>>>> 3.   Voltage is reapplied to MCLR and held.
>>>>>>>>> *The programming voltage applied to MCLR is VIH, or
>>>>>>>>> essentially, VDD*. There is no minimum time requirement
>>>>>>>>> for holding at VIH. After VIH is removed, an interval of at
>>>>>>>>> least P19 must elapse before presenting the key
>>>>>>>>> sequence on PGD.
>>>>>>>>>
>>>>>>>>> /Although the MCLR pin is 5.5V tolerant, in the programing
>>>>>>>>> specs VIH must not exceed VDD.
>>>>>>>>>
>>>>>>>>> I'll try with a zener diode...
>>>>>>>>>
>>>>>>>>> Patrick
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> Frans Schreuder a écrit :
>>>>>>>>>> Dear Patrick,
>>>>>>>>>>
>>>>>>>>>> It is not that easy, also the 24J10 is not yet recognized.
>>>>>>>>>> Please do not connect them yet as I am not even sure if they
>>>>>>>>>> might be destroyed by usbpicprog.
>>>>>>>>>> I am still considering if it might be necessary to implement
>>>>>>>>>> another 3.3V zener diode on VPP while programming the
>>>>>>>>>> 18FXXJXX devices.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Frans Schreuder
>>>>>>>>>>
>>>>>>>>>> On 09/16/2010 01:25 AM, Patrick NIES wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Frans,
>>>>>>>>>>>
>>>>>>>>>>> Could you please implement the 18f27j53 and the 18f47j53 ?
>>>>>>>>>>>
>>>>>>>>>>> I begin today some tests with this devices and it would be
>>>>>>>>>>> nice if they be recognised by UPP.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Patrick
>>>>>>>>>>>
>>>>>>>>>>> Frans Schreuder a écrit :
>>>>>>>>>>>> Hi Patrick,
>>>>>>>>>>>>
>>>>>>>>>>>> I will need some more time on the 24J10, but as soon as it
>>>>>>>>>>>> is working the 27j53 will be peanuts as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>
>>>>>>>>>>>> Frans
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/26/2010 01:14 AM, Patrick NIES wrote:
>>>>>>>>>>>>> Hi Frans,
>>>>>>>>>>>>>
>>>>>>>>>>>>> For a new project I would use a 18f27j53. I have seen that
>>>>>>>>>>>>> you have implemented and done some tests with 18f24j10
>>>>>>>>>>>>> (with same programming specs) apparently unsuccessful as
>>>>>>>>>>>>> you mark it as "not working".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you think it needs a little more time to spend to make
>>>>>>>>>>>>> it work or it seems to bee very hard to find what's wrong
>>>>>>>>>>>>> with these controllers ???
>>>>>>>>>>>>>  
>>>>>>>>>>>>> Thanks for your response.
>>>>>>>>>>>>>  
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>  
>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>