CY8C4014SXI-420 only able to succesfully program once

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

cross mob
MaHo_4757026
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted

As the title mentioned, I've made custom board, leaving all components off and only mount CY8C4014SXI-420 (8-pin SOIC) and 2x100nF and 1uF (VDD and VCCD) as specified by the datasheet, I'm only able to program the device the first time? I'm using MiniProg 4 and programmer application (3.29) from Cypress. I've measured 1.8V on VCCD and attached VDD to the MiniProg4.

I know that the MiniProg needs to power-cycle to simulate a reset due to the lack of xres pin. Can my .hex program cause the device from preventing to be re-programmed? In one of the first lines I set p1.6 high, can this be an issue? Should I put some delay before?

Result:

                                                                                  | FAILED! PSoC device is not acquired! Check connection of the chip to the programmer

                                                                                  | Please, check the following items:

                                                                                  |  - the connection between the programmer and the PSoC;

                                                                                  |  - the correct programming protocol is selected;

                                                                                  |  - the correct connector option is selected.

Memory Types Scan Device Requested

Power On at 18:33:25                                                              | MiniProg4 (CMSIS-DAP/BULK/191A0C8B02237400)

0 Likes
1 Solution

WOW!!!  Great progress.

I imagine you'll be able to erase/program all the 'bricked' chips using Kitprog.

I think the conclusion is: don't use Miniprog (or CMSIS-DAP programmers) when SWD pins are designated as GPIO in target application.  And this likely applies to all PSoC devices that have this SWD/GPIO association capability.

Kitprog does not use CMSIS-DAP methods.  This is why it acquire/programs properly.  And as you discovered, there's a 'connection sequence' when connecting everything together.

As for Kitprog on KIT-042, it must be relying on pull-up resistor R10 on Kit-042 pcb in order to sense it should be in Kitprog programming mode, instead of some other mode (like Mass Storage Programmer).

And, if you really wanted to, you can turn Kit-042 into a programmer for your project (with a bunch of work porting the code).

Using the CY8CKIT-049 to Program Another PSoC® ... | Cypress Developer Community

But, Kitprog already does what you need.  Hurraaaaay!  I'm sure it must have been a satisfying feeling that something finally worked.

View solution in original post

46 Replies
BiBi_1928986
Level 7
Level 7
First comment on blog 500 replies posted 250 replies posted

Hello MaHo.

See my article on programming PSoC 4000 chips for some tips.  The last reply I added today points to SWD wires being too long.  5cm is best.  I don't have Miniprog, I use KitProg.  Programming method is the same, uses Power Cycle.

Solution: Use Kitprog to Program PSoC 4000 with... | Cypress Developer Community

Also, I found P1.6 causes strange PSoC behaviour with a blank (never been programmed) PSoC.  After the first time of programming, PSoC behaves as expected.  Read text in weblink for description.

User target PSoC s/w should not cause any issue.  I use 4013 chip and disable SWD function to use all GPOI's.  Even this is not a problem to reprogram once PSoC is acquired.  It can even be s/w protected, but not at highest level of protection or else it's not re-programmable.

Question: does the 4014 still function with the first file that was successfully downloaded?  If yes, then the chip should still be good.  If no, then maybe the chip is damaged.

Hope this helps.

0 Likes

Hi, Thanks for your reply.

The programming wires are already very short (<5cm).

I can also confirm that the application runs after programming. It seems I'm not able to re-program again. I've set "debug select" to "GPIO" because I need those gpio's, but as far as I can see, this should not cause a problem.

Regarding p1.6, I've already seen in the datasheet, tried to pull-upp and down, no effect. Tomorrow I will going to retry with a new bunch of chips....

0 Likes

Hi.

You are doing everything correct as far as I can see.

I disable debug to recover more GPIO pin usage on 4013 and 4014 devices.  No issue to re-program them.  I use KitProg though.  Miniprog should have no issue either.  So, there must be something else here to discover.

What is target voltage?  3.3V?  5V? 1.8V?  Do you set Miniprog to same voltage?

Do you set Miniprog to autodetect the device?  You could try manually configuring Miniprog to the target device in place of autodetect.

Lastly, you could remove the 1uF capacitor from Vdd, leaving the .1uF in place.  Maybe Miniprog is not doing proper Power-Cycle?

