Menu
▾
▴
Re: [Usbpicprog-technical] Unstability when programing large pieces of code
|
From: fatih g. <gok...@gm...> - 2011-04-15 08:50:29
|
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
>
>
|
