Re: [Usbpicprog-technical] Unstability when programing large pieces of code

[Marcelo M. <mm...@ho...>]

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...
To: usb...@li...
Subject: Re: [Usbpicprog-technical] Unstability when programing large pieces of code



  


    
    Message body
  
  
    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...
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