PSOC5LP programing flakiness w/miniprog3 rev B on custom hardware

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

When I attempt to program a PSOC5LP (from PSOC Creator 3.1) using the Rev B miniprog3, the Program operation often halts/does nothing (indefinatly).  Unpluging the USB cable to MiniProg3 releases the stuck program operation.

   

Similarlay, the Select Debug Target dialog is generally rather slow / non-responsive.  (Eg selecting the window and relocating on the screen, or selecting port properties can take 10 seconds to update)  Often to get anything this to work, each time I try to program, I have to first unplug/plug in the MiniProg USB.  Then select debug target and connect, and then go to program.   This works 25% of the time. 

   

Programming mode is SWD protocol with reset acquire mode, external power, and 5 pin connector.  Clock speed has been lowered to 200kHz.

   

I suspect the problem is my prototype hardware with the PSOC, but have no idea what - as flakiy behavior isn't much of a guide to root causing the problem!

   

My PSOC hardware has 3.1V applied to Vddd, Vio, and Vdda.  1.8V is applied to Vccd and Vcca.  I *believe* power is applied to all pins and they are properly bypassed.   (The package is 68 DFN - which was very difficult to handsolder.  I've inspected w/microscope and believe all the pins are soldered.)  My hardware also lacks a proper programming header, thus I've place the 5 pin connector on the end of the miniprog3 and have 3 inch wirewrap wires going to the hardware.    Miniprog3 is connected to the PSOC pins labeled Vddio1, SWDIO, SWDCK, CFG-XRES, and GND (VssD, VssA).

   

Once programmed, thus far my rather simple programs (LEDs and UART output) seem to always startup as expected with power cycle, or when the miniprog releases reset.

   

I know there are lots of unknowns here - but possibly others with more than a few days PSOC experience have tips other than re-run the PCB.  (That will happen once I know most of what is wrong with in....)

   

 

   

TIA.

   

Chris

6 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Welcome in the forum, Chris.

   

Your description smells a bit as if the PSoC doesn't come out of reset fast enough. Are your voltages each bypassed with caps as suggested?

   

 

   

Bob

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

  I am running virtual machines on macintosh, and have had some of the same issues.

   

   The first run of our boards, we missed the VDD/VCC lines that *should NOT* be tied to the 5V or 3.3V power supply.  Those boards were DOA.  If you are running at a lower voltage, your boards might not be DOA, but horribly crippled.

   

   In regards to the 68pin parts, we often have at least one pin that doesn't solder right during oven heating. It varies, but is usually a pin not necessary to functionality and we reroute in the code.

   

   I would suspect the same for you.  A hot air gun and some flux might fix this.  We have a 50/50 success on prototype boards fixing this.

   

   I heartily recommend using the TQFP 100 package where space permits.  It's gull wing design allows for fixing such stuff for small run boards.

0 Likes
Anonymous
Not applicable

Thank you Bob for the tip.

   

The reset pin (XRES, pin 10 on QFN68) is tied to 22k pullup to Vddd (~3.1V).  The only other connection is to the Miniprog3 via 3" wire. 

0 Likes
Anonymous
Not applicable

Thank you WSM. 

   

Rechecked the supply voltages and I have all of them correct.  However, I have read somewhere that I still need to turn off the internal 1.8V regulator - as its still creating 1.8V - from my 1.8V supply - somehow.

   

Definatly will use the TQFP next time.  It took more than an hr to put the QFN on, but all the pins are soldered.  (I checked again under the microscope.)  The other trick for QFN is to make the footprint much larger so that the iron can touch the pad.  But I've also ordered a hot air pencil to help with this board.

   

Re bypass caps, all power pins have a 0.1uF around 3mm from the pin.  (The ground return path via the GND plane is ~5mm).  For each digital supply 3.x and 1.8, there is a single 1uF cap 'nearby'.  The 3.x V supply doesn't have any other caps (probably need one for the LDO), but the 1.8V switcher has 10uF ~26mm from PSOC center.

0 Likes
Anonymous
Not applicable

So I think the answer to the question is to update the software.

   

My PSoC Programmer was version 3.22.0 ?  (build 2034?) - I've updated to 3.22.3 (build 2043?) and it started working.  At least I think that is what seems to have fixed it.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Here is recommended bypassing -

   

 

   

    

   

         

   

http://www.cypress.com/?rID=43337     AN61290 - PSoC® 3 and PSoC 5LP Hardware Design Considerations

0 Likes