usbpicprog-technical

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

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

Dear Fatih,

It would be great if you would test this on your hardware.
If this doesn't help, the only other delay that can be causing the error
is the one in the erase procedure. Could you also try to make that one
longer?

Regards,

Frans

On 04/15/2011 10:50 AM, fatih gokce wrote:
> Dear All,
> Since our hardware is not usbpicprog hw i could not try Frans's new
> firmware.
> As far as i see, Frans changed two lines in prog.c in terms of timing:
>
> 1- in
>
>         case P16F87X:    //same as P16F62X
>         case P16F84A:    //same as P16F62X
>         case P16F62XA:    //same as P16F62X
>         case P16F62X:
>         case P12F629:
>         case P12F61X:
>
> of write_code function
>
> DelayMs(2); -> DelayMs(10);
>
>
> 2- in case P16F87XA: of write_code function DelayMs(8); -> DelayMs(16);
>
> Frans, if there is something that i missed please correct me.
>
> I am planning to make these changes in our firmware without touching
> original delayMs function (while((tick-lasttick)<cnt)continue;) and
> test it with 16F877 (not 877A). But i hope i can do it in weekend.
>
> All the best,
> Fatih.
>
>
>
> On Fri, Apr 15, 2011 at 9:56 AM, Frans Schreuder
> <fra...@gm... <mailto:fra...@gm...>> wrote:
>
>     Dear Marcel,
>
>     It seems that Fatih solved the issue (at least for the 16F877) by
>     adding
>     more delay. I have now added more delay in the programming routine
>     only,
>     not doubled the delay-routine as Fatih did, but it should do the same
>     trick. Maybe something went wrong during erase, I'll try and see if
>     doubling the erase time could help.
>
>     Regards,
>
>     Frans
>
>     On 04/14/2011 11:45 PM, Marcel Konrad wrote:
>     > Dear Frans,
>     >
>     > I have tried your new firmware, but it didn't change anything
>     for me. Still the
>     > same error. I was hoping that this issue could be solved in
>     software, but now
>     > I think that I will try Marcelo's suggestion and add a 470u cap.
>     Will report
>     > back when I tried that.
>     >
>     > Kind regards
>     >
>     > Marcel
>     >
>     > Am Mittwoch, 13. April 2011, 16:32:28 schrieb Frans Schreuder:
>     >> Dear Fatih,
>     >>
>     >> I have increased the delay for the given processors in the
>     current git
>     >> repository. Could you upgrade your firmware with the file below?
>     >>
>     https://github.com/fransschreuder/usbpicprog/raw/master/trunk/uc_code/uc_co
>     >> de.hex
>     >>
>     >> Kind regards,
>     >>
>     >> Frans Schreuder
>     >>
>     >> On 04/11/2011 08:17 PM, fatih gokce wrote:
>     >>> Dear all,
>     >>> We faced with the same problem for 16F877 and it is solved by the
>     >>> following change in DelayMs routine of interrupt.c (in firmware)
>     >>>
>     >>> while((tick-lasttick)<(2*cnt))continue;
>     >>>
>     >>> Since our hardware is not exactly the same hardware of
>     usbpicprog (it
>     >>> is compatible with gtp-usb lite and has a 12 Mhz xtal ), I thought
>     >>> that it was only our problem. But after seeing last messages
>     of Marcel
>     >>> and Marcelo I want to share our solution.
>     >>>
>     >>> Frans, you are saying that you have tried more delays in
>     programming
>     >>> sequence but I do not know the length of your additional
>     delays and
>     >>> maybe you can also try 2*cnt solution. You will notice but I
>     should
>     >>> also indicate that this change is unnecessarily affecting the
>     >>> programming times of all PICs.
>     >>>
>     >>> I should also note that while compiling the firmware with
>     MPLAB we had
>     >>> to comment out some part of the code in prog.c (related to the
>     PICs we
>     >>> are not planning to use), since it was not fitting into the
>     program
>     >>> memory of 18F2550.
>     >>>
>     >>> Kindest regards,
>     >>> Fatih.
>     >>>
>     >>>
>     >>> On Mon, Apr 11, 2011 at 5:38 PM, Marcelo Maggi
>     <mm...@ho... <mailto:mm...@ho...>
>     >>>
>     >>> <mailto:mm...@ho... <mailto:mm...@ho...>>> wrote:
>     >>>     Thank you Frans for your prompt reply.
>     >>>
>     >>>     I fully agree that the noise comes from the USB power
>     line, since
>     >>>     I can see it even with the programmer disconnected. What I
>     also
>     >>>     noticed is that the mosfet is somehow amplifying the
>     noise, that
>     >>>     is the reason why I added a 100nF capacitor at the gate,
>     besides
>     >>>     the large one directly on the Vdd line after the mosfet.
>     The large
>     >>>     current as well as the time constant introduced by this
>     capacitor
>     >>>     were the concerns I had at the beginning, so I started testing
>     >>>     with lower values until I reached 470 uF, which seems a good
>     >>>     compromise between noise reduction and unwanted side effects.
>     >>>
>     >>>     Unfortunately this is not a solution for the PIC16F877A... it
>     >>>     keeps showing the erratic behavior I described in my previous
>     >>>     message.
>     >>>
>     >>>     I will appreciate if you could let me know if you find a
>     solution
>     >>>     in the future... I will keep experimenting from my side
>     and let
>     >>>     you know any progress.
>     >>>
>     >>>     Thank you again.
>     >>>
>     >>>     Best regards
>     >>>
>     >>>     Marcelo Maggi
>     >>>
>     >>>    
>     ---------------------------------------------------------------------
>     >>>     --- Date: Mon, 11 Apr 2011 08:58:30 +0200
>     >>>     From: fra...@gm...
>     <mailto:fra...@gm...> <mailto:fra...@gm...
>     <mailto:fra...@gm...>>
>     >>>     To: usb...@li...
>     <mailto:usb...@li...>
>     >>>     <mailto:usb...@li...
>     <mailto:usb...@li...>>
>     >>>     Subject: Re: [Usbpicprog-technical] Unstability when
>     programing
>     >>>     large pieces of code
>     >>>
>     >>>
>     >>>     Dear Marcelo Maggi,
>     >>>
>     >>>     I have indeed noticed this behaviour before, but not for
>     all pic
>     >>>     devices. It seems to happen only on some revisions of pics
>     and it
>     >>>     is very unpredictable. It also depends on the computer you are
>     >>>     using it on. I have been trying to add more delays in the
>     >>>     programming sequence, but that also didn't seem to help
>     much. At
>     >>>     least it is good to hear that there is a solution for the
>     >>>     behaviour for the 628A.
>     >>>     The funny thing is that the +5V is directly obtained from
>     the usb
>     >>>     power line of the computer and is only switched by one
>     mosfet. The
>     >>>     noise seems to come from the usb port in most of the
>     cases. Also
>     >>>     on the programmer, the +5V is stabilized with 4x 100nF and one
>     >>>     time 100nF after the mosfet directly on the VDD pin of the
>     output
>     >>>     port. A 470uF capacitor could do the job but also introduces a
>     >>>     large current while switching the VDD pin on (there is no
>     current
>     >>>     limiter) but if it works, there is no problem!
>     >>>
>     >>>     Kind regards,
>     >>>
>     >>>     Frans Schreuder
>     >>>
>     >>>     On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
>     >>>         Dear Frans:
>     >>>
>     >>>         Thank you for this excellent programmer; I built it
>     and I am
>     >>>         currently running the latest beta version (0.4.2), both
>     >>>         firmware and software (AMD64 version).
>     >>>
>     >>>         I have been through a few issues; while I solved some
>     of them,
>     >>>         I need your support with one.
>     >>>
>     >>>         First thing I noticed was that I had trouble when
>     trying to
>     >>>         program the PIF16F628A using more than half of the program
>     >>>         memory. The programming cycle goes OK, but  during the
>     verify
>     >>>         step there were problems reported (byte read different
>     from
>     >>>         what was expected). It used to happen at different
>     parts of
>     >>>         the code, and eventually I could have a few successful
>     >>>         attempts. Trying to find the cause of the problem, I
>     noticed
>     >>>         that Vdd (5 volts) was very noisy; I added a large
>     capacitor
>     >>>         (470 uF/16v) between Vdd and GND at the connector to
>     the ZIF
>     >>>         board (P1), and a 0.1 uF at the gate of Q3 (BS250).
>     With Vdd
>     >>>         now much cleaner, I can program the PIC16F628A with no
>     problem
>     >>>         each and every time. This may help reply the question from
>     >>>         another user in this forum (posted on April 10).
>     >>>
>     >>>         Now, I am trying to program larger PICs... I tried
>     with the
>     >>>         PIC16F877A, filling almost all of the program memory.
>     Now, I
>     >>>         have the same problem again; while verifying there are
>     errors
>     >>>         at different points of the program each time, with a few
>     >>>         successful attempts. Further stabilization of Vdd does not
>     >>>         help. What I noticed is that only a small portion of the
>     >>>         program is corrupted when it fails to verify. It may
>     happen at
>     >>>         different parts of the code each time, but the wrong
>     sequence
>     >>>         is always the same:
>     >>>
>     >>>         FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00
>     00 00 00
>     >>>         00 00 00 00 00 00 00 00 00 00 00
>     >>>
>     >>>         After this sequence, the program continues with the
>     right code.
>     >>>
>     >>>         Have you experienced this before? Any clue of what
>     could be
>     >>>         the reason with the information given?
>     >>>
>     >>>         Just for your reference, the same happens with the latest
>     >>>         stable version 0.4.1.
>     >>>
>     >>>         Thank you in advance for your ideas...
>     >>>
>     >>>         Best regards
>     >>>
>     >>>         Marcelo Maggi
>     >>>
>     >>>
>     >>>        
>     -----------------------------------------------------------------
>     >>>         ------------- Xperia(TM) PLAY
>     >>>         It's a major breakthrough. An authentic gaming
>     >>>         smartphone on the nation's most reliable network.
>     >>>         And it wants your games.
>     >>>         http://p.sf.net/sfu/verizon-sfdev
>     >>>
>     >>>
>     >>>         _______________________________________________
>     >>>         Usbpicprog-technical mailing list
>     >>>         Usb...@li...
>     <mailto:Usb...@li...>
>     >>>         <mailto:Usb...@li...
>     <mailto:Usb...@li...>>
>     >>>        
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technica
>     >>>         l
>     >>>
>     >>>    
>     ---------------------------------------------------------------------
>     >>>     --------- Xperia(TM) PLAY It's a major breakthrough. An
>     authentic
>     >>>     gaming smartphone on the nation's most reliable network.
>     And it
>     >>>     wants your games. http://p.sf.net/sfu/verizon-sfdev
>     >>>
>     >>>     _______________________________________________
>     >>>     Usbpicprog-technical mailing list
>     >>>     Usb...@li...
>     <mailto:Usb...@li...>
>     >>>     <mailto:Usb...@li...
>     <mailto:Usb...@li...>>
>     >>>    
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>     >>>
>     >>>    
>     ---------------------------------------------------------------------
>     >>>     --------- Xperia(TM) PLAY
>     >>>     It's a major breakthrough. An authentic gaming
>     >>>     smartphone on the nation's most reliable network.
>     >>>     And it wants your games.
>     >>>     http://p.sf.net/sfu/verizon-sfdev
>     >>>     _______________________________________________
>     >>>     Usbpicprog-technical mailing list
>     >>>     Usb...@li...
>     <mailto:Usb...@li...>
>     >>>     <mailto:Usb...@li...
>     <mailto:Usb...@li...>>
>     >>>    
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>     >>>
>     >>>
>     -------------------------------------------------------------------------
>     >>> ----- Xperia(TM) PLAY
>     >>> It's a major breakthrough. An authentic gaming
>     >>> smartphone on the nation's most reliable network.
>     >>> And it wants your games.
>     >>> http://p.sf.net/sfu/verizon-sfdev
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Usbpicprog-technical mailing list
>     >>> Usb...@li...
>     <mailto:Usb...@li...>
>     >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Benefiting from Server Virtualization: Beyond Initial Workload
>     > Consolidation -- Increasing the use of server virtualization is
>     a top
>     > priority.Virtualization can reduce costs, simplify management,
>     and improve
>     > application availability and disaster protection. Learn more
>     about boosting
>     > the value of server virtualization.
>     http://p.sf.net/sfu/vmware-sfdev2dev
>     > _______________________________________________
>     > Usbpicprog-technical mailing list
>     > Usb...@li...
>     <mailto:Usb...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>     ------------------------------------------------------------------------------
>     Benefiting from Server Virtualization: Beyond Initial Workload
>     Consolidation -- Increasing the use of server virtualization is a top
>     priority.Virtualization can reduce costs, simplify management, and
>     improve
>     application availability and disaster protection. Learn more about
>     boosting
>     the value of server virtualization.
>     http://p.sf.net/sfu/vmware-sfdev2dev
>     _______________________________________________
>     Usbpicprog-technical mailing list
>     Usb...@li...
>     <mailto:Usb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload 
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve 
> application availability and disaster protection. Learn more about boosting 
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

[fatih g. <gok...@gm...>]

Dear All,
Since our hardware is not usbpicprog hw i could not try Frans's new
firmware.
As far as i see, Frans changed two lines in prog.c in terms of timing:

1- in

        case P16F87X:    //same as P16F62X
        case P16F84A:    //same as P16F62X
        case P16F62XA:    //same as P16F62X
        case P16F62X:
        case P12F629:
        case P12F61X:

of write_code function

DelayMs(2); -> DelayMs(10);


2- in case P16F87XA: of write_code function DelayMs(8); -> DelayMs(16);

Frans, if there is something that i missed please correct me.

I am planning to make these changes in our firmware without touching
original delayMs function (while((tick-lasttick)<cnt)continue;) and test it
with 16F877 (not 877A). But i hope i can do it in weekend.

All the best,
Fatih.



On Fri, Apr 15, 2011 at 9:56 AM, Frans Schreuder
<fra...@gm...>wrote:

> Dear Marcel,
>
> It seems that Fatih solved the issue (at least for the 16F877) by adding
> more delay. I have now added more delay in the programming routine only,
> not doubled the delay-routine as Fatih did, but it should do the same
> trick. Maybe something went wrong during erase, I'll try and see if
> doubling the erase time could help.
>
> Regards,
>
> Frans
>
> On 04/14/2011 11:45 PM, Marcel Konrad wrote:
> > Dear Frans,
> >
> > I have tried your new firmware, but it didn't change anything for me.
> Still the
> > same error. I was hoping that this issue could be solved in software, but
> now
> > I think that I will try Marcelo's suggestion and add a 470u cap. Will
> report
> > back when I tried that.
> >
> > Kind regards
> >
> > Marcel
> >
> > Am Mittwoch, 13. April 2011, 16:32:28 schrieb Frans Schreuder:
> >> Dear Fatih,
> >>
> >> I have increased the delay for the given processors in the current git
> >> repository. Could you upgrade your firmware with the file below?
> >>
> https://github.com/fransschreuder/usbpicprog/raw/master/trunk/uc_code/uc_co
> >> de.hex
> >>
> >> Kind regards,
> >>
> >> Frans Schreuder
> >>
> >> On 04/11/2011 08:17 PM, fatih gokce wrote:
> >>> Dear all,
> >>> We faced with the same problem for 16F877 and it is solved by the
> >>> following change in DelayMs routine of interrupt.c (in firmware)
> >>>
> >>> while((tick-lasttick)<(2*cnt))continue;
> >>>
> >>> Since our hardware is not exactly the same hardware of usbpicprog (it
> >>> is compatible with gtp-usb lite and has a 12 Mhz xtal ), I thought
> >>> that it was only our problem. But after seeing last messages of Marcel
> >>> and Marcelo I want to share our solution.
> >>>
> >>> Frans, you are saying that you have tried more delays in programming
> >>> sequence but I do not know the length of your additional delays and
> >>> maybe you can also try 2*cnt solution. You will notice but I should
> >>> also indicate that this change is unnecessarily affecting the
> >>> programming times of all PICs.
> >>>
> >>> I should also note that while compiling the firmware with MPLAB we had
> >>> to comment out some part of the code in prog.c (related to the PICs we
> >>> are not planning to use), since it was not fitting into the program
> >>> memory of 18F2550.
> >>>
> >>> Kindest regards,
> >>> Fatih.
> >>>
> >>>
> >>> On Mon, Apr 11, 2011 at 5:38 PM, Marcelo Maggi <mm...@ho...
> >>>
> >>> <mailto:mm...@ho...>> wrote:
> >>>     Thank you Frans for your prompt reply.
> >>>
> >>>     I fully agree that the noise comes from the USB power line, since
> >>>     I can see it even with the programmer disconnected. What I also
> >>>     noticed is that the mosfet is somehow amplifying the noise, that
> >>>     is the reason why I added a 100nF capacitor at the gate, besides
> >>>     the large one directly on the Vdd line after the mosfet. The large
> >>>     current as well as the time constant introduced by this capacitor
> >>>     were the concerns I had at the beginning, so I started testing
> >>>     with lower values until I reached 470 uF, which seems a good
> >>>     compromise between noise reduction and unwanted side effects.
> >>>
> >>>     Unfortunately this is not a solution for the PIC16F877A... it
> >>>     keeps showing the erratic behavior I described in my previous
> >>>     message.
> >>>
> >>>     I will appreciate if you could let me know if you find a solution
> >>>     in the future... I will keep experimenting from my side and let
> >>>     you know any progress.
> >>>
> >>>     Thank you again.
> >>>
> >>>     Best regards
> >>>
> >>>     Marcelo Maggi
> >>>
> >>>
> ---------------------------------------------------------------------
> >>>     --- Date: Mon, 11 Apr 2011 08:58:30 +0200
> >>>     From: fra...@gm... <mailto:fra...@gm...>
> >>>     To: usb...@li...
> >>>     <mailto:usb...@li...>
> >>>     Subject: Re: [Usbpicprog-technical] Unstability when programing
> >>>     large pieces of code
> >>>
> >>>
> >>>     Dear Marcelo Maggi,
> >>>
> >>>     I have indeed noticed this behaviour before, but not for all pic
> >>>     devices. It seems to happen only on some revisions of pics and it
> >>>     is very unpredictable. It also depends on the computer you are
> >>>     using it on. I have been trying to add more delays in the
> >>>     programming sequence, but that also didn't seem to help much. At
> >>>     least it is good to hear that there is a solution for the
> >>>     behaviour for the 628A.
> >>>     The funny thing is that the +5V is directly obtained from the usb
> >>>     power line of the computer and is only switched by one mosfet. The
> >>>     noise seems to come from the usb port in most of the cases. Also
> >>>     on the programmer, the +5V is stabilized with 4x 100nF and one
> >>>     time 100nF after the mosfet directly on the VDD pin of the output
> >>>     port. A 470uF capacitor could do the job but also introduces a
> >>>     large current while switching the VDD pin on (there is no current
> >>>     limiter) but if it works, there is no problem!
> >>>
> >>>     Kind regards,
> >>>
> >>>     Frans Schreuder
> >>>
> >>>     On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
> >>>         Dear Frans:
> >>>
> >>>         Thank you for this excellent programmer; I built it and I am
> >>>         currently running the latest beta version (0.4.2), both
> >>>         firmware and software (AMD64 version).
> >>>
> >>>         I have been through a few issues; while I solved some of them,
> >>>         I need your support with one.
> >>>
> >>>         First thing I noticed was that I had trouble when trying to
> >>>         program the PIF16F628A using more than half of the program
> >>>         memory. The programming cycle goes OK, but  during the verify
> >>>         step there were problems reported (byte read different from
> >>>         what was expected). It used to happen at different parts of
> >>>         the code, and eventually I could have a few successful
> >>>         attempts. Trying to find the cause of the problem, I noticed
> >>>         that Vdd (5 volts) was very noisy; I added a large capacitor
> >>>         (470 uF/16v) between Vdd and GND at the connector to the ZIF
> >>>         board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd
> >>>         now much cleaner, I can program the PIC16F628A with no problem
> >>>         each and every time. This may help reply the question from
> >>>         another user in this forum (posted on April 10).
> >>>
> >>>         Now, I am trying to program larger PICs... I tried with the
> >>>         PIC16F877A, filling almost all of the program memory. Now, I
> >>>         have the same problem again; while verifying there are errors
> >>>         at different points of the program each time, with a few
> >>>         successful attempts. Further stabilization of Vdd does not
> >>>         help. What I noticed is that only a small portion of the
> >>>         program is corrupted when it fails to verify. It may happen at
> >>>         different parts of the code each time, but the wrong sequence
> >>>         is always the same:
> >>>
> >>>         FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00
> >>>         00 00 00 00 00 00 00 00 00 00 00
> >>>
> >>>         After this sequence, the program continues with the right code.
> >>>
> >>>         Have you experienced this before? Any clue of what could be
> >>>         the reason with the information given?
> >>>
> >>>         Just for your reference, the same happens with the latest
> >>>         stable version 0.4.1.
> >>>
> >>>         Thank you in advance for your ideas...
> >>>
> >>>         Best regards
> >>>
> >>>         Marcelo Maggi
> >>>
> >>>
> >>>
> -----------------------------------------------------------------
> >>>         ------------- Xperia(TM) PLAY
> >>>         It's a major breakthrough. An authentic gaming
> >>>         smartphone on the nation's most reliable network.
> >>>         And it wants your games.
> >>>         http://p.sf.net/sfu/verizon-sfdev
> >>>
> >>>
> >>>         _______________________________________________
> >>>         Usbpicprog-technical mailing list
> >>>         Usb...@li...
> >>>         <mailto:Usb...@li...>
> >>>
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technica
> >>>         l
> >>>
> >>>
> ---------------------------------------------------------------------
> >>>     --------- Xperia(TM) PLAY It's a major breakthrough. An authentic
> >>>     gaming smartphone on the nation's most reliable network. And it
> >>>     wants your games. http://p.sf.net/sfu/verizon-sfdev
> >>>
> >>>     _______________________________________________
> >>>     Usbpicprog-technical mailing list
> >>>     Usb...@li...
> >>>     <mailto:Usb...@li...>
> >>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
> >>>
> >>>
> ---------------------------------------------------------------------
> >>>     --------- Xperia(TM) PLAY
> >>>     It's a major breakthrough. An authentic gaming
> >>>     smartphone on the nation's most reliable network.
> >>>     And it wants your games.
> >>>     http://p.sf.net/sfu/verizon-sfdev
> >>>     _______________________________________________
> >>>     Usbpicprog-technical mailing list
> >>>     Usb...@li...
> >>>     <mailto:Usb...@li...>
> >>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
> >>>
> >>>
> -------------------------------------------------------------------------
> >>> ----- Xperia(TM) PLAY
> >>> It's a major breakthrough. An authentic gaming
> >>> smartphone on the nation's most reliable network.
> >>> And it wants your games.
> >>> http://p.sf.net/sfu/verizon-sfdev
> >>>
> >>>
> >>> _______________________________________________
> >>> Usbpicprog-technical mailing list
> >>> Usb...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
> >
> >
> ------------------------------------------------------------------------------
> > Benefiting from Server Virtualization: Beyond Initial Workload
> > Consolidation -- Increasing the use of server virtualization is a top
> > priority.Virtualization can reduce costs, simplify management, and
> improve
> > application availability and disaster protection. Learn more about
> boosting
> > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> > _______________________________________________
> > Usbpicprog-technical mailing list
> > Usb...@li...
> > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

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

Dear Marcel,

It seems that Fatih solved the issue (at least for the 16F877) by adding
more delay. I have now added more delay in the programming routine only,
not doubled the delay-routine as Fatih did, but it should do the same
trick. Maybe something went wrong during erase, I'll try and see if
doubling the erase time could help.

Regards,

Frans

