PSoC 5LP debugger exits when setting Port 1 in cyfitter_cfg.c

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

cross mob
DaWe_291306
Level 1
Level 1
5 sign-ins First question asked 5 replies posted

Exasperating problem arose after a a minor code change to a running development board - every time I started the debugger it immediately exits with the message " Encountered error (Target disconnected See output window for more information.)".

I've eventually tracked the issue down to this line of code in cyfitter_cfg() in cyfitter_cfg.c (after setting the debugger to not run to main).  As soon as this code executes the debugger exits:

CYCONFIGCPY((void CYFAR *)(CYREG_PRT1_DM0), (const void CYFAR *)(BS_IOPINS0_1_VAL), 8u);

I could understand why changing the port configuration would break the debugger - what I haven't been able to locate is what values are being copied over (BS_IOPINS0_1_VAL points into flash ECC and I can't find anywhere where/how they are being set).

I've rebuilt the project multiple times, changed the debugger type from JTAG to SWD back and forth, tried a new minProg3 all to no avail.

When the issue started I had made a minor code change to the implementation code- nothing related to the system code and the fitter was not changed, so I'm at a loss why this would suddenly start.

Note the debugging option currently is set to "SWD+SWV" in the system configuration. 

Clearly the chip thinks these pins are being used for GPIO but I can't find anyway to convince it otherwise, or even the setting that changes it.

Any help appreciated.

0 Likes
1 Solution
DaWe_291306
Level 1
Level 1
5 sign-ins First question asked 5 replies posted

So, replacing the processor didn't solve the issue - it started again yesterday.  I did finally manage to isolate the issue to toggling P1[2] (I use this pin as an output in the design).  It isn't only setting the value of the drive register which triggered the issue, but even toggling the electrical value on the pin causes the debugger disconnect.

I have external reset (XRES pin) disabled in the design.

I suspect that somehow the environment is incorrectly setting the value in the NV Latch register, causing P1[2] to be setup as XRES, and toggling the pin is causing a processor reset. 

It's not clear how to read these registers during debug or how I could check them in the hex file - toggling the value results in large changes in the output HEX.

I've modified the design to avoid the use of P1[2].

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 DaWe.

I don't have a direct answer to address your observation.  But, I have a few suggestions you can try to see if it resolves the issue.

Be sure to make a backup copy of any projects before attempting these suggestions.

1) In cydwr window, select System tab and change Debug Select to GPIO.  Clean and Build the project, but DO NOT PROGRAM the 5LP target.  Now, change Debug Select back to SWD+SV, Clean and Build, program the 5LP target.  You don't want to program 5LP with Debug set to GPIO as this may brick the 5LP.  You've been WARNED!!!  (there are a number of issues when target device has SWD pins acting as GPIO, documented in Creator and PSoC Programmer release notes)

2) Change project from "Debug" to "Release".  Clean/Build.  Change back to Debug, Clean/Build/Program/Debug.

3) Create Workspace Bundle, Minimal. Copy this to a new folder and open this project.  Maybe it won't carry/copy the bad bits with it.  Clean/Build/Program/Debug.

4) Program 5LP with PSoC Programmer, not with Creator.  Click on Erase icon first.  Then program target 5LP.  Go back to Creator for debugging.

5) Uninstall PSoC Programmer, re-install.  You might even try an earlier release.

https://www.cypress.com/documentation/software-and-drivers/psoc-programmer-archive

Are you able to program/debug an earlier known working project successfully?  If a known working project can't be debugged, it suggests something else has changed in IDE environment.

I know I didn't answer your question, but maybe something here will help, or expose some other issue.

Good luck with your project.

0 Likes
DaWe_291306
Level 1
Level 1
5 sign-ins First question asked 5 replies posted

I tried the steps you outlined (except for downgrading PSoC programmer) without success.

I did discover that removing the GPS card made the problem go away (at least temporarily).  I didn't have to change the code - only remove the card.  Oddly the only pin on PORT1 that connects to the GPS card is the EN pin, which is a simple output.

When I moved the pin, I could debug.  Then I moved it back and it worked, as well.  I'm completely confused at this point.  The chip debugs properly now but seems to occasionally revert back - in that case a full rebuild makes the problem disappear.  I'm suspicious of an issue with the chip - I may replace it tomorrow.

I'm still confused how the SWD is configured on the chip - I would assume there is a TAP/SWD/JTAG configuration register somewhere but I don't see anything in the documentation.  If you setup the part for SWD I would assume setting drive mode, bypass or slew on P1.0, P1.1 and P1.3 would have no effect (debugger works fine to that point in the code and those registers are all zero).  Confusing.

I'll leave it open for now until I get a fuller resolution.

0 Likes
DaWe_291306
Level 1
Level 1
5 sign-ins First question asked 5 replies posted

I ended up replacing the processor and, for now, the problem seems to have gone away.  After spending way too much time digging through the documentation I was never able to find out which registers setup SWD debugging versus GPIO on those pins - it can't be the regular IO setup registers as these registers are reset to all zeros on startup and the debugger still works.  Same for the MLOGIC_DEBUG:dis_dbg_prt bits, which seem to be one setting for using the pins as GPIO, but setting these values does not cause the debugger disconnect.

The conclusion I came to is that there are some undocumented bits in the build that setup JTAG/SWD connections internally from the TAP to P1.0/1/3, probably in EEPROM or special flash and that rewriting these registers many times (as often happens during development) can cause that memory to fail intermittently, resulting in the disconnects.

Lesson I'm taking from this is that intermittent problem probably means a hardware issue.  Should have replaced the chip last week and saved myself a lot of time.

0 Likes
DaWe_291306
Level 1
Level 1
5 sign-ins First question asked 5 replies posted

So, replacing the processor didn't solve the issue - it started again yesterday.  I did finally manage to isolate the issue to toggling P1[2] (I use this pin as an output in the design).  It isn't only setting the value of the drive register which triggered the issue, but even toggling the electrical value on the pin causes the debugger disconnect.

I have external reset (XRES pin) disabled in the design.

I suspect that somehow the environment is incorrectly setting the value in the NV Latch register, causing P1[2] to be setup as XRES, and toggling the pin is causing a processor reset. 

It's not clear how to read these registers during debug or how I could check them in the hex file - toggling the value results in large changes in the output HEX.

I've modified the design to avoid the use of P1[2].

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

Hi @DaWe_291306

Can you please let us know if you were able to recreate this issue in another project or if the issue is project-specific?

If you are able to recreate the issue in a different project, can you please share the project so that it will help us understand the issue? 

Thanks and Regards,
Rakshith M B
0 Likes