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