On 04/14/2011 11:45 PM, Marcel Konrad wrote:
> Dear Frans,
>
> I have tried your new firmware, but it didn't change anything for me. Still the 
> same error. I was hoping that this issue could be solved in software, but now 
> I think that I will try Marcelo's suggestion and add a 470u cap. Will report 
> back when I tried that.
>
> Kind regards
>
> Marcel
>
> Am Mittwoch, 13. April 2011, 16:32:28 schrieb Frans Schreuder:
>> Dear Fatih,
>>
>> I have increased the delay for the given processors in the current git
>> repository. Could you upgrade your firmware with the file below?
>> https://github.com/fransschreuder/usbpicprog/raw/master/trunk/uc_code/uc_co
>> de.hex
>>
>> Kind regards,
>>
>> Frans Schreuder
>>
>> On 04/11/2011 08:17 PM, fatih gokce wrote:
>>> Dear all,
>>> We faced with the same problem for 16F877 and it is solved by the
>>> following change in DelayMs routine of interrupt.c (in firmware)
>>>
>>> while((tick-lasttick)<(2*cnt))continue;
>>>
>>> Since our hardware is not exactly the same hardware of usbpicprog (it
>>> is compatible with gtp-usb lite and has a 12 Mhz xtal ), I thought
>>> that it was only our problem. But after seeing last messages of Marcel
>>> and Marcelo I want to share our solution.
>>>
>>> Frans, you are saying that you have tried more delays in programming
>>> sequence but I do not know the length of your additional delays and
>>> maybe you can also try 2*cnt solution. You will notice but I should
>>> also indicate that this change is unnecessarily affecting the
>>> programming times of all PICs.
>>>
>>> I should also note that while compiling the firmware with MPLAB we had
>>> to comment out some part of the code in prog.c (related to the PICs we
>>> are not planning to use), since it was not fitting into the program
>>> memory of 18F2550.
>>>
>>> Kindest regards,
>>> Fatih.
>>>
>>>
>>> On Mon, Apr 11, 2011 at 5:38 PM, Marcelo Maggi <mm...@ho...
>>>
>>> <mailto:mm...@ho...>> wrote:
>>>     Thank you Frans for your prompt reply.
>>>     
>>>     I fully agree that the noise comes from the USB power line, since
>>>     I can see it even with the programmer disconnected. What I also
>>>     noticed is that the mosfet is somehow amplifying the noise, that
>>>     is the reason why I added a 100nF capacitor at the gate, besides
>>>     the large one directly on the Vdd line after the mosfet. The large
>>>     current as well as the time constant introduced by this capacitor
>>>     were the concerns I had at the beginning, so I started testing
>>>     with lower values until I reached 470 uF, which seems a good
>>>     compromise between noise reduction and unwanted side effects.
>>>     
>>>     Unfortunately this is not a solution for the PIC16F877A... it
>>>     keeps showing the erratic behavior I described in my previous
>>>     message.
>>>     
>>>     I will appreciate if you could let me know if you find a solution
>>>     in the future... I will keep experimenting from my side and let
>>>     you know any progress.
>>>     
>>>     Thank you again.
>>>     
>>>     Best regards
>>>     
>>>     Marcelo Maggi
>>>     
>>>     ---------------------------------------------------------------------
>>>     --- Date: Mon, 11 Apr 2011 08:58:30 +0200
>>>     From: fra...@gm... <mailto:fra...@gm...>
>>>     To: usb...@li...
>>>     <mailto:usb...@li...>
>>>     Subject: Re: [Usbpicprog-technical] Unstability when programing
>>>     large pieces of code
>>>     
>>>     
>>>     Dear Marcelo Maggi,
>>>     
>>>     I have indeed noticed this behaviour before, but not for all pic
>>>     devices. It seems to happen only on some revisions of pics and it
>>>     is very unpredictable. It also depends on the computer you are
>>>     using it on. I have been trying to add more delays in the
>>>     programming sequence, but that also didn't seem to help much. At
>>>     least it is good to hear that there is a solution for the
>>>     behaviour for the 628A.
>>>     The funny thing is that the +5V is directly obtained from the usb
>>>     power line of the computer and is only switched by one mosfet. The
>>>     noise seems to come from the usb port in most of the cases. Also
>>>     on the programmer, the +5V is stabilized with 4x 100nF and one
>>>     time 100nF after the mosfet directly on the VDD pin of the output
>>>     port. A 470uF capacitor could do the job but also introduces a
>>>     large current while switching the VDD pin on (there is no current
>>>     limiter) but if it works, there is no problem!
>>>     
>>>     Kind regards,
>>>     
>>>     Frans Schreuder
>>>     
>>>     On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
>>>         Dear Frans:
>>>         
>>>         Thank you for this excellent programmer; I built it and I am
>>>         currently running the latest beta version (0.4.2), both
>>>         firmware and software (AMD64 version).
>>>         
>>>         I have been through a few issues; while I solved some of them,
>>>         I need your support with one.
>>>         
>>>         First thing I noticed was that I had trouble when trying to
>>>         program the PIF16F628A using more than half of the program
>>>         memory. The programming cycle goes OK, but  during the verify
>>>         step there were problems reported (byte read different from
>>>         what was expected). It used to happen at different parts of
>>>         the code, and eventually I could have a few successful
>>>         attempts. Trying to find the cause of the problem, I noticed
>>>         that Vdd (5 volts) was very noisy; I added a large capacitor
>>>         (470 uF/16v) between Vdd and GND at the connector to the ZIF
>>>         board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd
>>>         now much cleaner, I can program the PIC16F628A with no problem
>>>         each and every time. This may help reply the question from
>>>         another user in this forum (posted on April 10).
>>>         
>>>         Now, I am trying to program larger PICs... I tried with the
>>>         PIC16F877A, filling almost all of the program memory. Now, I
>>>         have the same problem again; while verifying there are errors
>>>         at different points of the program each time, with a few
>>>         successful attempts. Further stabilization of Vdd does not
>>>         help. What I noticed is that only a small portion of the
>>>         program is corrupted when it fails to verify. It may happen at
>>>         different parts of the code each time, but the wrong sequence
>>>         is always the same:
>>>         
>>>         FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00
>>>         00 00 00 00 00 00 00 00 00 00 00
>>>         
>>>         After this sequence, the program continues with the right code.
>>>         
>>>         Have you experienced this before? Any clue of what could be
>>>         the reason with the information given?
>>>         
>>>         Just for your reference, the same happens with the latest
>>>         stable version 0.4.1.
>>>         
>>>         Thank you in advance for your ideas...
>>>         
>>>         Best regards
>>>         
>>>         Marcelo Maggi
>>>         
>>>         
>>>         -----------------------------------------------------------------
>>>         ------------- Xperia(TM) PLAY
>>>         It's a major breakthrough. An authentic gaming
>>>         smartphone on the nation's most reliable network.
>>>         And it wants your games.
>>>         http://p.sf.net/sfu/verizon-sfdev
>>>         
>>>         
>>>         _______________________________________________
>>>         Usbpicprog-technical mailing list
>>>         Usb...@li...
>>>         <mailto:Usb...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technica
>>>         l
>>>     
>>>     ---------------------------------------------------------------------
>>>     --------- Xperia(TM) PLAY It's a major breakthrough. An authentic
>>>     gaming smartphone on the nation's most reliable network. And it
>>>     wants your games. http://p.sf.net/sfu/verizon-sfdev
>>>     
>>>     _______________________________________________
>>>     Usbpicprog-technical mailing list
>>>     Usb...@li...
>>>     <mailto:Usb...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>     
>>>     ---------------------------------------------------------------------
>>>     --------- Xperia(TM) PLAY
>>>     It's a major breakthrough. An authentic gaming
>>>     smartphone on the nation's most reliable network.
>>>     And it wants your games.
>>>     http://p.sf.net/sfu/verizon-sfdev
>>>     _______________________________________________
>>>     Usbpicprog-technical mailing list
>>>     Usb...@li...
>>>     <mailto:Usb...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>> -------------------------------------------------------------------------
>>> ----- Xperia(TM) PLAY
>>> It's a major breakthrough. An authentic gaming
>>> smartphone on the nation's most reliable network.
>>> And it wants your games.
>>> http://p.sf.net/sfu/verizon-sfdev
>>>
>>>
>>> _______________________________________________
>>> Usbpicprog-technical mailing list
>>> Usb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload 
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve 
> application availability and disaster protection. Learn more about boosting 
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

[Marcel K. <mak...@gm...>]

Dear Frans,

I have tried your new firmware, but it didn't change anything for me. Still the 
same error. I was hoping that this issue could be solved in software, but now 
I think that I will try Marcelo's suggestion and add a 470u cap. Will report 
back when I tried that.

Kind regards

Marcel

Am Mittwoch, 13. April 2011, 16:32:28 schrieb Frans Schreuder:
> Dear Fatih,
> 
> I have increased the delay for the given processors in the current git
> repository. Could you upgrade your firmware with the file below?
> https://github.com/fransschreuder/usbpicprog/raw/master/trunk/uc_code/uc_co
> de.hex
> 
> Kind regards,
> 
> Frans Schreuder
> 
> On 04/11/2011 08:17 PM, fatih gokce wrote:
> > Dear all,
> > We faced with the same problem for 16F877 and it is solved by the
> > following change in DelayMs routine of interrupt.c (in firmware)
> > 
> > while((tick-lasttick)<(2*cnt))continue;
> > 
> > Since our hardware is not exactly the same hardware of usbpicprog (it
> > is compatible with gtp-usb lite and has a 12 Mhz xtal ), I thought
> > that it was only our problem. But after seeing last messages of Marcel
> > and Marcelo I want to share our solution.
> > 
> > Frans, you are saying that you have tried more delays in programming
> > sequence but I do not know the length of your additional delays and
> > maybe you can also try 2*cnt solution. You will notice but I should
> > also indicate that this change is unnecessarily affecting the
> > programming times of all PICs.
> > 
> > I should also note that while compiling the firmware with MPLAB we had
> > to comment out some part of the code in prog.c (related to the PICs we
> > are not planning to use), since it was not fitting into the program
> > memory of 18F2550.
> > 
> > Kindest regards,
> > Fatih.
> > 
> > 
> > On Mon, Apr 11, 2011 at 5:38 PM, Marcelo Maggi <mm...@ho...
> > 
> > <mailto:mm...@ho...>> wrote:
> >     Thank you Frans for your prompt reply.
> >     
> >     I fully agree that the noise comes from the USB power line, since
> >     I can see it even with the programmer disconnected. What I also
> >     noticed is that the mosfet is somehow amplifying the noise, that
> >     is the reason why I added a 100nF capacitor at the gate, besides
> >     the large one directly on the Vdd line after the mosfet. The large
> >     current as well as the time constant introduced by this capacitor
> >     were the concerns I had at the beginning, so I started testing
> >     with lower values until I reached 470 uF, which seems a good
> >     compromise between noise reduction and unwanted side effects.
> >     
> >     Unfortunately this is not a solution for the PIC16F877A... it
> >     keeps showing the erratic behavior I described in my previous
> >     message.
> >     
> >     I will appreciate if you could let me know if you find a solution
> >     in the future... I will keep experimenting from my side and let
> >     you know any progress.
> >     
> >     Thank you again.
> >     
> >     Best regards
> >     
> >     Marcelo Maggi
> >     
> >     ---------------------------------------------------------------------
> >     --- Date: Mon, 11 Apr 2011 08:58:30 +0200
> >     From: fra...@gm... <mailto:fra...@gm...>
> >     To: usb...@li...
> >     <mailto:usb...@li...>
> >     Subject: Re: [Usbpicprog-technical] Unstability when programing
> >     large pieces of code
> >     
> >     
> >     Dear Marcelo Maggi,
> >     
> >     I have indeed noticed this behaviour before, but not for all pic
> >     devices. It seems to happen only on some revisions of pics and it
> >     is very unpredictable. It also depends on the computer you are
> >     using it on. I have been trying to add more delays in the
> >     programming sequence, but that also didn't seem to help much. At
> >     least it is good to hear that there is a solution for the
> >     behaviour for the 628A.
> >     The funny thing is that the +5V is directly obtained from the usb
> >     power line of the computer and is only switched by one mosfet. The
> >     noise seems to come from the usb port in most of the cases. Also
> >     on the programmer, the +5V is stabilized with 4x 100nF and one
> >     time 100nF after the mosfet directly on the VDD pin of the output
> >     port. A 470uF capacitor could do the job but also introduces a
> >     large current while switching the VDD pin on (there is no current
> >     limiter) but if it works, there is no problem!
> >     
> >     Kind regards,
> >     
> >     Frans Schreuder
> >     
> >     On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
> >         Dear Frans:
> >         
> >         Thank you for this excellent programmer; I built it and I am
> >         currently running the latest beta version (0.4.2), both
> >         firmware and software (AMD64 version).
> >         
> >         I have been through a few issues; while I solved some of them,
> >         I need your support with one.
> >         
> >         First thing I noticed was that I had trouble when trying to
> >         program the PIF16F628A using more than half of the program
> >         memory. The programming cycle goes OK, but  during the verify
> >         step there were problems reported (byte read different from
> >         what was expected). It used to happen at different parts of
> >         the code, and eventually I could have a few successful
> >         attempts. Trying to find the cause of the problem, I noticed
> >         that Vdd (5 volts) was very noisy; I added a large capacitor
> >         (470 uF/16v) between Vdd and GND at the connector to the ZIF
> >         board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd
> >         now much cleaner, I can program the PIC16F628A with no problem
> >         each and every time. This may help reply the question from
> >         another user in this forum (posted on April 10).
> >         
> >         Now, I am trying to program larger PICs... I tried with the
> >         PIC16F877A, filling almost all of the program memory. Now, I
> >         have the same problem again; while verifying there are errors
> >         at different points of the program each time, with a few
> >         successful attempts. Further stabilization of Vdd does not
> >         help. What I noticed is that only a small portion of the
> >         program is corrupted when it fails to verify. It may happen at
> >         different parts of the code each time, but the wrong sequence
> >         is always the same:
> >         
> >         FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00
> >         00 00 00 00 00 00 00 00 00 00 00
> >         
> >         After this sequence, the program continues with the right code.
> >         
> >         Have you experienced this before? Any clue of what could be
> >         the reason with the information given?
> >         
> >         Just for your reference, the same happens with the latest
> >         stable version 0.4.1.
> >         
> >         Thank you in advance for your ideas...
> >         
> >         Best regards
> >         
> >         Marcelo Maggi
> >         
> >         
> >         -----------------------------------------------------------------
> >         ------------- Xperia(TM) PLAY
> >         It's a major breakthrough. An authentic gaming
> >         smartphone on the nation's most reliable network.
> >         And it wants your games.
> >         http://p.sf.net/sfu/verizon-sfdev
> >         
> >         
> >         _______________________________________________
> >         Usbpicprog-technical mailing list
> >         Usb...@li...
> >         <mailto:Usb...@li...>
> >         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technica
> >         l
> >     
> >     ---------------------------------------------------------------------
> >     --------- Xperia(TM) PLAY It's a major breakthrough. An authentic
> >     gaming smartphone on the nation's most reliable network. And it
> >     wants your games. http://p.sf.net/sfu/verizon-sfdev
> >     
> >     _______________________________________________
> >     Usbpicprog-technical mailing list
> >     Usb...@li...
> >     <mailto:Usb...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
> >     
> >     ---------------------------------------------------------------------
> >     --------- Xperia(TM) PLAY
> >     It's a major breakthrough. An authentic gaming
> >     smartphone on the nation's most reliable network.
> >     And it wants your games.
> >     http://p.sf.net/sfu/verizon-sfdev
> >     _______________________________________________
> >     Usbpicprog-technical mailing list
> >     Usb...@li...
> >     <mailto:Usb...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
> > 
> > -------------------------------------------------------------------------
> > ----- Xperia(TM) PLAY
> > It's a major breakthrough. An authentic gaming
> > smartphone on the nation's most reliable network.
> > And it wants your games.
> > http://p.sf.net/sfu/verizon-sfdev
> > 
> > 
> > _______________________________________________
> > Usbpicprog-technical mailing list
> > Usb...@li...
> > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

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

