Menu
▾
▴
Re: [Usbpicprog-technical] Unstability when programing large pieces of code
|
From: Marcel K. <mak...@gm...> - 2011-04-14 21:45:35
|
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 |
