The target device needs to be acquired for the programmer to program the device.
Can you please provide more details regarding your hardware setup so that I can reproduce the issue? The DAP Acquire step generally takes so much time when one of the programming parameters are set incorrectly. Can you please provide the list of commands that you used before the acquire step?
Did you try programming the device using the RESET mode? Did it make any difference?
Rakshith M B
Sorry, I need to give more detailed I will get as detailed as I feel is pertinent, but feel free to request more detail.
First, we are using the cy8c4014LQI-421. As I understand, that chip requires the power cycle method of programming, doesn't it?
We have a board that we are using the Capsense function, in fact the IO pins are used exclusively for Capsense and an I2C lines that connected to another board through a connector. We also have a couple pins that are unconnected. There is also an interrupt line that goes from this board to the other board to let the other board know when a Capsense event has occurred.
It occurred to me that you might be asking for the physical programming connections to the device under test. During programming we remove the I2C to the other board and use I2C to program the device. Is that what you are looking for? Let me know if I need more detail.
As far as the programming set up, we use the example in %&PROGRAM FiLES%\Cypress\Programmer\Examples\Programming\PSoC4\SWD\Cpp_Ex. The only thing I really did in relation to the code was:
- I added a way for it to turn off the power to the chip after programming
- Added a way for the CLI to select a specific programmer ;
- Made 2 separate versions, one for 10 pin and one for 5 pin.
- Added a way to select the hex file from the command line.
- Changed the acquire mode to power cycle.
The problem we are having is most of the time the power cycle of programming works fine, but on occasion it will power cycle again and again. It will then pause and power cycle again and again. Since it is black box starting from the Invoke command into the COM object, I can't see why it is repeating again and again. (Please pardon my ignorance of COM objects, I haven't dealt much with them at all.) It makes finding a solution troublesome.
So that is where we are. Like I say, if I am missing detail or confusing things, let me know.
Cypress told me PSoC 4000 family could be programmed using SWD by default. No mention of using I2C as an alternative method.
Bootloader from factory in PSoC 4000, 4200? Are you using an I2C Bootloader?
I follow this method for power-cycle programming using SWD interface using Kitprog (from KIT-059) for 4013, 4014:
To get power-cycle programming method (Kitprog or Miniprog3) to work reliably is to use short length SWD (and in your case I2C) cables. I've never had an issue with 5cm length cables and SWD runs faster than I2C. When I had similar issues as you (constant power cycling to acquire), it was because my cables were over 10cm length. After I shortened them, never an issue again. I use both PSoC Programmer and the programmer inside Creator.
With I2C, the pcb needs to provide termination pull-up resistors. Are these resistors still connected to 4014 when you disconnect the I2C port for programming purposes? Maybe they become disconnected when pcb is configured for programming.
You mentioned Miniprog3, so that should provide proper power cycle timing. But, can it provide enough current to support the rest of the circuitry connected to 4014? I suspect it can, but you should check this.
As for schematic, many designers have connected Vccd incorrectly. For 5V/3.3V design, it should not be connected to any other rail and should have its own 0.1uF capacitor. For 1.8V designs, then you have the option to connect Vccd to Vddd and disable the internal regulator via s/w.
Maybe you already checked all the above. I can't think of other stuff to check.
Good luck with your project.