CY8C4146FNI-S433 MiniProg3 Chip Detects but getting "EraseAll Operation Failed!"

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

cross mob
LandonC
Level 2
Level 2
5 sign-ins First like given First solution authored

Good Afternoon, 

I'm currently trying to program a brand new CY8C4146FNI-S433 on a custom board with a MiniProg3 and PSoc Programmer 3.29.1

I have connected the MiniProg3's SCLK, SDAT, XRES GND, and VARG to the corresponding pins on the Cypress chip.

PSoC programmer is able to auto detect the device correctly, however it constantly runs into a "FAILED! EraseAll operation failed"

I am able to "read to log" correctly, and I've tested that the pins are properly soldered to the device.
(I tried to program when removing one pin at a time, the device was undetected, upon reconnecting the pin, it was able to detect the device.)

When I read the flash, it says that the state is "OPEN" but I'm not convinced.

I've tried every combination I can think of when it comes to the settings, but unfortunately nothing is removing this EraseAll error.

This is the second chip I have tried it on with the same issue.

 

The only things I can think of are:

  • The Decoupling capacitor is too far away from the chip and is somehow causing an issue during power cycle.
  • The device was damaged when it was being soldered (as per datasheet (260C for 30sec), reflow temp did not pass 235C.)
  • Firmware on the Miniprog3 is incorrect or my hex file is in the wrong directory.

I'm not convinced that the device is damaged since I can read flash and detect the device. (Am I wrong in this assumption?)

I have removed all other active components from the board to remove the load on the VDD line.

Is there something I'm missing? I didn't do much with changing settings and I'm working with a hex file that I received from the company that wrote the firmware.

I pretty much just downloaded PSoC programmer, Connected the MiniProg3 and went to work. Is there some setup I missed?

Any information would be greatly appreciated!

Thanks!

FlashSave.PNGPrintout_CypressProgrammer_EraseAllFailed.PNG

0 Likes
1 Solution

Good Afternoon Bibi,

I have good news and not so good news.

My board that I'm working with has two of these cypress chips on it, I figured since they were both using the identical circuitry that they would work the same.
Unfortunately, I was wrong in this assumption.

I decided to try to program the other cypress section of the board because I was running out of ideas (Honestly I should have done this earlier...)

The program successfully programmed to the chip on the other side of the board, but cannot program to the original side. I have a sneaking suspicion that the trace lengths on the original chip are too long, too skinny, or are picking up some kind of interference.

