Menu
▾
▴
Re: [Usbpicprog-technical] Unstability when programing large pieces of code
|
From: Frans S. <fra...@gm...> - 2011-04-15 09:10:25
|
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 |