Dear Fatih,

I have increased the delay for the given processors in the current git
repository. Could you upgrade your firmware with the file below?
https://github.com/fransschreuder/usbpicprog/raw/master/trunk/uc_code/uc_code.hex

Kind regards,

Frans Schreuder

On 04/11/2011 08:17 PM, fatih gokce wrote:
> Dear all,
> We faced with the same problem for 16F877 and it is solved by the
> following change in DelayMs routine of interrupt.c (in firmware)
>
> while((tick-lasttick)<(2*cnt))continue;
>
> Since our hardware is not exactly the same hardware of usbpicprog (it
> is compatible with gtp-usb lite and has a 12 Mhz xtal ), I thought
> that it was only our problem. But after seeing last messages of Marcel
> and Marcelo I want to share our solution.
>
> Frans, you are saying that you have tried more delays in programming
> sequence but I do not know the length of your additional delays and
> maybe you can also try 2*cnt solution. You will notice but I should
> also indicate that this change is unnecessarily affecting the
> programming times of all PICs.
>
> I should also note that while compiling the firmware with MPLAB we had
> to comment out some part of the code in prog.c (related to the PICs we
> are not planning to use), since it was not fitting into the program
> memory of 18F2550.
>
> Kindest regards,
> Fatih.
>
>
> On Mon, Apr 11, 2011 at 5:38 PM, Marcelo Maggi <mm...@ho...
> <mailto:mm...@ho...>> wrote:
>
>     Thank you Frans for your prompt reply.
>
>     I fully agree that the noise comes from the USB power line, since
>     I can see it even with the programmer disconnected. What I also
>     noticed is that the mosfet is somehow amplifying the noise, that
>     is the reason why I added a 100nF capacitor at the gate, besides
>     the large one directly on the Vdd line after the mosfet. The large
>     current as well as the time constant introduced by this capacitor
>     were the concerns I had at the beginning, so I started testing
>     with lower values until I reached 470 uF, which seems a good
>     compromise between noise reduction and unwanted side effects.
>
>     Unfortunately this is not a solution for the PIC16F877A... it
>     keeps showing the erratic behavior I described in my previous message.
>
>     I will appreciate if you could let me know if you find a solution
>     in the future... I will keep experimenting from my side and let
>     you know any progress.
>
>     Thank you again.
>
>     Best regards
>
>     Marcelo Maggi
>
>     ------------------------------------------------------------------------
>     Date: Mon, 11 Apr 2011 08:58:30 +0200
>     From: fra...@gm... <mailto:fra...@gm...>
>     To: usb...@li...
>     <mailto:usb...@li...>
>     Subject: Re: [Usbpicprog-technical] Unstability when programing
>     large pieces of code
>
>
>     Dear Marcelo Maggi,
>
>     I have indeed noticed this behaviour before, but not for all pic
>     devices. It seems to happen only on some revisions of pics and it
>     is very unpredictable. It also depends on the computer you are
>     using it on. I have been trying to add more delays in the
>     programming sequence, but that also didn't seem to help much. At
>     least it is good to hear that there is a solution for the
>     behaviour for the 628A.
>     The funny thing is that the +5V is directly obtained from the usb
>     power line of the computer and is only switched by one mosfet. The
>     noise seems to come from the usb port in most of the cases. Also
>     on the programmer, the +5V is stabilized with 4x 100nF and one
>     time 100nF after the mosfet directly on the VDD pin of the output
>     port. A 470uF capacitor could do the job but also introduces a
>     large current while switching the VDD pin on (there is no current
>     limiter) but if it works, there is no problem!
>
>     Kind regards,
>
>     Frans Schreuder
>
>     On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
>
>         Dear Frans:
>
>         Thank you for this excellent programmer; I built it and I am
>         currently running the latest beta version (0.4.2), both
>         firmware and software (AMD64 version).
>
>         I have been through a few issues; while I solved some of them,
>         I need your support with one.
>
>         First thing I noticed was that I had trouble when trying to
>         program the PIF16F628A using more than half of the program
>         memory. The programming cycle goes OK, but  during the verify
>         step there were problems reported (byte read different from
>         what was expected). It used to happen at different parts of
>         the code, and eventually I could have a few successful
>         attempts. Trying to find the cause of the problem, I noticed
>         that Vdd (5 volts) was very noisy; I added a large capacitor
>         (470 uF/16v) between Vdd and GND at the connector to the ZIF
>         board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd
>         now much cleaner, I can program the PIC16F628A with no problem
>         each and every time. This may help reply the question from
>         another user in this forum (posted on April 10).
>
>         Now, I am trying to program larger PICs... I tried with the
>         PIC16F877A, filling almost all of the program memory. Now, I
>         have the same problem again; while verifying there are errors
>         at different points of the program each time, with a few
>         successful attempts. Further stabilization of Vdd does not
>         help. What I noticed is that only a small portion of the
>         program is corrupted when it fails to verify. It may happen at
>         different parts of the code each time, but the wrong sequence
>         is always the same:
>
>         FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00
>         00 00 00 00 00 00 00 00 00 00 00
>
>         After this sequence, the program continues with the right code.
>
>         Have you experienced this before? Any clue of what could be
>         the reason with the information given?
>
>         Just for your reference, the same happens with the latest
>         stable version 0.4.1.
>
>         Thank you in advance for your ideas...
>
>         Best regards
>
>         Marcelo Maggi
>
>
>         ------------------------------------------------------------------------------
>         Xperia(TM) PLAY
>         It's a major breakthrough. An authentic gaming
>         smartphone on the nation's most reliable network.
>         And it wants your games.
>         http://p.sf.net/sfu/verizon-sfdev
>
>
>         _______________________________________________
>         Usbpicprog-technical mailing list
>         Usb...@li... <mailto:Usb...@li...>
>         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>     ------------------------------------------------------------------------------
>     Xperia(TM) PLAY It's a major breakthrough. An authentic gaming
>     smartphone on the nation's most reliable network. And it wants
>     your games. http://p.sf.net/sfu/verizon-sfdev
>
>     _______________________________________________
>     Usbpicprog-technical mailing list
>     Usb...@li...
>     <mailto:Usb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>     ------------------------------------------------------------------------------
>     Xperia(TM) PLAY
>     It's a major breakthrough. An authentic gaming
>     smartphone on the nation's most reliable network.
>     And it wants your games.
>     http://p.sf.net/sfu/verizon-sfdev
>     _______________________________________________
>     Usbpicprog-technical mailing list
>     Usb...@li...
>     <mailto:Usb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

[fatih g. <gok...@gm...>]

Dear all,
We faced with the same problem for 16F877 and it is solved by the following
change in DelayMs routine of interrupt.c (in firmware)

while((tick-lasttick)<(2*cnt))continue;

Since our hardware is not exactly the same hardware of usbpicprog (it is
compatible with gtp-usb lite and has a 12 Mhz xtal ), I thought that it was
only our problem. But after seeing last messages of Marcel and Marcelo I
want to share our solution.

Frans, you are saying that you have tried more delays in programming
sequence but I do not know the length of your additional delays and maybe
you can also try 2*cnt solution. You will notice but I should also indicate
that this change is unnecessarily affecting the programming times of all
PICs.

I should also note that while compiling the firmware with MPLAB we had to
comment out some part of the code in prog.c (related to the PICs we are not
planning to use), since it was not fitting into the program memory of
18F2550.

Kindest regards,
Fatih.


On Mon, Apr 11, 2011 at 5:38 PM, Marcelo Maggi <mm...@ho...> wrote:

>  Thank you Frans for your prompt reply.
>
> I fully agree that the noise comes from the USB power line, since I can see
> it even with the programmer disconnected. What I also noticed is that the
> mosfet is somehow amplifying the noise, that is the reason why I added a
> 100nF capacitor at the gate, besides the large one directly on the Vdd line
> after the mosfet. The large current as well as the time constant introduced
> by this capacitor were the concerns I had at the beginning, so I started
> testing with lower values until I reached 470 uF, which seems a good
> compromise between noise reduction and unwanted side effects.
>
> Unfortunately this is not a solution for the PIC16F877A... it keeps showing
> the erratic behavior I described in my previous message.
>
> I will appreciate if you could let me know if you find a solution in the
> future... I will keep experimenting from my side and let you know any
> progress.
>
> Thank you again.
>
> Best regards
>
> Marcelo Maggi
>
> ------------------------------
> Date: Mon, 11 Apr 2011 08:58:30 +0200
> From: fra...@gm...
> To: usb...@li...
> Subject: Re: [Usbpicprog-technical] Unstability when programing large
> pieces of code
>
>
> Dear Marcelo Maggi,
>
> I have indeed noticed this behaviour before, but not for all pic devices.
> It seems to happen only on some revisions of pics and it is very
> unpredictable. It also depends on the computer you are using it on. I have
> been trying to add more delays in the programming sequence, but that also
> didn't seem to help much. At least it is good to hear that there is a
> solution for the behaviour for the 628A.
> The funny thing is that the +5V is directly obtained from the usb power
> line of the computer and is only switched by one mosfet. The noise seems to
> come from the usb port in most of the cases. Also on the programmer, the +5V
> is stabilized with 4x 100nF and one time 100nF after the mosfet directly on
> the VDD pin of the output port. A 470uF capacitor could do the job but also
> introduces a large current while switching the VDD pin on (there is no
> current limiter) but if it works, there is no problem!
>
> Kind regards,
>
> Frans Schreuder
>
> On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
>
> Dear Frans:
>
> Thank you for this excellent programmer; I built it and I am currently
> running the latest beta version (0.4.2), both firmware and software (AMD64
> version).
>
> I have been through a few issues; while I solved some of them, I need your
> support with one.
>
> First thing I noticed was that I had trouble when trying to program the
> PIF16F628A using more than half of the program memory. The programming cycle
> goes OK, but  during the verify step there were problems reported (byte read
> different from what was expected). It used to happen at different parts of
> the code, and eventually I could have a few successful attempts. Trying to
> find the cause of the problem, I noticed that Vdd (5 volts) was very noisy;
> I added a large capacitor (470 uF/16v) between Vdd and GND at the connector
> to the ZIF board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd now
> much cleaner, I can program the PIC16F628A with no problem each and every
> time. This may help reply the question from another user in this forum
> (posted on April 10).
>
> Now, I am trying to program larger PICs... I tried with the PIC16F877A,
> filling almost all of the program memory. Now, I have the same problem
> again; while verifying there are errors at different points of the program
> each time, with a few successful attempts. Further stabilization of Vdd does
> not help. What I noticed is that only a small portion of the program is
> corrupted when it fails to verify. It may happen at different parts of the
> code each time, but the wrong sequence is always the same:
>
> FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00
>
> After this sequence, the program continues with the right code.
>
> Have you experienced this before? Any clue of what could be the reason with
> the information given?
>
> Just for your reference, the same happens with the latest stable version
> 0.4.1.
>
> Thank you in advance for your ideas...
>
> Best regards
>
> Marcelo Maggi
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.http://p.sf.net/sfu/verizon-sfdev
>
>
> _______________________________________________
> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on
> the nation's most reliable network. And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
>
> _______________________________________________ Usbpicprog-technical
> mailing list Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

[Marcelo M. <mm...@ho...>]

Thank you Frans for your prompt reply.

I fully agree that the noise comes from the USB power line, since I can see it even with the programmer disconnected. What I also noticed is that the mosfet is somehow amplifying the noise, that is the reason why I added a 100nF capacitor at the gate, besides the large one directly on the Vdd line after the mosfet. The large current as well as the time constant introduced by this capacitor were the concerns I had at the beginning, so I started testing with lower values until I reached 470 uF, which seems a good compromise between noise reduction and unwanted side effects.

Unfortunately this is not a solution for the PIC16F877A... it keeps showing the erratic behavior I described in my previous message.

I will appreciate if you could let me know if you find a solution in the future... I will keep experimenting from my side and let you know any progress.

Thank you again.

Best regards

Marcelo Maggi