Hi,

I'm using 3.3V target voltage, I'm using MiniiProg to supply the psoc4, as it'is the only thing connected atm. I tried autoconnect as well manual method. Removing the 1uF cap I tried a few days ago. But as this is recommended by the datasheet I would say this should not cause issues.

So litterally I have connected to my MiniProg:

VTARG (direct connected to pin 4)

GND (direct connected to pin 5)

SWCLK (direct connected to pin 1: P3.1)

SWDIO (direct connected to pin 8: P3.0)

The psoc has:

- 100nF and 1uF on VDD (3.3V)

- 100nF on VCCD (1.8V)

0 Likes

Hi.

The 4014 connections look good.

How about connections at Miniprog4?

I know with original Miniprog, people had better success with the 5-pin connector vs 10-pin.

Which reminds me to ask, are you selecting the Miniprog4 connector size 5-pin vs 10-pin in the Programmer s/w?

Maybe uninstall Programmer s/w and re-install.

Maybe try a previous Programmer version, 3.28.1 (it supports Miniprog4).

Maybe try a different USB port.

Could it be the sequence of:

launching Programmer,

then connecting Miniprog4 to USB,

then connecting target to Miniprog4,

then clicking on Connect?

Maybe alter the sequence to see if it makes a difference.

Capture a screen shot of Programmer window showing configuration for us to see.

Since I don't have a Miniprog, I'm running out of suggestions.

If none of the above works, this is truly a Cypress support question.

Hopefully, someone from Cypress will jump in with suggestions.

Thanks, see attached picture:

cypress.jpg

When I receive the new parts, I will try to make some tests.

0 Likes

Can you please share the screenshot of the entire PSoC Programmer window when the programming fails? I want to see the various programming parameters, detected voltage etc. to see if everything's okay.

Regards,

Dheeraj

0 Likes

If you want the MiniProg4 to power your device, you need to click the Toggle Power icon at the top, next to the Program icon. You should see Power Status set to ON and voltage detected mentioned under Status once you do that.

Let me know if it works once you do that

Regards,
Dheeraj

0 Likes

Hi Dheeraj, yes this works, I can see power status "on" and "3300mV". However, still not able to program.

0 Likes

Hello MaHo.

The photo of Minprog4+Target shows the target connected to 5-pin port.

However, the image of PSoC Programmer window shows 10-pin port is selected.

So, select the 5-pin port in PSoC Programmer or, move the wires to the 10-pin port on Miniprog4.  Try both to see which one might work.

0 Likes

I can't choose 5p? The option is greyed out?

0 Likes

Also 10p connector does not work:

miniprog4.jpg

0 Likes

You said "I'm only able to program the device the first time", are you sure you didn't set chip protection config to ‘kill’? (set chip protection to KIll in Creator and program silicon use PSoC Programmer with chip lock option enabled in 'Programmer Option' window)

0 Likes

It's set to "Open"

0 Likes

This morning I made some progress using the 5p connector again with new PsoC 4:

First try to autodetect part, this will succeed:

pic1.png

Then, next step is only erase part (this will also succeed):

pic2.png

Then program the part via PSoC Creator 4.3 (this will also succeed):

pic3.png

However, I don't understand why "Protecting" is mentioned here?

From this point on, I'm not able to do anything anymore with the mcu, I cannot acquire it anymore. Application is running, so seems like some kind of protection or disturbance of p1.6 by setting it as output?

I also noticed that 1800mV was presented by PSoC programmer before I flashed the application, after programming I see 3300mV? Also check my System:

system.png

Edit: I tried uploading an new and empty project, that succeeded, so it seems something is definitly is going wrong with my project, I will do some additional testing....

0 Likes

Hi MaHo.

I noticed the 1.8V read by Miniprog4 as well.  That's unusual.

