Menu
▾
▴
Re: [Usbpicprog-technical] Unstability when programing large pieces of code
|
From: Marcelo M. <mm...@ho...> - 2011-04-15 22:47:48
|
Dear Frans:
I have tried your new firmware.
I still have errors when programming the PIC16F877A, at random locations each time. However, I noticed that the pattern changed.
Instead of FF 3F repeated 8 times and then 00 00 another 8 times, now I only see FF 3F repeated 8 times. No more 00 00.
I do not know if this may shed some light... just wanted to share my findings.
Thank you.
Best regards
Marcelo
Date: Fri, 15 Apr 2011 11:09:41 +0200
From: fra...@gm...
To: usb...@li...
Subject: Re: [Usbpicprog-technical] Unstability when programing large pieces of code
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...>
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
------------------------------------------------------------------------------
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 |