Date: Mon, 11 Apr 2011 08:58:30 +0200
From: fra...@gm...
To: usb...@li...
Subject: Re: [Usbpicprog-technical] Unstability when programing large pieces of code



  


    
    Message body
  
  
    Dear Marcelo Maggi,

    

    I have indeed noticed this behaviour before, but not for all pic
    devices. It seems to happen only on some revisions of pics and it is
    very unpredictable. It also depends on the computer you are using it
    on. I have been trying to add more delays in the programming
    sequence, but that also didn't seem to help much. At least it is
    good to hear that there is a solution for the behaviour for the
    628A.

    The funny thing is that the +5V is directly obtained from the usb
    power line of the computer and is only switched by one mosfet. The
    noise seems to come from the usb port in most of the cases. Also on
    the programmer, the +5V is stabilized with 4x 100nF and one time
    100nF after the mosfet directly on the VDD pin of the output port. A
    470uF capacitor could do the job but also introduces a large current
    while switching the VDD pin on (there is no current limiter) but if
    it works, there is no problem!

    

    Kind regards,

    

    Frans Schreuder

    

    On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
    
      
      Dear Frans:

      

      Thank you for this excellent programmer; I built it and I am
      currently running the latest beta version (0.4.2), both firmware
      and software (AMD64 version).

      

      I have been through a few issues; while I solved some of them, I
      need your support with one.

      

      First thing I noticed was that I had trouble when trying to
      program the PIF16F628A using more than half of the program memory.
      The programming cycle goes OK, but  during the verify step there
      were problems reported (byte read different from what was
      expected). It used to happen at different parts of the code, and
      eventually I could have a few successful attempts. Trying to find
      the cause of the problem, I noticed that Vdd (5 volts) was very
      noisy; I added a large capacitor (470 uF/16v) between Vdd and GND
      at the connector to the ZIF board (P1), and a 0.1 uF at the gate
      of Q3 (BS250). With Vdd now much cleaner, I can program the
      PIC16F628A with no problem each and every time. This may help
      reply the question from another user in this forum (posted on
      April 10). 

      

      Now, I am trying to program larger PICs... I tried with the
      PIC16F877A, filling almost all of the program memory. Now, I have
      the same problem again; while verifying there are errors at
      different points of the program each time, with a few successful
      attempts. Further stabilization of Vdd does not help. What I
      noticed is that only a small portion of the program is corrupted
      when it fails to verify. It may happen at different parts of the
      code each time, but the wrong sequence is always the same:

      

      FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00

      

      After this sequence, the program continues with the right code.

      

      Have you experienced this before? Any clue of what could be the
      reason with the information given?

      

      Just for your reference, the same happens with the latest stable
      version 0.4.1.

      

      Thank you in advance for your ideas...

      

      Best regards

      

      Marcelo Maggi

      
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
      
_______________________________________________
Usbpicprog-technical mailing list
Usb...@li...
https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

    
    

  


------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Usbpicprog-technical mailing list
Usb...@li...
https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical 		 	   		  

Re: [Usbpicprog-technical] Problem with 16F628A

[Marcel K. <mak...@gm...>]

Hello Frans,

the verify step fails, as Marcelo pointed out in his mail today.
------------
Mo 11 Apr 2011 10:10:10 CEST: Löschen vor dem Programmieren
Mo 11 Apr 2011 10:10:10 CEST: Löschen OK
Mo 11 Apr 2011 10:10:10 CEST: Programmieren des Programmbereiches des PIC ...
Mo 11 Apr 2011 10:10:16 CEST: Schreiben des Programmspeichers ist OK
Mo 11 Apr 2011 10:10:16 CEST: Programmieren des Datenbereiches des PIC ...
Mo 11 Apr 2011 10:10:16 CEST: Schreiben des Datenspeichers ist OK
Mo 11 Apr 2011 10:10:16 CEST: Vergleiche alle Bereiche des PIC ...
Mo 11 Apr 2011 10:10:17 CEST: Vergleiche den ProgrammcodeErfolglos bei  0x0. 
Gelesen: 0xFF, Erwartet: 0x55
Mo 11 Apr 2011 10:10:17 CEST: Programmieren des Konfigurationsspeichers des PIC
Mo 11 Apr 2011 10:10:17 CEST: Fehler beim Programmieren des 
Konfigurationsspeichers
Mo 11 Apr 2011 10:10:17 CEST: Ablauf ohne Fehler/Warnungen ausgeführt
------------
this is the log. Is it possible to switch the language to english from within 
the software? Did not find a option. Would be easier for troubleshooting...

In english the sequence would be:
Delete OK -> Programming the program memory OK -> Programming the data memory 
OK -> verify all areas of the pic -> Verify failed at 0x0, read: 0xFF, 
expected: 0x55.

So my programming fails right at the beginning, whereas Marcelo's fails when 
programming large programs to the PIC, if I have understood that correctly.

Also the last message is a bit weird, because ist say: "actions performed 
without errors/warnings". I will have a look at the translation files ...

Best regards
Marcel

On Sunday 10 April 2011 17:06:00 Frans Schreuder wrote:
> Dear Marcel Konrad,
> 
> Could you tell me which error you are getting while programming?
> 
> Kind regards,
> 
> Frans Schreuder
> 
> On 04/10/2011 04:33 PM, Marcel Konrad wrote:
> > Hey,
> > 
> > I have build the through-hole Version of usbpicprog successfully and want
> > to thank you for the good and hard work you have invested so far.
> > 
> > I was able to program a 18F4550 without problems, but when I have tried a
> > 16F628A the programming has failed. Both chips are autodetected just
> > fine. I am using the zif-board to mount the pics.
> > 
> > I measured all pins with the Input/Output Test from the Options menu and
> > they are as following:
> > MCLR 4,96/13,7
> > VDD 5,04
> > PGD 3,52/5,32
> > PGC 3,52/5,31
> > Hardware rev. of usbpicprog is 0.3.2 firmware 0.4.2-beta (tried 0.4.1 as
> > well)
> > 
> > Any suggestions where to go from here?
> > 
> > Kind regards
> > Marcel Konrad
> > 
> > -------------------------------------------------------------------------
> > ----- Xperia(TM) PLAY
> > It's a major breakthrough. An authentic gaming
> > smartphone on the nation's most reliable network.
> > And it wants your games.
> > http://p.sf.net/sfu/verizon-sfdev
> > _______________________________________________
> > Usbpicprog-technical mailing list
> > Usb...@li...
> > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] Unstability when programing large pieces of code

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

Dear Marcelo Maggi,

I have indeed noticed this behaviour before, but not for all pic
devices. It seems to happen only on some revisions of pics and it is
very unpredictable. It also depends on the computer you are using it on.
I have been trying to add more delays in the programming sequence, but
that also didn't seem to help much. At least it is good to hear that
there is a solution for the behaviour for the 628A.
The funny thing is that the +5V is directly obtained from the usb power
line of the computer and is only switched by one mosfet. The noise seems
to come from the usb port in most of the cases. Also on the programmer,
the +5V is stabilized with 4x 100nF and one time 100nF after the mosfet
directly on the VDD pin of the output port. A 470uF capacitor could do
the job but also introduces a large current while switching the VDD pin
on (there is no current limiter) but if it works, there is no problem!

Kind regards,

Frans Schreuder

On 04/11/2011 04:48 AM, Marcelo Maggi wrote:
> Dear Frans:
>
> Thank you for this excellent programmer; I built it and I am currently
> running the latest beta version (0.4.2), both firmware and software
> (AMD64 version).
>
> I have been through a few issues; while I solved some of them, I need
> your support with one.
>
> First thing I noticed was that I had trouble when trying to program
> the PIF16F628A using more than half of the program memory. The
> programming cycle goes OK, but  during the verify step there were
> problems reported (byte read different from what was expected). It
> used to happen at different parts of the code, and eventually I could
> have a few successful attempts. Trying to find the cause of the
> problem, I noticed that Vdd (5 volts) was very noisy; I added a large
> capacitor (470 uF/16v) between Vdd and GND at the connector to the ZIF
> board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd now much
> cleaner, I can program the PIC16F628A with no problem each and every
> time. This may help reply the question from another user in this forum
> (posted on April 10).
>
> Now, I am trying to program larger PICs... I tried with the
> PIC16F877A, filling almost all of the program memory. Now, I have the
> same problem again; while verifying there are errors at different
> points of the program each time, with a few successful attempts.
> Further stabilization of Vdd does not help. What I noticed is that
> only a small portion of the program is corrupted when it fails to
> verify. It may happen at different parts of the code each time, but
> the wrong sequence is always the same:
>
> FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00
>
> After this sequence, the program continues with the right code.
>
> Have you experienced this before? Any clue of what could be the reason
> with the information given?
>
> Just for your reference, the same happens with the latest stable
> version 0.4.1.
>
> Thank you in advance for your ideas...
>
> Best regards
>
> Marcelo Maggi
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

[Usbpicprog-technical] Unstability when programing large pieces of code

[Marcelo M. <mm...@ho...>]

Dear Frans:

Thank you for this excellent programmer; I built it and I am currently running the latest beta version (0.4.2), both firmware and software (AMD64 version).

I have been through a few issues; while I solved some of them, I need your support with one.

First thing I noticed was that I had trouble when trying to program the PIF16F628A using more than half of the program memory. The programming cycle goes OK, but  during the verify step there were problems reported (byte read different from what was expected). It used to happen at different parts of the code, and eventually I could have a few successful attempts. Trying to find the cause of the problem, I noticed that Vdd (5 volts) was very noisy; I added a large capacitor (470 uF/16v) between Vdd and GND at the connector to the ZIF board (P1), and a 0.1 uF at the gate of Q3 (BS250). With Vdd now much cleaner, I can program the PIC16F628A with no problem each and every time. This may help reply the question from another user in this forum (posted on April 10). 

Now, I am trying to program larger PICs... I tried with the PIC16F877A, filling almost all of the program memory. Now, I have the same problem again; while verifying there are errors at different points of the program each time, with a few successful attempts. Further stabilization of Vdd does not help. What I noticed is that only a small portion of the program is corrupted when it fails to verify. It may happen at different parts of the code each time, but the wrong sequence is always the same:

FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

After this sequence, the program continues with the right code.

Have you experienced this before? Any clue of what could be the reason with the information given?

Just for your reference, the same happens with the latest stable version 0.4.1.

Thank you in advance for your ideas...

Best regards

Marcelo Maggi
 		 	   		  

Re: [Usbpicprog-technical] Problem with 16F628A

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

Dear Marcel Konrad,

Could you tell me which error you are getting while programming?

Kind regards,

Frans Schreuder

On 04/10/2011 04:33 PM, Marcel Konrad wrote:
> Hey,
>
> I have build the through-hole Version of usbpicprog successfully and want to 
> thank you for the good and hard work you have invested so far.
>
> I was able to program a 18F4550 without problems, but when I have tried a 
> 16F628A the programming has failed. Both chips are autodetected just fine. I am 
> using the zif-board to mount the pics.
>
> I measured all pins with the Input/Output Test from the Options menu and they 
> are as following:
> MCLR 4,96/13,7
> VDD 5,04
> PGD 3,52/5,32
> PGC 3,52/5,31
> Hardware rev. of usbpicprog is 0.3.2 firmware 0.4.2-beta (tried 0.4.1 as well)
>
> Any suggestions where to go from here?
>
> Kind regards
> Marcel Konrad
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

[Usbpicprog-technical] Problem with 16F628A

[Marcel K. <mak...@gm...>]

Hey,

I have build the through-hole Version of usbpicprog successfully and want to 
thank you for the good and hard work you have invested so far.

I was able to program a 18F4550 without problems, but when I have tried a 
16F628A the programming has failed. Both chips are autodetected just fine. I am 
using the zif-board to mount the pics.

I measured all pins with the Input/Output Test from the Options menu and they 
are as following:
MCLR 4,96/13,7
VDD 5,04
PGD 3,52/5,32
PGC 3,52/5,31
Hardware rev. of usbpicprog is 0.3.2 firmware 0.4.2-beta (tried 0.4.1 as well)

Any suggestions where to go from here?

Kind regards
Marcel Konrad

Re: [Usbpicprog-technical] wxWidgets Debug Alert

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

Alright, great news!
Well, at least something I can try to reproduce.
So probably wxWidgets is looking for bigger icons because that's your
setting. Maybe I can hard-code somewhere that it should always look for
one size of icons.

Regards,

Frans Schreuder