Can you check your layout by looking at the physical pcb (and Ohm'ing it out) and ensure there is no other connection to Vccd PSoC pin3 otherthan the 0.1uF capacitor, and the other end of 0.1uF is going to Ground.

The only way I can see Miniprog4 measuring 1.8V is:

if Miniprog4 is broken,

if there's a short between PSoC pin3 and PSoC pin-4,

if Miniprog4 Vtarg is connected to PSoC pin-3,

if PSoC is damaged.

Also, I'm wondering why you use PSoC Programmer to reset/erase PSoC, and then switch to PSoC Creator to program it?

Note: I just saw your edit update.  Still, worth checking the pcb though.

0 Likes

Hi,

I've done several tests with the fresh PSoC4 and blank project. I'm able to (re)program all times without issues...... until I set "Debug Select" to: "GPIO". From that moment I'm not able to get access to the device anymore. This was all tested in PSoC Creator 4.3 (without using PSoC programmer).

Please let me know what to do?

0 Likes

Hi.

When you open the project window in PSoC Creator, along the top is a menu (drop down list) that allows you to change the project from "debug" to "release".  Make sure this is set to "release", then build the load and try to program again.

0 Likes

hi, no this doesn't work either (with already flashed/broken PSoC), also I cannot access the device from PSoC programmer as mentioned (after first flash via PSoC Creator 4.3 setting debug select to "GPIO").

Edit1: every time I give it a try, I "brick" a PSoC. So just to be sure, do you mean that I have to give this a try with a fresh PSoC?

Edit2: Never mind, also bricked this fresh PSoC, even when setting to "Release"

0 Likes

I feel your frustration.

If you try to re-program a bricked device with the blank project, does this work?

0 Likes

Hello MaHo.

You haven't mentioned your development environment.

I found this note in PSoC Creator User Guide with respect to using 3rd party IDE:

IMPORTANT: All devices using 3rd party programmers except μVision using MP3 require that the project exported to the appropriate IDE have a System Editor Debug Select value of anything other than GPIO. If a project with Debug Select set to GPIO is exported, it will be able to program only one time. Subsequent attempts to program via the 3rd party will fail. This is a limitation of the Arm standard acquire sequence, which is not aware of the special acquire sequence used by Cypress for our devices.

So, are you using Keil uVision, IAR, Eclipse, other?

This could explain why you can only program PSoC only once.

Hi,

I'm not able to re-program a bricked device.

Good catch about the Dev envoirement! I'm using standard PSoC Creator 4.3. So this should not cause any issue right?

Anyway, thanks for support!

Running out of ideas....... probably the last thing I will try is soldering PSoC directly to the wires with decoupling caps.

0 Likes

Hi MaHo.

Soldering the wires/cap's (keeping them short) to 4014 is not a bad idea.  Worth one more try.  Let's hope the other PSoC's aren't bricked, but in a state that can be recovered.

4013 and 4014 in SO-8 packages can be programmed with GPIO in place of debug SWD because I do it all the time with Kitprog.  I can FLASH program in PSoC Programmer 3.28 and in PSoC Creator 3.1, 3.3, without issues.  From reading other threads, other people have programmed 4013/4014 SO-8 with Miniprog3.  So, why can't Miniprog4?

BTW, have you looked under the HELP menu in PSoC Programmer for the Miniprog4 documentation?

This is looking more like something Cypress will need to respond to.  You've narrowed it down to setting debug SWD pins to GPIO usage, is the culprit.  Either Miniprog4, Creator 4.3 or PSoC Programmer, is at fault.

0 Likes

Hi MaHo.

I just found this release note on PSoC Programmer 3.29.  There's a list of issues with version 3.29 that addresses SWD vs GPIO option.

PSoC® Programmer Release Notes (cypress.com)​  Doesn't look good.

I suggest you try PSoC Programmer 3.28.  However, I don't know if it supports Miniprog4.  I think you have to uninstall version 3.29 before installing 3.28 otherwise things might get messed up.  You'll need to read the installation notes.

PSoC Programmer Archive (cypress.com)

edit: I just read the release notes for Miniprog4 and it is supported in PSoC Programmer 3.28.

Hi,

Just tried 3.28 and 3.28.5. Both same result:

Failed Connect to | Can't Open CMSIS-DAP port

Problaby because firmware on MiniProg4 has been updated. Btw, I found another bug :

bug.png

0 Likes

Seems the issue can be related to:

"When using standard CMSIS-DAP programmer/debugger, the device flash should be erased or contain an application that has SWD or JTAG selected in PSoC Creator ('Debug Select' option in System Tab). When GPIO is selected in this option, debug pins are disabled in start-up code of user application. PSoC Programmer or 3rd party tools then cannot access the device. The only option for accessing the device, when debug pins are configured as GPIO, is to enter Cypressspecific Test Mode, which is not supported with standard CMSIS-DAP transport. This can be done using following programmers: MiniProg3, MiniProg4, KitProg3 and using KitProg1 or KitProg2 in proprietary mode."

As described in: https://community.cypress.com/external-link.jspa?url=https%3A%2F%2Fwww.cypress.com%2Ffile%2F512826%2...

Now to find out how to get my MiniProg4 in "Cypressspecific Test Mode".......

0 Likes

I think I need PSoC programmer V3.28, but then I need Kitprog 2 that is not supported on MiniProg4 if I'm right......

0 Likes

In the meantime I also tried connecting to CY8CKIT-042 (CY8C4245AX*-483) with MiniProg4, the result (all tested with PSoC Programmer v3.29):

1. System Debug select to: "GPIO", programmed via Kitprog (onboard DevKit) PSoC Creator 4.3

- Not accesible via MiniProg4 with "power cycle" reset

- Accesible via MiniProg4 with "normal reset"

2. System Debug select to: "SWD", programmed via Kitprog (onboard DevKit) PSoC Creator 4.3

- Accesible via MiniProg4 with "power cycle" reset

So the issue seems to be related to MiniProg4 for now, I will try to program my custom pcb with the onboard Kitprog to see if this will work. It's however interesting to see that it is possible to perform the reset by power cycle?

test.jpg

0 Likes

Hi MaHo.

Good to hear you have Kit-042.  Yes, you can wire the Kitprog from Kit-042 over to the 4014.  Be sure to disconnect whatever resistor(s) from Kit-042 to isolate Kitprog.

So, here's the quick way to fake out a Power Cycle with Kitprog.  Simply connect Kitprog XRES to 4014 Vdd pin.  When Kitprog 'thinks' it's reseting 4014, it's actually doing a Power Cycle from 4014 perspective.  XRES will normally sit 'hi' which is what you want.

So, don't worry that you can't select Power Cycle if using PSoC Programmer.  And by the way, you don't have to configure anything if you use PSoC Creator and program from the Debug menu's.

Now, this brings us to the voltage applied to 4014 signals.  When I use Kitprog (from KIT-059), it supplies 5V.  See the "Solution..." link earlier in this thread.  KIT-042 Kitprog might supply 3.3V to it's signals (3.3V is sourced from voltage regulator on Kit-042).  This is okay.

And FYI... I have used Kitprog to Power Cycle program CY8C4245 and 5LP.

Good luck with your test.

Hello MaHo.

If you want to see the low level info on PSoC 40xx SWD, here's the Cypress programming specification:

https://www.cypress.com/file/409516/download

I think the Cypress reference to 'proprietary mode' was Cypress's way of saying, they have other methods that are different from the standard CMSIS-DAP, while still using SWD interface.

Inside the PSoC 4000 Architecture TRM, it says there is a Test Mode.

Inside the PSoC 4000 Registers TRM, there is a register, TST_MODE, where bit 31 if set, puts PSoC into test mode.  Other 'bits' in this register are also interesting.  Of course, it assumes you can 'acquire' the device, which at the moment, is not working.

I haven't found any more info on using Test Mode.  A bit of a mystery.

I'm guessing some sort of low-level CLI is used in conjunction with PSoC Programmer and Miniprog4 (or Kitprog) and this method might be able to recover SWD port pin functionality.  i.e., unbrick the device.

0 Likes

Hi,

I'm struggeling to get this to work OK. What I did, I removed R32, R33 and R34 from DEV board: https://www.cypress.com/file/457841/download

Then connected flatcable to connector J6, wired GND, XRES, SWDIO and SWCLK to my custom board. When powering the DEV board by attaching sub I get this message:

>KitProg bootloader device is detected

>Please close all ports, then navigate to the Utilities tab and click the Upgrade Firmware button to recover Bridge

I can perform the DEVKIT FW update, but this seems not to solve this message when re-attaching the USB power.

Any hints what I can try?

0 Likes

Hi MaHo.

You removed the correct resistors and connected to the right connector.  Good.

The message is referring to the Kitprog f/w (on KIT-042) being out of date.  You can either update it by going to the Utilities tab menu, or ignore it.  The message doesn't prevent you from using Kitprog (I use PSoC Programmer 3.28.0).  I used Kitprog with old f/w to program 4013 device without issues.  I eventually purchased a second KIT-059 and updated Kitprog f/w, and it programmed 4013 also.

If PSoC Programmer is still showing that message after updating Kitprog f/w, then I don't know what's going on.

I think you would have to:

close PSoC Programmer,

disconnect Kitprog USB from computer,

disconnect Kit-042 from all power supplies.

Then, open PSoC Programmer, attach Kitprog to USB and see if PSoC Programmer complains.

You can also use PSoC Creator to program 4014 using Kitprog from the Debug menu.  I don't think you'll see the 'update f/w' message from that menu.

When you mention you can perform DEVKIT FW update, are you referring to updating Kitprog f/w, or to PSoC 4245 f/w?

0 Likes

Hi BiBi,

Unfortunately, it's preventing me from programming because it's not being detected in "Port section". This happened by removing these 3 resistors that forward SWDIO, SWCLK and XRES to the onboard PSoC4. It seems the host PSoC5 goes into some kind of bootloader mode due to a certain level on certian pin?

Edit: it seems to be related to the R34 (XRES resistor), placing this jumper back, it is not mentioning anything about "bootlader device"

0 Likes

Hi MaHo.

Since I don't have KIT-042, I can't replicate the issue.  Sorry.

Maybe there is something mentioned on another forum thread that talks about using Kit-042 Kitprog for programming other devices.  I'm sure there will be.

If replacing R34 keeps Kitprog happy, that's okay.

Any difference using PSoC Creator vs PSoC Programmer?

Or do they behave the same?

0 Likes

Ok, some new developments......

I'm able to aquire, erase and program the device with PSoC programmer as well PSoC Creator 4.3, finally

I have to mount R34 (XRES), remove R32 (SWDIO) and R33 (SWDCLK) (all 0R jumpers).Then I have to connect usb cable (without my target board connected!), then, after booted, I can plug in my target board and I'm able to aquire, erase program. For now I've tested this with PSoC programmer v3.28, I will also try with v3.29. Of course I still don't have a clue what is wrong atm.

test_setup.jpg

0 Likes

WOW!!!  Great progress.

I imagine you'll be able to erase/program all the 'bricked' chips using Kitprog.

I think the conclusion is: don't use Miniprog (or CMSIS-DAP programmers) when SWD pins are designated as GPIO in target application.  And this likely applies to all PSoC devices that have this SWD/GPIO association capability.

Kitprog does not use CMSIS-DAP methods.  This is why it acquire/programs properly.  And as you discovered, there's a 'connection sequence' when connecting everything together.

As for Kitprog on KIT-042, it must be relying on pull-up resistor R10 on Kit-042 pcb in order to sense it should be in Kitprog programming mode, instead of some other mode (like Mass Storage Programmer).

And, if you really wanted to, you can turn Kit-042 into a programmer for your project (with a bunch of work porting the code).

Using the CY8CKIT-049 to Program Another PSoC® ... | Cypress Developer Community

But, Kitprog already does what you need.  Hurraaaaay!  I'm sure it must have been a satisfying feeling that something finally worked.

Hi BiBi,

Thanks! I guess that I'm able to reprogram the rest of PSoC4 yes. But still I'm not completely satisfied that standard Cypress programmer is not able to do what it is made for: programming :s

For now I can finally proceed, or better said, "start", with the rest of the project that I estimated to be "the" complicated part instead of programming the PSoC.

I already had my eyes on R10, tried to connect 4.7K myself on VTARG and XRES, this didn't work. Problaby it has something to do with the inrush current delaying the XRES voltage to be not high enough at the right moment. It's the same behavior as pressing SW1 while connecting USB, so it "sees" a logical zero.

I can confirm that PSoC Programmer v3.29 also works.

Very much thank you for your help BiBi!

0 Likes

One addition, it seems that also the Kitprog goes into CMIS-DAP mode after a few seconds, than I have to plug out my custom board again, hold SW1 for 5sec to turn it back to "working mode". Then I again have a few seconds to program......

Seems I do need a circuit in between XRES -> VDD. Problaby when powering my complete board it's too much power consumption. Maybe this will work:

circuit.png

0 Likes