PSoC 5LP does not come out of reset after reprogram

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

cross mob
ArvidVitroflow
Level 1
Level 1
First solution authored First reply posted First question asked

I've built a bit-banging SWD programmer for performing OtA firmware updates of our product.
This programming is performed by a separate MCU connected to the PSoC.

I've been working off this https://www.cypress.com/file/119651/download document.

I've gotten everything working and I can correctly program all the PSoCs memories,
but the PSoC won't boot and function normally after the final reset.
However, if I power-cycle the system, the PSoC boots and behaves normally.

I know I am actually programming it, because it has a firmware version number that it sends over SPI to another MCU
and this does change when I program different firmware versions.
It also sends other data, which is how I know if it is working.

If I use the MiniProg 3 to program, the PSoC boots as it should.
Both the MiniProg and the bitbanger use the dedicated XRES pin on the TQFP package.
The difference is that the MiniProg plugs into a header routed to the combined JTAG/SWD interface,
while the MCU is routed to the SWD/USB pins. These pins are only used for programming, they're not used as USB or GPIO.

I have a breakout with all the relevant signals and I've scoped these
to compare my implementation with what the MiniProg does.
The MiniProg actually does things a bit different from what the official app note says,
but there's nothing special about the final reset.
It just holds down the reset for about 20ms, the release it and the PSoC boots and starts sending SPI data.

Since I've confirmed that I correctly program all the memories,
I find it really surprising that the PSoC won't just come out of reset and start working.
There shouldn't be any difference between using XRES and the PSoC doing a POR.

Thank you in advance!

0 Likes
1 Solution
ArvidVitroflow
Level 1
Level 1
First solution authored First reply posted First question asked

I solved it!

The official documentation is incorrect.

On p49 of the pdf I linked above, there's an instruction to do the following:

APACC ADDR Write [0xE000 EDF0]
APACC DATA Write [0xA05F 0001] //Activate Debug

The Miniprog also sets the C_HALT bit, i.e. it writes:

APACC DATA Write [0xA05F 0003]

But I don't think this was the real problem.
The issue was probably that it omits a crucial step:

APACC ADDR Write [0x4000 46E8]
APACC DATA Write [0x0000 0040]

According to https://www.cypress.com/file/136211/download p273
MLOGIC Debug Register
Bits Name Description
6 allow_rst_hrd Allows XRES to generate a hard reset during JTAG and SWD mode. This bit should not be set
at the same time as dis_dbg_prt. Both bits set together will not allow the debug port to be re-
claimed without a port acquire

So yeah. Marking as solved.
Is there a way of notifying Cypress/Infineon of this, so they can fix the docs?

View solution in original post

0 Likes
5 Replies
BiBi_1928986
Level 7
Level 7
First comment on blog 500 replies posted 250 replies posted

Hello.

After programming, verify SWDIO is held at logic 0 during/after XRES is active.  If SWDIO is held at logic 1, PSoC could re-enter programming mode (if SWDCK gets clocked).

You could also review this PSoC4 SWD bit-banger project.  It might shed some light.
Using the CY8CKIT-049 to Program Another PSoC® 4 - KBA93541
Using the CY8CKIT-049 to Program Another PSoC® 4 -... - Cypress Developer Community
The source code is available.

Otherwise, try to replicate Miniprog reset cycle at end of programming.
Is it possible, Miniprog is executing a Power Cycle reset at end of programming?  I wouldn't think so, but then again, it doesn't follow the spec's either.

Also, 5LP has 2 SWD ports.  Make sure the 'other' SWDIO is also held at logic 0.

BTW, SWD wire connections should not exceed 5-10cm in length.  Signal integrity is the issue.

Good luck with your project.

0 Likes
ArvidVitroflow
Level 1
Level 1
First solution authored First reply posted First question asked

@BiBi_1928986 
I have verified that SWDIO is held low during the last reset.
The clock isn't run after the final SWD packet, so it should not matter, but I've checked it anyway.

Also, as a test I tried running the clock during reset. I ran the clock for 7ms after the last packet, then for 25ms with reset low, then a last 8ms with reset high. All this with SWDIO low, of course.
This is exactly what the MiniProg does. No difference.

I am positive the MiniProg is not doing power cycle.
- It's set to Programming Mode: Reset in PSoC Programmer.
- The oscilloscope says 3v3 stays at a good level during the entire procedure.
- The board isn't designed to have 3v3 pulled low through the programming header and would probably break.

The bitbanging MCU doesn't have access to the main programming port,
which is routed to the external programming header. It only has access to the alternate USB/SWD port.
During MCU bitbang programming, the main SWD port will float.

I don't see how signal integrity could be a factor.
The bitbanging MCU only has a few cm of copper traces and a bit of ribbon cable between it and the PSoC.
Either way, the programming works fine, it's the coming out of reset afterwards that is the problem.

Thank you for the link to the PSoC 4 project, I will study it and compare.

Best Regards!

0 Likes

Hello.

Sounds like you're doing everything correctly.  With both Miniprog and MCU using dedicated XRES pin, there should be no difference.  This is a head scratcher.

I found another bit-banger SWD that might be easier to read.
GitHub - tmanaud/psoc-flash: PSOC flash SWD (HSSP) programming from linux with GPIO

I looked through it and couldn't find anything different from your implementation (aside from possible timing delays).

IIRC, there was a Cypress Community thread on this topic in the past.  I wish the search engine worked better.

As a test, can you issue the XRES reset cycle twice, maybe with 100ms delay between cycles.

0 Likes

I just tried doing the extra reset. No dice, I'm afraid.

It looks like the linux GPIO programmer you linked uses the same base code as the cypress one,
just adapted to compile as a linux executable.
I'm gonna see if I can get that project running. If I can get it to use an FTDI USB-to-UART as GPIO,
I'll have another point of comparison. Otherwise, I think I have an RPi lying around.

0 Likes
ArvidVitroflow
Level 1
Level 1
First solution authored First reply posted First question asked

I solved it!

The official documentation is incorrect.

On p49 of the pdf I linked above, there's an instruction to do the following:

APACC ADDR Write [0xE000 EDF0]
APACC DATA Write [0xA05F 0001] //Activate Debug

The Miniprog also sets the C_HALT bit, i.e. it writes:

APACC DATA Write [0xA05F 0003]

But I don't think this was the real problem.
The issue was probably that it omits a crucial step:

APACC ADDR Write [0x4000 46E8]
APACC DATA Write [0x0000 0040]

According to https://www.cypress.com/file/136211/download p273
MLOGIC Debug Register
Bits Name Description
6 allow_rst_hrd Allows XRES to generate a hard reset during JTAG and SWD mode. This bit should not be set
at the same time as dis_dbg_prt. Both bits set together will not allow the debug port to be re-
claimed without a port acquire

So yeah. Marking as solved.
Is there a way of notifying Cypress/Infineon of this, so they can fix the docs?

0 Likes