Nevertheless, my new workflow is going to be soldering chips to the secondary spot, programming, then migrating to the original location. Not fun, but it should work. (I also need to test and see if that side of the board just can't program or if it has an absolute lack of functionality.)

Thank you for taking your time to walk me through this issue, and while we didn't exactly come to a conclusion on what was wrong, I'm going to guess a hardware issue/poor-design. I'm hoping the information in this thread will come to some use to other users at some point.

Again, many thanks!

View solution in original post

0 Likes
15 Replies
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi @LandonC

I do not think there is anything missing with the setup. However, could you please share your schematics so that we can review the same? Primarily what we are looking for is the power line connections and XRES. 

Also, I see that the PSoC Programmer points out that the device is not powered. Could you please check and confirm the VTARG connections?

Thanks and Regards,
Rakshith M B
0 Likes

Good Morning Rakshith,

Thank you for taking the time to assist me with this.

Apologies for the misleading picture, the device was powered when the readout displayed the error, but things were disconnected when I made the screenshot for the post. Mainly wanted y'all to see the readout and the settings I was currently using.

Here is a picture of the schematic that the board is based on where the bottom left is the programming header and +V is connected to VTARG:Schematic_Cypress-wth-ProgHeader.png

Please let me know if I can add anything else to assist you, thanks again!

0 Likes

Hello.

In PSoC Programmer, change Programming Mode from Power Cycle to Reset.

Are you using an external power supply for the pcb?
If yes, disconnect it while Miniprog3 is attached.  Otherwise, lack of isolating Vdd of Miniprog3 from the external source can cause issues.

You could also try the 5-pin Miniprog3 connector.  I've forgotten the delta to the 10-pin connector, but people have better success with the 5-pin.

Since the SWD connector on your pcb is non-standard, I suspect you are using flying wires between Miniprog3 and the pcb connector.  If these wires are longer than 5-10cm in length, the SWD signals aren't reliable.

Good luck with your project.

0 Likes

Good Afternoon BiBi, 

Thank you for this information and for the good luck,

I have tried both an external supply and power supplied by the MiniProg as well.

I also started with the 5 pin connector and a custom pogo pin jig, but moved to the 10 pin to see if that made a change.

From your reply, perhaps I should move to a short header soldered to the pads from the board, to the MiniProg and avoid using the jig altogether for the time being.

I hope to update with my findings soon.

Many thanks again!

 

0 Likes
LandonC
Level 2
Level 2
5 sign-ins First like given First solution authored

Okay, update:

I have short wires ~15mm soldered to the pads of the board but I'm unfortunately still getting the same "Detected but EraseAll operation Failed".

I'm programming at 1.6Mhz, and the crystal is a  32.7680KHZ 12.5PF SMD crystal. 

Could the length of the traces be an issue?
If so:

  • Would they all need to be the same length?
  • Is there a minimum trace width to consider?

Again, thank you all for taking the time out of your day to assist with this.

 

0 Likes

Hi.

Try adding a 4.7k-to-10k resistor from XRES to Vdd.  I've never found the internal XRES resistor to work properly (regardless of PSoC family).

15mm is really good.  They don't need to be exactly the same length.

I'm wondering... if Miniprog3 can't program the device, then why does the memory dump show data?

When you attach Minprog3 to pcb and Minprog3 acquires the chip, what is the voltage reported in PSoC Programmer window (Status box).

Your schematic looks okay BTW.

 

0 Likes

Good Afternoon BiBi,

Just ran a test with both a 10K and 4.7K resistor and unfortunately still no luck.

Voltage reading is hovering around 3380 - 3420 mV

Below is the data I gather when I read to the log

ReadingToLogFromDevice-FirstFlashLines.pngReadingToLogFromDevice-FlashSecurityData.pngThanks again!

0 Likes

Hello.

So far, everything looks right.  It should erase.

Can you lower the speed of SWD to 1.6MHz and try that.

Also, can you measure the voltage on Vccd.  It should be around 1.8V.  Be careful with probes not to short adjacent pins.

Have you tried the Erase command from drop-down menu?  This might show a different behaviour vs trying to download the project.  (I could be mixing up this command with one from a different programmer, I'm not at the bench right now).

I'm still concerned the User Flash area contains data.  From my perspective, these are not brand new devices.

I don't have the chart, but somewhere on Cypress website is a database of Silicon Family codes.  Maybe try to find the chart (it might even be contained in the datasheet) and see if it lines up with 1B02 and AB codes.  Maybe you have a clone chip and not the real thing?

I'm running out of idea's.

edit: Maybe try running PSoC at 5V from Miniprog3?

0 Likes

Good Afternoon BiBi,

Thank you again for your continued assistance, your perseverance is greatly appreciated.

I am getting 1.8 Volts on the VCCD, and unfortunately the change in voltage to 5V does not appear to fix the issue.

If it makes a difference, the flash is now showing as empty.

Maybe one of the pins was loose and the flash showed as garbled data?

This chips are directly from Mouser, unless they got scammed? I'm not entirely sure.

Would a newer MiniProg4 be a better option? Could it be that I possibly fried this programmer?

Weirdest thing to me is that it detects the chip, and doesn't if any one of the SWD pins are disconnected.

Perhaps one of the BGA pads under the chip aren't fully connected?

The chip is showing as obselete so maybe an older version of PSoC Programmer or an older version of the MiniProg3 firmware is needed?

Maybe a diver on my computer or some other program is getting in the way of the programmer successfully completing? I suppose I'll try that on my laptop this evening.

Thanks again!

0 Likes

Hello again.

As long as the chip has connections to the power rails and SWD IO pins and XRES, the rest of the 'balls' don't matter.  Since Miniprog3 reports the part number you're expecting, I'd say the interface is electrically working correctly.

There's another method you can try to program the device.  In Creator, the Debug menu has a Programming option.  Open the project in Creator.  Set up Miniprog3 options from Debug menu.  Try it without external power first (i.e., use Miniprog3 to supply power).  The User Interface is a bit different from PSoC Programmer (okay, it's a lot different!).  You have to Connect and Acquire the target device manually.  Then try to program FLASH.

BTW, do you happen to have one of the Cypress KIT's handy?  You could test Miniprog3 on the KIT to determine if it's functioning properly.

If you Search the forum, the most common device to fail in a Miniprog3 is a diode.  Users have replaced it and Miniprog3 works again.  In other cases, the user blew up Miniprog3 and had to purchase a new one.  I'd hold off purchasing Miniprog4 until you try a few more things.

Maybe you could start another thread and ask about the device part number vs what Miniprog3 reports as 1B02 and AB, and AA Major/Minor Rev codes, to verify device validity.  Hopefully Cypress will answer.

Good Evening BiBi,

Hope you had a good weekend!

I have been able to look elsewhere on the formums and it appears that I do not have a diode issue.

My PSOC Creator is able to see the MiniProg3 as a debug target, but it appears to not let me acquire the port. I can press the "Port Acquire" button, but nothing happens or tells me that it was able to acquire the port. Unfortunately I only have access to the HEX file and not the project itself.

 

I was also able to test on a better multimeter (Fluke) and it appears that the VCCD pin is at 2.1V. Seeing as the  VCCD_ABS is 1.95V, perhaps this shows that there is an error in the chip and it needs to be replaced?

No Cypress KIT, but I'm looking at getting one soon I think.

I also don't have a .1uF cap on XRES which is an optional part that apparently can help fix errors. I need to try that today when I get the chance.

Also the MiniProg3 does not show up as a COM port, rather as a USB Controller in Windows Device Manager.

 

Any thoughts with this new information?

Thank you again so much!

0 Likes

Hello.

Take a look at the bottom of this thread for an image of Windows Device Manager.  Yes, Miniprog3 shows up as a USB Controller.
MiniProg3: This device was recognized but does not... - Infineon Developer Community

Hmmm, can't Acquire Port from debugger.  That's an issue.  Maybe something is not configured in Creator for Miniprog?  Or, as you've suggested, could be something wrong with this PSoC chip.  Yet, PSoC Programmer can acquire the chip.  Since you only have a hex file, I guess stick with getting it to work with PSoC Programmer.

Vccd at 2.1V is really high.  I'm surprised the chip isn't getting hot to the touch.  BTW, Vccd runs the ARM core.

I'll assume Vccd was with Vdd at 3.3V.  Can you measure Vccd  with Vdd at 5V.  I'm wondering if there's a short between solder balls surrounding Vccd A7 (A6, B6, B7).  Not likely B7 (Vss).  Crystal (A6 ball) could be solder shorted to A7.  Try removing crystal. and re-measure Vccd.

Could you also measure Vtarg (at SWD connector on pcb) with Miniprog3 connected to target pcb.  One of your screen captures showed Vdd at 3.420V.  What does it show when set to 5V?

The cap on XRES is for noise filtering.  Not needed here.  However, the pull up resistor on XRES is needed.

Since you've already tried downloading to 2 chips, I suspect changing the chip will give same results.  Wait to see what Cypress says about chip codes (in your new discussion thread).

Check the layout.  Many times I've seen Vccd tied to Vdd by mistake.  And, measure the ball-to-ball spacing (0.35mm center-to-center).

edit: You could make a simple project (or use a Cypress example project) in Creator to toggle a GPIO.  Then you could use Debugger to attempt downloading the project.

Good Afternoon Bibi,

I have good news and not so good news.

My board that I'm working with has two of these cypress chips on it, I figured since they were both using the identical circuitry that they would work the same.
Unfortunately, I was wrong in this assumption.

I decided to try to program the other cypress section of the board because I was running out of ideas (Honestly I should have done this earlier...)

The program successfully programmed to the chip on the other side of the board, but cannot program to the original side. I have a sneaking suspicion that the trace lengths on the original chip are too long, too skinny, or are picking up some kind of interference.

Nevertheless, my new workflow is going to be soldering chips to the secondary spot, programming, then migrating to the original location. Not fun, but it should work. (I also need to test and see if that side of the board just can't program or if it has an absolute lack of functionality.)

Thank you for taking your time to walk me through this issue, and while we didn't exactly come to a conclusion on what was wrong, I'm going to guess a hardware issue/poor-design. I'm hoping the information in this thread will come to some use to other users at some point.

Again, many thanks!

0 Likes

Hey!  That's good news.
The goal is to get the PSoC functional and you've achieved that.

Just curious..., do you have individual SWD headers for each PSoC?  I assume yes, and that's why you could program the second PSoC.

I think if you closely compare schematic differences between the two PSoC's (and possibly the layout), you'll find your answer.

Good luck with your project.

Yes, there were individual headers for each PSoC, they shared VCC and GND, but nothing else.

After looking at my schematic and testing continuity on my board, it appears that the ground pin on the particular problem chip was not connected to anything.

I'm assuming I could still talk to it because it was getting grounded through the other pins.

Thanks again for all of your help!

0 Likes