On 03/09/2011 03:34 PM, fatih gokce wrote:
> Dear Frans,
> Good news. The problem is solved.
>
> My friend said that he did not face with a problem. In the mean time,
> I have changed a display setting on my system inspiring from
> http://simion.com/issue/561: In "Control panel -> Appearance and
> Personalization -> Display", previous setting was Medium - 125%
> (Default), I changed it to Smaller - 100%. And usbpicprog opened
> without complaining icons. Working with tiny icons and characters are
> now a little bit interesting, but anyway usbpicprog is working properly :)
>
> Thank you very much for your helps.
> Fatih.
>
>
> On Wed, Mar 9, 2011 at 4:11 PM, fatih gokce <gok...@gm...
> <mailto:gok...@gm...>> wrote:
>
>     Hello Frans,
>     Yes, really funny.. I have requested from one of my friends to
>     test the program on Win7 32 bit. I will inform you about the result.
>
>
>     "I am affraid that it must be a flag somewhere on which wxWidgets
>     switches into debug mode."
>
>     do you mean this flag is somewhere on my system or in the source
>     of usbpicprog?
>
>     Regards,
>     Fatih.
>
>
>     On Wed, Mar 9, 2011 at 3:41 PM, Frans Schreuder
>     <fra...@gm... <mailto:fra...@gm...>> wrote:
>
>         Ok, that is funny, I have tested the current build on Win7
>         32bit and I didn't get the messages.
>         I will try it again though, and see what kind of error
>         messages I get.
>         I think tomorrow eve I can will find some time to test it.
>         I am affraid that it must be a flag somewhere on which
>         wxWidgets switches into debug mode.
>
>         Kind regards,
>
>         Frans Schreuder
>
>
>         On 03/09/2011 02:33 PM, fatih gokce wrote:
>>         Dear Frans,
>>         I am using Windows 7 Professional, 32-bit.
>>
>>         Best Thanks&Regards
>>         Fatih.
>>
>>         On Wed, Mar 9, 2011 at 3:25 PM, Frans Schreuder
>>         <fra...@gm... <mailto:fra...@gm...>>
>>         wrote:
>>
>>             Dear Fatih,
>>
>>             Which version of Windows are you using?
>>             I will try on that version to see if I can reproduce the
>>             problem.
>>             I am not using Windows myself, but I can try it in a
>>             virtual machine or something.
>>
>>             Kind regards,
>>
>>             Frans Schreuder
>>
>>
>>             On 03/09/2011 02:02 PM, fatih gokce wrote:
>>>             Dear Frans,
>>>             I used the Windows installer.
>>>
>>>             I have uninstalled wxWidgets, usbpicprog and
>>>             re-installed usbpicprog (UsbPicProg-x86-0.4.2-beta.exe),
>>>             but nothing changed.
>>>
>>>             I have checked environment variables but I could not
>>>             find a related setting.
>>>
>>>             Regards,
>>>             Fatih.
>>>
>>>             On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder
>>>             <fra...@gm...
>>>             <mailto:fra...@gm...>> wrote:
>>>
>>>                 Dear Fatih,
>>>
>>>                 Did you use the Windows installer from usbpicprog,
>>>                 or did you build it yourself?
>>>                 It seems that your wxWidgets is somehow running in
>>>                 debug mode.
>>>                 I don't know how the icons got lost, but could you
>>>                 try running usbpicprog on a clean machine (without
>>>                 wxWidgets installed)?
>>>
>>>                 Is it possible that you have some environment
>>>                 variable set which has something to do with debug?
>>>
>>>                 Kind regards,
>>>
>>>                 Frans Schreuder
>>>
>>>
>>>                 On 03/09/2011 12:29 AM, fatih gokce wrote:
>>>>                 Hi,
>>>>                 When I start usbpicprog (0.4.1 or higher) I am
>>>>                 getting an alert as in the attached screenshot. I
>>>>                 am clicking cancel and going on without some icons.
>>>>                 This is not a big problem but taking this alert
>>>>                 everytime is a bit annoying. Is there something
>>>>                 missing that I have to install? (wxWidgets is
>>>>                 installed on my system.)
>>>>
>>>>                 Kindest Regards.
>>>>                 Fatih.
>>>>
>>>>
>>>>                 ------------------------------------------------------------------------------
>>>>                 Colocation vs. Managed Hosting
>>>>                 A question and answer guide to determining the best fit
>>>>                 for your organization - today and in the future.
>>>>                 http://p.sf.net/sfu/internap-sfd2d
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 Usbpicprog-technical mailing list
>>>>                 Usb...@li... <mailto:Usb...@li...>
>>>>                 https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>>                 ------------------------------------------------------------------------------
>>>                 Colocation vs. Managed Hosting
>>>                 A question and answer guide to determining the best fit
>>>                 for your organization - today and in the future.
>>>                 http://p.sf.net/sfu/internap-sfd2d
>>>                 _______________________________________________
>>>                 Usbpicprog-technical mailing list
>>>                 Usb...@li...
>>>                 <mailto:Usb...@li...>
>>>                 https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>>
>>>             ------------------------------------------------------------------------------
>>>             Colocation vs. Managed Hosting
>>>             A question and answer guide to determining the best fit
>>>             for your organization - today and in the future.
>>>             http://p.sf.net/sfu/internap-sfd2d
>>>
>>>
>>>             _______________________________________________
>>>             Usbpicprog-technical mailing list
>>>             Usb...@li... <mailto:Usb...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>             ------------------------------------------------------------------------------
>>             Colocation vs. Managed Hosting
>>             A question and answer guide to determining the best fit
>>             for your organization - today and in the future.
>>             http://p.sf.net/sfu/internap-sfd2d
>>             _______________________________________________
>>             Usbpicprog-technical mailing list
>>             Usb...@li...
>>             <mailto:Usb...@li...>
>>             https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>
>>         ------------------------------------------------------------------------------
>>         Colocation vs. Managed Hosting
>>         A question and answer guide to determining the best fit
>>         for your organization - today and in the future.
>>         http://p.sf.net/sfu/internap-sfd2d
>>
>>
>>         _______________________________________________
>>         Usbpicprog-technical mailing list
>>         Usb...@li... <mailto:Usb...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>         ------------------------------------------------------------------------------
>         Colocation vs. Managed Hosting
>         A question and answer guide to determining the best fit
>         for your organization - today and in the future.
>         http://p.sf.net/sfu/internap-sfd2d
>         _______________________________________________
>         Usbpicprog-technical mailing list
>         Usb...@li...
>         <mailto:Usb...@li...>
>         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] wxWidgets Debug Alert

[fatih g. <gok...@gm...>]

Dear Frans,
Good news. The problem is solved.

My friend said that he did not face with a problem. In the mean time, I have
changed a display setting on my system inspiring from
http://simion.com/issue/561: In "Control panel -> Appearance and
Personalization -> Display", previous setting was Medium - 125% (Default), I
changed it to Smaller - 100%. And usbpicprog opened without complaining
icons. Working with tiny icons and characters are now a little bit
interesting, but anyway usbpicprog is working properly :)

Thank you very much for your helps.
Fatih.


On Wed, Mar 9, 2011 at 4:11 PM, fatih gokce <gok...@gm...> wrote:

> Hello Frans,
> Yes, really funny.. I have requested from one of my friends to test the
> program on Win7 32 bit. I will inform you about the result.
>
>
> "I am affraid that it must be a flag somewhere on which wxWidgets switches
> into debug mode."
>
> do you mean this flag is somewhere on my system or in the source of
> usbpicprog?
>
> Regards,
> Fatih.
>
>
> On Wed, Mar 9, 2011 at 3:41 PM, Frans Schreuder <fra...@gm...>wrote:
>
>>  Ok, that is funny, I have tested the current build on Win7 32bit and I
>> didn't get the messages.
>> I will try it again though, and see what kind of error messages I get.
>> I think tomorrow eve I can will find some time to test it.
>> I am affraid that it must be a flag somewhere on which wxWidgets switches
>> into debug mode.
>>
>> Kind regards,
>>
>> Frans Schreuder
>>
>>
>> On 03/09/2011 02:33 PM, fatih gokce wrote:
>>
>> Dear Frans,
>> I am using Windows 7 Professional, 32-bit.
>>
>> Best Thanks&Regards
>> Fatih.
>>
>> On Wed, Mar 9, 2011 at 3:25 PM, Frans Schreuder <fra...@gm...
>> > wrote:
>>
>>>  Dear Fatih,
>>>
>>> Which version of Windows are you using?
>>> I will try on that version to see if I can reproduce the problem.
>>> I am not using Windows myself, but I can try it in a virtual machine or
>>> something.
>>>
>>> Kind regards,
>>>
>>> Frans Schreuder
>>>
>>>
>>> On 03/09/2011 02:02 PM, fatih gokce wrote:
>>>
>>> Dear Frans,
>>> I used the Windows installer.
>>>
>>> I have uninstalled wxWidgets, usbpicprog and re-installed usbpicprog
>>> (UsbPicProg-x86-0.4.2-beta.exe), but nothing changed.
>>>
>>> I have checked environment variables but I could not find a related
>>> setting.
>>>
>>> Regards,
>>> Fatih.
>>>
>>> On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder <
>>> fra...@gm...> wrote:
>>>
>>>>  Dear Fatih,
>>>>
>>>> Did you use the Windows installer from usbpicprog, or did you build it
>>>> yourself?
>>>> It seems that your wxWidgets is somehow running in debug mode.
>>>> I don't know how the icons got lost, but could you try running
>>>> usbpicprog on a clean machine (without wxWidgets installed)?
>>>>
>>>> Is it possible that you have some environment variable set which has
>>>> something to do with debug?
>>>>
>>>> Kind regards,
>>>>
>>>> Frans Schreuder
>>>>
>>>>
>>>> On 03/09/2011 12:29 AM, fatih gokce wrote:
>>>>
>>>>  Hi,
>>>> When I start usbpicprog (0.4.1 or higher) I am getting an alert as in
>>>> the attached screenshot. I am clicking cancel and going on without some
>>>> icons. This is not a big problem but taking this alert everytime is a bit
>>>> annoying. Is there something missing that I have to install? (wxWidgets is
>>>> installed on my system.)
>>>>
>>>> Kindest Regards.
>>>> Fatih.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Colocation vs. Managed Hosting
>>>> A question and answer guide to determining the best fit
>>>> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>>>>
>>>>
>>>> _______________________________________________
>>>> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Colocation vs. Managed Hosting
>>>> A question and answer guide to determining the best fit
>>>> for your organization - today and in the future.
>>>> http://p.sf.net/sfu/internap-sfd2d
>>>> _______________________________________________
>>>> Usbpicprog-technical mailing list
>>>> Usb...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>>>
>>>
>>> _______________________________________________
>>> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.
>>> http://p.sf.net/sfu/internap-sfd2d
>>> _______________________________________________
>>> Usbpicprog-technical mailing list
>>> Usb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>>
>>
>> _______________________________________________
>> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Usbpicprog-technical mailing list
>> Usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>

Re: [Usbpicprog-technical] wxWidgets Debug Alert

[fatih g. <gok...@gm...>]

Hello Frans,
Yes, really funny.. I have requested from one of my friends to test the
program on Win7 32 bit. I will inform you about the result.

"I am affraid that it must be a flag somewhere on which wxWidgets switches
into debug mode."

do you mean this flag is somewhere on my system or in the source of
usbpicprog?

Regards,
Fatih.

On Wed, Mar 9, 2011 at 3:41 PM, Frans Schreuder <fra...@gm...>wrote:

>  Ok, that is funny, I have tested the current build on Win7 32bit and I
> didn't get the messages.
> I will try it again though, and see what kind of error messages I get.
> I think tomorrow eve I can will find some time to test it.
> I am affraid that it must be a flag somewhere on which wxWidgets switches
> into debug mode.
>
> Kind regards,
>
> Frans Schreuder
>
>
> On 03/09/2011 02:33 PM, fatih gokce wrote:
>
> Dear Frans,
> I am using Windows 7 Professional, 32-bit.
>
> Best Thanks&Regards
> Fatih.
>
> On Wed, Mar 9, 2011 at 3:25 PM, Frans Schreuder <fra...@gm...>wrote:
>
>>  Dear Fatih,
>>
>> Which version of Windows are you using?
>> I will try on that version to see if I can reproduce the problem.
>> I am not using Windows myself, but I can try it in a virtual machine or
>> something.
>>
>> Kind regards,
>>
>> Frans Schreuder
>>
>>
>> On 03/09/2011 02:02 PM, fatih gokce wrote:
>>
>> Dear Frans,
>> I used the Windows installer.
>>
>> I have uninstalled wxWidgets, usbpicprog and re-installed usbpicprog
>> (UsbPicProg-x86-0.4.2-beta.exe), but nothing changed.
>>
>> I have checked environment variables but I could not find a related
>> setting.
>>
>> Regards,
>> Fatih.
>>
>> On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder <fra...@gm...
>> > wrote:
>>
>>>  Dear Fatih,
>>>
>>> Did you use the Windows installer from usbpicprog, or did you build it
>>> yourself?
>>> It seems that your wxWidgets is somehow running in debug mode.
>>> I don't know how the icons got lost, but could you try running usbpicprog
>>> on a clean machine (without wxWidgets installed)?
>>>
>>> Is it possible that you have some environment variable set which has
>>> something to do with debug?
>>>
>>> Kind regards,
>>>
>>> Frans Schreuder
>>>
>>>
>>> On 03/09/2011 12:29 AM, fatih gokce wrote:
>>>
>>>  Hi,
>>> When I start usbpicprog (0.4.1 or higher) I am getting an alert as in the
>>> attached screenshot. I am clicking cancel and going on without some icons.
>>> This is not a big problem but taking this alert everytime is a bit annoying.
>>> Is there something missing that I have to install? (wxWidgets is installed
>>> on my system.)
>>>
>>> Kindest Regards.
>>> Fatih.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>>>
>>>
>>> _______________________________________________
>>> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.
>>> http://p.sf.net/sfu/internap-sfd2d
>>> _______________________________________________
>>> Usbpicprog-technical mailing list
>>> Usb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>>
>>
>> _______________________________________________
>> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Usbpicprog-technical mailing list
>> Usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>

Re: [Usbpicprog-technical] wxWidgets Debug Alert

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

Ok, that is funny, I have tested the current build on Win7 32bit and I
didn't get the messages.
I will try it again though, and see what kind of error messages I get.
I think tomorrow eve I can will find some time to test it.
I am affraid that it must be a flag somewhere on which wxWidgets
switches into debug mode.

Kind regards,

Frans Schreuder

