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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>