On 03/09/2011 02:33 PM, fatih gokce wrote:
> Dear Frans,
> I am using Windows 7 Professional, 32-bit.
>
> Best Thanks&Regards
> Fatih.
>
> On Wed, Mar 9, 2011 at 3:25 PM, Frans Schreuder
> <fra...@gm... <mailto:fra...@gm...>> wrote:
>
>     Dear Fatih,
>
>     Which version of Windows are you using?
>     I will try on that version to see if I can reproduce the problem.
>     I am not using Windows myself, but I can try it in a virtual
>     machine or something.
>
>     Kind regards,
>
>     Frans Schreuder
>
>
>     On 03/09/2011 02:02 PM, fatih gokce wrote:
>>     Dear Frans,
>>     I used the Windows installer.
>>
>>     I have uninstalled wxWidgets, usbpicprog and re-installed
>>     usbpicprog (UsbPicProg-x86-0.4.2-beta.exe), but nothing changed.
>>
>>     I have checked environment variables but I could not find a
>>     related setting.
>>
>>     Regards,
>>     Fatih.
>>
>>     On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder
>>     <fra...@gm... <mailto:fra...@gm...>> wrote:
>>
>>         Dear Fatih,
>>
>>         Did you use the Windows installer from usbpicprog, or did you
>>         build it yourself?
>>         It seems that your wxWidgets is somehow running in debug mode.
>>         I don't know how the icons got lost, but could you try
>>         running usbpicprog on a clean machine (without wxWidgets
>>         installed)?
>>
>>         Is it possible that you have some environment variable set
>>         which has something to do with debug?
>>
>>         Kind regards,
>>
>>         Frans Schreuder
>>
>>
>>         On 03/09/2011 12:29 AM, fatih gokce wrote:
>>>         Hi,
>>>         When I start usbpicprog (0.4.1 or higher) I am getting an
>>>         alert as in the attached screenshot. I am clicking cancel
>>>         and going on without some icons. This is not a big problem
>>>         but taking this alert everytime is a bit annoying. Is there
>>>         something missing that I have to install? (wxWidgets is
>>>         installed on my system.)
>>>
>>>         Kindest Regards.
>>>         Fatih.
>>>
>>>
>>>         ------------------------------------------------------------------------------
>>>         Colocation vs. Managed Hosting
>>>         A question and answer guide to determining the best fit
>>>         for your organization - today and in the future.
>>>         http://p.sf.net/sfu/internap-sfd2d
>>>
>>>
>>>         _______________________________________________
>>>         Usbpicprog-technical mailing list
>>>         Usb...@li... <mailto:Usb...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>         ------------------------------------------------------------------------------
>>         Colocation vs. Managed Hosting
>>         A question and answer guide to determining the best fit
>>         for your organization - today and in the future.
>>         http://p.sf.net/sfu/internap-sfd2d
>>         _______________________________________________
>>         Usbpicprog-technical mailing list
>>         Usb...@li...
>>         <mailto:Usb...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     Colocation vs. Managed Hosting
>>     A question and answer guide to determining the best fit
>>     for your organization - today and in the future.
>>     http://p.sf.net/sfu/internap-sfd2d
>>
>>
>>     _______________________________________________
>>     Usbpicprog-technical mailing list
>>     Usb...@li... <mailto:Usb...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>     ------------------------------------------------------------------------------
>     Colocation vs. Managed Hosting
>     A question and answer guide to determining the best fit
>     for your organization - today and in the future.
>     http://p.sf.net/sfu/internap-sfd2d
>     _______________________________________________
>     Usbpicprog-technical mailing list
>     Usb...@li...
>     <mailto:Usb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] wxWidgets Debug Alert

[fatih g. <gok...@gm...>]

Dear Frans,
I am using Windows 7 Professional, 32-bit.

Best Thanks&Regards
Fatih.

On Wed, Mar 9, 2011 at 3:25 PM, Frans Schreuder <fra...@gm...>wrote:

>  Dear Fatih,
>
> Which version of Windows are you using?
> I will try on that version to see if I can reproduce the problem.
> I am not using Windows myself, but I can try it in a virtual machine or
> something.
>
> Kind regards,
>
> Frans Schreuder
>
>
> On 03/09/2011 02:02 PM, fatih gokce wrote:
>
> Dear Frans,
> I used the Windows installer.
>
> I have uninstalled wxWidgets, usbpicprog and re-installed usbpicprog
> (UsbPicProg-x86-0.4.2-beta.exe), but nothing changed.
>
> I have checked environment variables but I could not find a related
> setting.
>
> Regards,
> Fatih.
>
> On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder <fra...@gm...>wrote:
>
>>  Dear Fatih,
>>
>> Did you use the Windows installer from usbpicprog, or did you build it
>> yourself?
>> It seems that your wxWidgets is somehow running in debug mode.
>> I don't know how the icons got lost, but could you try running usbpicprog
>> on a clean machine (without wxWidgets installed)?
>>
>> Is it possible that you have some environment variable set which has
>> something to do with debug?
>>
>> Kind regards,
>>
>> Frans Schreuder
>>
>>
>> On 03/09/2011 12:29 AM, fatih gokce wrote:
>>
>>  Hi,
>> When I start usbpicprog (0.4.1 or higher) I am getting an alert as in the
>> attached screenshot. I am clicking cancel and going on without some icons.
>> This is not a big problem but taking this alert everytime is a bit annoying.
>> Is there something missing that I have to install? (wxWidgets is installed
>> on my system.)
>>
>> Kindest Regards.
>> Fatih.
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>>
>>
>> _______________________________________________
>> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Usbpicprog-technical mailing list
>> Usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>

Re: [Usbpicprog-technical] wxWidgets Debug Alert

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

Dear Fatih,

Which version of Windows are you using?
I will try on that version to see if I can reproduce the problem.
I am not using Windows myself, but I can try it in a virtual machine or
something.

Kind regards,

Frans Schreuder

On 03/09/2011 02:02 PM, fatih gokce wrote:
> Dear Frans,
> I used the Windows installer.
>
> I have uninstalled wxWidgets, usbpicprog and re-installed usbpicprog
> (UsbPicProg-x86-0.4.2-beta.exe), but nothing changed.
>
> I have checked environment variables but I could not find a related
> setting.
>
> Regards,
> Fatih.
>
> On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder
> <fra...@gm... <mailto:fra...@gm...>> wrote:
>
>     Dear Fatih,
>
>     Did you use the Windows installer from usbpicprog, or did you
>     build it yourself?
>     It seems that your wxWidgets is somehow running in debug mode.
>     I don't know how the icons got lost, but could you try running
>     usbpicprog on a clean machine (without wxWidgets installed)?
>
>     Is it possible that you have some environment variable set which
>     has something to do with debug?
>
>     Kind regards,
>
>     Frans Schreuder
>
>
>     On 03/09/2011 12:29 AM, fatih gokce wrote:
>>     Hi,
>>     When I start usbpicprog (0.4.1 or higher) I am getting an alert
>>     as in the attached screenshot. I am clicking cancel and going on
>>     without some icons. This is not a big problem but taking this
>>     alert everytime is a bit annoying. Is there something missing
>>     that I have to install? (wxWidgets is installed on my system.)
>>
>>     Kindest Regards.
>>     Fatih.
>>
>>
>>     ------------------------------------------------------------------------------
>>     Colocation vs. Managed Hosting
>>     A question and answer guide to determining the best fit
>>     for your organization - today and in the future.
>>     http://p.sf.net/sfu/internap-sfd2d
>>
>>
>>     _______________________________________________
>>     Usbpicprog-technical mailing list
>>     Usb...@li... <mailto:Usb...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>     ------------------------------------------------------------------------------
>     Colocation vs. Managed Hosting
>     A question and answer guide to determining the best fit
>     for your organization - today and in the future.
>     http://p.sf.net/sfu/internap-sfd2d
>     _______________________________________________
>     Usbpicprog-technical mailing list
>     Usb...@li...
>     <mailto:Usb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] wxWidgets Debug Alert

[fatih g. <gok...@gm...>]

Dear Frans,
I used the Windows installer.

I have uninstalled wxWidgets, usbpicprog and re-installed usbpicprog
(UsbPicProg-x86-0.4.2-beta.exe), but nothing changed.

I have checked environment variables but I could not find a related setting.

Regards,
Fatih.

On Wed, Mar 9, 2011 at 9:36 AM, Frans Schreuder <fra...@gm...>wrote:

>  Dear Fatih,
>
> Did you use the Windows installer from usbpicprog, or did you build it
> yourself?
> It seems that your wxWidgets is somehow running in debug mode.
> I don't know how the icons got lost, but could you try running usbpicprog
> on a clean machine (without wxWidgets installed)?
>
> Is it possible that you have some environment variable set which has
> something to do with debug?
>
> Kind regards,
>
> Frans Schreuder
>
>
> On 03/09/2011 12:29 AM, fatih gokce wrote:
>
> Hi,
> When I start usbpicprog (0.4.1 or higher) I am getting an alert as in the
> attached screenshot. I am clicking cancel and going on without some icons.
> This is not a big problem but taking this alert everytime is a bit annoying.
> Is there something missing that I have to install? (wxWidgets is installed
> on my system.)
>
> Kindest Regards.
> Fatih.
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>

Re: [Usbpicprog-technical] wxWidgets Debug Alert

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

Dear Fatih,

Did you use the Windows installer from usbpicprog, or did you build it
yourself?
It seems that your wxWidgets is somehow running in debug mode.
I don't know how the icons got lost, but could you try running
usbpicprog on a clean machine (without wxWidgets installed)?

Is it possible that you have some environment variable set which has
something to do with debug?

Kind regards,

Frans Schreuder

On 03/09/2011 12:29 AM, fatih gokce wrote:
> Hi,
> When I start usbpicprog (0.4.1 or higher) I am getting an alert as in
> the attached screenshot. I am clicking cancel and going on without
> some icons. This is not a big problem but taking this alert everytime
> is a bit annoying. Is there something missing that I have to install?
> (wxWidgets is installed on my system.)
>
> Kindest Regards.
> Fatih.
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] 18f45k22

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

Dear Matt Hirsch,

Thanks for the patches. I have reviewed the code and committed it to the
git repository.
Just made a few changes to your code:
-The new pic families should be added to the end of the enum for
backward compatibility.
-I have removed the debugging cout lines.

Regards,

Frans

On 02/20/2011 12:01 PM, Matt Hirsch wrote:
> I finally gotten around to doing this.
>
> I've attached two patches against the 0.4.2 beta release, one for the
> firmware source tree, and one for usbpicprog. I had to add new entries
> to PicFamily, which is why usbpicprog needed to be updated. I've tried
> to make the code changes minimally invasive, but please let me know if
> there's anything that needs cleaning up.
>
> I've tested this as working with a 18f45k22 using a 9v regulator on
> Vpp. The 18lf versions of these parts require a lower voltage (<3.6V)
> Vdd/PGC/D. It looks like this should be possible, so I added an XML
> file and entry for the LF part as well, but I think code changes to
> the firmware will be necessary to provide the low voltage versions of
> the PGC/D signals.
>
> My XML files are missing the C compiler tags, since I'm not sure where
> you're pulling these from. I couldn't find an obvious place in the
> MCC18 headers. The SDCC tags seem irrelevant, since SDCC doesn't
> support the 18F4XK22 parts.
>
> Thanks,
> Matt
>
> On 01/31/2011 10:48 AM, Matt Hirsch wrote:
>> Frans,
>>
>> Thanks for the pointers. I noticed you use mcc18 to compile the
>> firmware. (Or at least your Makefile is setup that way). Do you use
>> the commercial version? Or will it be ok to use the lite version? I
>> also see #defines for sdcc - is this a valid option to compile the
>> firmware?
>>
>> Thanks,
>> Matt
>>
>> On 01/31/2011 03:54 AM, Frans Schreuder wrote:
>>> Dear Matt,
>>>
>>> I think the sourcecode of the PC application doesn't have to be altered
>>> for that, only the .xml files.
>>> Only in the firmware some small modifications will have to be done.
>>> Also the hardware can't just program these devices since it gives a VPP
>>> of 12V where the 18f45K22 has a maximum VPP of 9V.
>>> A very simple solution for this will be a 9V zener diode over the VPP
>>> pin so that it won't exceed this limit.
>>>
>>> I don't see any other problems for implementing this device.
>>>
>>> Kind regards,
>>>
>>> Frans Schreuder
>>>
>>>
>>> On 01/31/2011 09:06 AM, Matt Hirsch wrote:
>>>> I was thinking of attempting to modify usbpicprog to program the 
>>>> 18f45k22. The programming spec is similar, with minor differences, to 
>>>> the PIC18F2XXX/4XXX family:
>>>>
>>>> http://ww1.microchip.com/downloads/en/DeviceDoc/39622L.pdf
>>>> vs
>>>> http://ww1.microchip.com/downloads/en/DeviceDoc/41398B.pdf
>>>>
>>>> And I see many parts from that first family are on the tested list.
>>>>
>>>> Should something like this process work?:
>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical 
>>>> <http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical>
>>>>
>>>> I guess I will have to create a new family.
>>>>
>>>> I'd appreciate any comments.
>>>>
>>>> Best,
>>>> Matt
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>>> Finally, a world-class log management solution at an even better price-free!
>>>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
>>>> February 28th, so secure your free ArcSight Logger TODAY! 
>>>> http://p.sf.net/sfu/arcsight-sfd2d
>>>> _______________________________________________
>>>> Usbpicprog-technical mailing list
>>>> Usb...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>> Finally, a world-class log management solution at an even better price-free!
>>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
>>> February 28th, so secure your free ArcSight Logger TODAY! 
>>> http://p.sf.net/sfu/arcsight-sfd2d
>>>
>>>
>>> _______________________________________________
>>> Usbpicprog-technical mailing list
>>> Usb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
>> February 28th, so secure your free ArcSight Logger TODAY! 
>> http://p.sf.net/sfu/arcsight-sfd2d
>>
>>
>> _______________________________________________
>> Usbpicprog-technical mailing list
>> Usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

Re: [Usbpicprog-technical] Hebrew

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

Dear Sephy,

Have you already made the hardware? I have just changed some component
values in the schematic
Replacing Q4 with a bipolar transistor helps increasing VPP, resulting
in more staple programming of some devices...

Regards,

Frans

On 02/25/2011 02:27 PM, sephy p wrote:
> Dear Frans.
> Yes. I am very exited about this project. This programmer is the
> most professorial third party programmer I have seen yet. I have a few
> JDM programmers, and two ICD clones, that I've built ,but this is a
> very nice upgrade for me, and as you said on the video, my laptop
> doesn't have serial...
>
> I am running windows 7 and on some occasions I am still running on
> windows XP. 
>
> As I said, I prefer working in English, but I would love to help
> with Hebrew translation. consider it done. I will start working on it
> right away.
>
> Again, thank you for contributing this project to the public.
>
> Yours, 
> Sephy.
>
>
>
>
> On Fri, Feb 25, 2011 at 10:14 AM, Frans Schreuder
> <fra...@gm... <mailto:fra...@gm...>> wrote:
>
>     Hi Sephy,
>
>     Nice to hear that you are so enthousiastic about my little project!
>     I actually didn't put a single line of code in my software which
>     handles right-to-left languages, only a "set Locale" command which
>     detects the default system language.
>     The fact that the gui changes on right to left operating systems
>     is handled by the wxWidgets library that I use for the GUI.
>     Depending on the operating system you are using, there are some
>     switches that can be set in order to change the GUI back to
>     normal, I don't know which os you are using?
>
>     Having new translations is always a great thing! It will make it
>     possible for more users to use this peace of software!
>     I have already written a page on my site about translations:
>     http://usbpicprog.org/?page_id=158
>     I do want to release version 0.4.2 soon, I didn't get any
>     complaints about the beta version, so probably there will just be
>     some language updates before the release.
>     It would be very great if you would help me translating this
>     software. Thank you for your offer!
>
>     Kind regards,
>
>     Frans Schreuder
>
>
>     On 02/25/2011 07:33 AM, sephy p wrote:
>>     Hi. My name is Sephy, I am from Israel.
>>
>>     First of all, thank you for your wonderful work!
>>     Second thing is, I'm having problems with the software. 
>>     since hebrew is written from right to left, the program shows
>>     everything oriented to the right and sometimes (in the help
>>     section) it's mirrored.
>>     I can send you a picture if you like to show you what I mean.
>>
>>     I prefer using the program in English (left side oriented of
>>     course) but I think, once the program detects a different locale
>>     it sets the orientation automatically. I would love to have some
>>     solution for this, maybe to run the program with a special
>>     switch, or having some way to enforce (left side) English...
>>
>>     Third thing is, I would love to offer my help and translate the
>>     program to Hebrew, properly.
>>
>>
>>     Again, THANK YOU, for your wonderful work. keep doing so!
>>
>>
>>     ------------------------------------------------------------------------------
>>     Free Software Download: Index, Search & Analyze Logs and other IT data in 
>>     Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
>>     generated by your applications, servers and devices whether physical, virtual
>>     or in the cloud. Deliver compliance at lower cost and gain new business 
>>     insights. http://p.sf.net/sfu/splunk-dev2dev 
>>
>>
>>     _______________________________________________
>>     Usbpicprog-technical mailing list
>>     Usb...@li... <mailto:Usb...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>
>

Re: [Usbpicprog-technical] Hebrew

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

Hi Sephy,

Nice to hear that you are so enthousiastic about my little project!
I actually didn't put a single line of code in my software which handles
right-to-left languages, only a "set Locale" command which detects the
default system language.
The fact that the gui changes on right to left operating systems is
handled by the wxWidgets library that I use for the GUI.
Depending on the operating system you are using, there are some switches
that can be set in order to change the GUI back to normal, I don't know
which os you are using?

Having new translations is always a great thing! It will make it
possible for more users to use this peace of software!
I have already written a page on my site about translations:
http://usbpicprog.org/?page_id=158
I do want to release version 0.4.2 soon, I didn't get any complaints
about the beta version, so probably there will just be some language
updates before the release.
It would be very great if you would help me translating this software.
Thank you for your offer!

Kind regards,

Frans Schreuder

On 02/25/2011 07:33 AM, sephy p wrote:
> Hi. My name is Sephy, I am from Israel.
>
> First of all, thank you for your wonderful work!
> Second thing is, I'm having problems with the software. 
> since hebrew is written from right to left, the program shows
> everything oriented to the right and sometimes (in the help section)
> it's mirrored.
> I can send you a picture if you like to show you what I mean.
>
> I prefer using the program in English (left side oriented of course)
> but I think, once the program detects a different locale it sets the
> orientation automatically. I would love to have some solution for
> this, maybe to run the program with a special switch, or having some
> way to enforce (left side) English...
>
> Third thing is, I would love to offer my help and translate the
> program to Hebrew, properly.
>
>
> Again, THANK YOU, for your wonderful work. keep doing so!
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical

[Usbpicprog-technical] Hebrew

[sephy p <li...@gm...>]

Hi. My name is Sephy, I am from Israel.

First of all, thank you for your wonderful work!
Second thing is, I'm having problems with the software.
since hebrew is written from right to left, the program shows everything
oriented to the right and sometimes (in the help section) it's mirrored.
I can send you a picture if you like to show you what I mean.

I prefer using the program in English (left side oriented of course) but I
think, once the program detects a different locale it sets the orientation
automatically. I would love to have some solution for this, maybe to run the
program with a special switch, or having some way to enforce (left side)
English...

Third thing is, I would love to offer my help and translate the program to
Hebrew, properly.


Again, THANK YOU, for your wonderful work. keep doing so!

Re: [Usbpicprog-technical] 18f45k22

[Matt H. <mh...@me...>]

diff -rupN firmware-0.4.2-beta-orig/prog.c firmware-0.4.2-beta/prog.c
--- firmware-0.4.2-beta-orig/prog.c	2011-01-22 11:24:58.000000000 -0500
+++ firmware-0.4.2-beta/prog.c	2011-02-16 02:02:58.050744634 -0500
@@ -182,14 +182,26 @@ char bulk_erase(PICFAMILY picfamily,PICT
 			pic_send(4,0x00,0x94A6); //BCF EECON1, WREN
 			break;
 		case P18F2XXX:           //also valid for 18F4XXX
+		case P18F4XK22:
+		case P18LF4XK22:
 			set_address(picfamily, 0x3C0005);
-			pic_send(4,0x0C,0x3F3F); //Write 3F3Fh to 3C0005h
+			if(pictype == P18F2XXX)
+			{
+				pic_send(4,0x0C,0x3F3F); //Write 3F3Fh to 3C0005h
+			} else { // // P18LF/F4XK22
+				pic_send(4,0x0C,0x0F0F); //Write 0F0Fh to 3C0005h
+			}
 			set_address(picfamily, 0x3C0004);
 			pic_send(4,0x0C,0x8F8F); //Write 8F8Fh to 3C0004h
 			pic_send(4,0x00,0x0000); //NOP
 			lasttick=tick;
 			pic_send(4,0x00,0x0000); //hold PGD low until erase completes
-			DelayMs(P11);
+			if(pictype==P18F2XXX)
+			{
+				DelayMs(P11);
+			} else { // P18LF/F4XK22
+				DelayMs(P11K);
+			}
 			break;
 		case P18FX220:
 		case P18FXX31:
@@ -582,8 +594,12 @@ char write_code(PICFAMILY picfamily, PIC
 			//}
 			break;
 		case P18F2XXX:
+		case P18F4XK22:
+		case P18LF4XK22:
 			pic_send(4,0x00,0x8EA6); //BSF EECON1, EEPGD
 			pic_send(4,0x00,0x9CA6); //BCF EECON1, CFGS
+			if((pictype == P18F4XK22)||(pictype == P18LF4XK22))
+				pic_send(4,0x00,0x84A6); //BSF EECON1, WREN
 			set_address(picfamily, address);
 			for(blockcounter=0;blockcounter<(blocksize-2);blockcounter+=2)
 			{
@@ -967,6 +983,11 @@ char write_data(PICFAMILY picfamily, PIC
 					pic_send(4,0,0x6EA7); //MOVWF EECON2
 				}
 				pic_send(4,0x00,0x82A6); //BSF EECON1, WR
+				if((pictype==P18F4XK22)||(pictype==P18LF4XK22))
+				{
+					pic_send(4,0x00,0x0000); //NOP, two NOPs required before polling
+					pic_send(4,0x00,0x0000); //NOP, write starts on 4th clock of this instruction
+				}
 				//pic_send(4,0x00,0x0000); //NOP, when not polling for the WR bit, the PIC still needs at least 4 clocks
 				lasttick=tick;
 				do
@@ -1114,8 +1135,12 @@ char write_config_bits(PICFAMILY picfami
 		case P18F6X2X:
 		case P18FXX2:
 		case P18F2XXX:
+		case P18F4XK22:
+		case P18LF4XK22:
         		pic_send(4,0x00,0x8EA6); //BSF EECON1, EEPGD
 			pic_send(4,0x00,0x8CA6); //BSF EECON1, CFGS
+			if((pictype==P18F4XK22)||(pictype==P18LF4XK22))
+				pic_send(4,0x00,0x84A6); //BSF EECON1, WREN
 			if((pictype==P18FXX2)||(pictype==P18FXX31)||(pictype==P18FXX31))
 			{
 				//goto 0x100000
@@ -1130,8 +1155,13 @@ char write_config_bits(PICFAMILY picfami
 				//LSB first
 				pic_send(4,0x0F,((unsigned int)*(data+blockcounter))|(((unsigned int)*(data+blockcounter))<<8));
 				pic_send_n_bits(3, 0);
-				PGC=1;	//hold PGC high for P9
-				DelayMs(P9);
+				PGC=1;	//hold PGC high for P9 (or P9A for 4XF/LFK22 config word)
+				if((pictype==P18F4XK22)||(pictype==P18LF4XK22))
+				{
+				        DelayMs(P9A);
+				} else {
+				        DelayMs(P9);
+				}
 				PGC=0;	//hold PGC low for time P10
 				DelayMs(P10);
 				pic_send_word(0x0000); //last part of the nop
@@ -1142,8 +1172,13 @@ char write_config_bits(PICFAMILY picfami
 				set_address(picfamily, address+((unsigned int)blockcounter)+1);
 				pic_send(4,0x0F, ((unsigned int)*(data+1+blockcounter))|(((unsigned int)*(data+1+blockcounter))<<8)); //load MSB and start programming
 				pic_send_n_bits(3, 0);
-				PGC=1;	//hold PGC high for P9
-				DelayMs(P9);
+				PGC=1;	//hold PGC high for P9 (or P9A for 4XF/LFK22 config word)
+				if((pictype==P18F4XK22)||(pictype==P18LF4XK22))
+				{
+				        DelayMs(P9A);
+				} else {
+				        DelayMs(P9);
+				}
 				PGC=0;	//hold PGC low for time P10
 				DelayMs(P10);
 				pic_send_word(0x0000); //last part of the nop
diff -rupN firmware-0.4.2-beta-orig/prog.h firmware-0.4.2-beta/prog.h
--- firmware-0.4.2-beta-orig/prog.h	2010-12-13 10:33:41.000000000 -0500
+++ firmware-0.4.2-beta/prog.h	2011-02-16 01:28:31.474548425 -0500
@@ -35,7 +35,7 @@ typedef enum _PICTYPE{
         P16F7X,P16F7X7,P16F87X,P16F72,P16F87,P16F54,P16F57,P16F785,P16F59,P16F91X,P16F88X,
         P16C6XX,P16C55X,P16C7XX,P16C64x,P14000,P16C50X,P16C432,P17CXX,P17C7XX,
         P18FXX39,P18F6X2X,P18FXX80,P18F8410,P18F6XJXX,P18F45J10,P18F97J60,P18F1X30,P18FXX23,P18FXXK20,
-	P24FJXXXGA0XX,P24FJXXXGA1,dsP30F,dsP33F,P24H,P10F200,P10F202,P12F61X,P16F716,P18FXX31,P18FX220,
+	P24FJXXXGA0XX,P24FJXXXGA1,dsP30F,dsP33F,P24H,P10F200,P10F202,P12F61X,P16F716,P18FXX31,P18FX220,P18F4XK22,P18LF4XK22,
  	I2C_EE_1,I2C_EE_2,P12F508,P24FXXKAXXX,
  	UPP_INVALID_PICTYPE
 }PICTYPE;
@@ -61,9 +61,11 @@ unsigned char read_data(PICFAMILY picfam
 
 // delay times according to programming specification for PIC18F:
 #define P9 2
+#define P9A 6
 #define P10 1
 #define P11 10
 #define P11A 5
+#define P11K 16
 
 // delay times according to programming specification for PIC16F:
 #define Tera 10
diff -rupN firmware-0.4.2-beta-orig/upp.c firmware-0.4.2-beta/upp.c
--- firmware-0.4.2-beta-orig/upp.c	2011-01-07 06:43:16.000000000 -0500
+++ firmware-0.4.2-beta/upp.c	2011-02-04 01:59:53.576524142 -0500
@@ -522,7 +522,9 @@ unsigned char set_pictype(unsigned char*
 		case P16F716:
 		case P17C7XX:picfamily=PIC16;break;
 		case P18F2XXX:
-		case P18FXX2:picfamily=PIC18;break;
+		case P18F4XK22:
+		case P18LF4XK22:
+		case P18FXX2:
 		case P18FXX39:
 		case P18F6X2X:
 		case P18FXX80: