Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

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

cross mob
GuGa_1322886
Level 4
Level 4
5 solutions authored 25 sign-ins First comment on KBA

HI,

I have a project created for a custom board based on PSOC62 with its corresponding Custom BSP. All seems to be correct on the firmware side. The project compiles and programs without errors, but I can't debug because I get a constant string of warnings and errors when the debugger should start and hit the main() breakpoint.

I also tried programming the part with the standalone Moudus Toolbox programmer and MiniProg4. I can erase, program, and verify OK the part, but also with the standalone programmer I get the same enless stream of errors after programming.

Here is the output in MTB 2.41 when I try to debug. Everything seems to be normal until the first "Warn : Connecting DP: stalled AP operation, issuing ABORT":

Started by GNU MCU Eclipse
Open On-Chip Debugger 0.11.0+dev-4.3.0.1746 (2021-09-16-07:59)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter srst delay: 25
adapter srst pulse_width: 25
** Auto-acquire enabled, use "set ENABLE_ACQUIRE 0" to disable
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Warn : SFlash programming allowed for regions: USER, TOC, KEY
Info : Using CMSIS-DAPv2 interface with VID:PID=0x04b4:0xf151, serial=041410D101310400
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: JTAG supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : KitProg3: FW version: 2.50.1401
Info : KitProg3: Pipelined transfers enabled
Info : VTarget = 3.303 V
Info : kitprog3: acquiring the device (mode: reset)...
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x6ba02477
Info : psoc6.cpu.cm0: hardware has 4 breakpoints, 2 watchpoints
***************************************
** Silicon: 0xE206, Family: 0x100, Rev.: 0x24 (B3)
** Detected Device: CY8C6247BZI-D54
** Detected Main Flash size, kb: 1024
** Flash Boot version: 1.20.1.45
** Chip Protection: NORMAL
***************************************
Info : psoc6.cpu.cm4: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for psoc6.cpu.cm0 on 3332
Info : Listening on port 3332 for gdb connections
Info : starting gdb server for psoc6.cpu.cm4 on 3333
Info : Listening on port 3333 for gdb connections
Info : SWD DPIDR 0x6ba02477
Info : kitprog3: acquiring the device (mode: reset)...
psoc6.cpu.cm0 halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001f34 msp: 0x080477a8
** Device acquired successfully
** psoc6.cpu.cm4: Ran after reset and before halt...
psoc6.cpu.cm4 halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x1600400c msp: 00000000
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Info : New GDB Connection: 1, Target psoc6.cpu.cm4, state: halted
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
semihosting is enabled
Warn : No RTOS could be auto-detected!
Warn : No RTOS could be auto-detected!
Info : All data matches, Flash programming skipped
Info : SWD DPIDR 0x6ba02477
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error executing event reset-deassert-post on target psoc6.cpu.cm0:
.../ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg:115: Error:
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 788
in procedure 'mxs40_reset_deassert_post' called at file "C:/Users/Guillermo/ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/psoc6_common.cfg", line 134
at file "../ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg", line 115
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error executing event reset-deassert-post on target psoc6.cpu.cm4:
.../ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg:115: Error:
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 788
in procedure 'mxs40_reset_deassert_post' called at file "C:/Users/Guillermo/ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/psoc6_common.cfg", line 169
at file ".../ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg", line 115
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Polling target psoc6.cpu.cm0 failed, trying to reexamine
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Examination failed, GDB will be halted. Polling again in 100ms
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Polling target psoc6.cpu.cm4 failed, trying to reexamine
Info : SWD DPIDR 0x6ba02477
Warn : Connecting DP: stalled AP operation, issuing ABORT
Examination failed, GDB will be halted. Polling again in 100ms
Info : SWD DPIDR 0x6ba02477

... more of the same

0 Likes
1 Solution

Hi Ekta,

Thanks for the tips, the good news is that last night I found what seems to be the root of the problem, which I will explain below, but first I will answer quickly to your points:

1. I compared the screenshot in your answer with the settings in my project. There are no differences in the files to run but there are additional commands in Pre-run/Restart reset:
mon psoc6 reset_halt sysresetreq
flushregs
mon gdb_sync
stepi

However, I didn't change anything there.

2. check, no diference

3. check, that's the first thing I looked at.

4. At first I thought that the problem was at start debug section, but in fact I now see that the problem was a general device communication because the log reports erase and program OK while indeed it did not completted any of that at all for CM4.

5. The part number in this project is CY8C6247BZI-D54, and this seems to be the culprit of the problem.

BACKGROND

The custom BSP in this project reproduced all the settings of a previous BSP used in a last year's project with an apparently slightly differnt part CY8C6247BZI-AUD54, which seems to be now discontinued by Infineon...?

In this project, for what it respects to PSOC6 I have the same design as last year's board with the addition of  5 additional GPIO lines to control peripherals, and the new part number. So, I have to reproduce the BSP for this part copying all the settings from the old one.

One more thing, these boards have some timeing crytical functions, so, I use an external oscilator of 33.333 MHz with 50ppm accuracy for EXTCLK through P0.5 pin as clock source for onboard peripherals throuhg PATH_MUX0, instead of IMO.  This setup worked reliably in last year's project with CY8C6247BZI-AUD54 over weeks of programming and debugging. It is well within the specified clock range in the application note and the part datasheet:  "In PSoC™ 6 MCU, a 0–100 MHz-range clock can be connected to an EXT_CLK pin (P0[0] or P0[5])"

 

GuGa_1322886_0-1697743232511.png

 

THE PROBLEM TURNS OUT TO BE EXTCLK
Afte confirming that two out of 5 boards that came out of manufacturing behave exactly the same, I discarded the idea of a bad part for now. Long story short, after comparing system clock settings with the prototyping kit BSPs, changed the source clock of PAHT_MUX0 to IMO everything started to work. Back to EXTCLK the problem shows again. Also checked that P0.5 has the correct Digital High Z with buffer on.

The oscilator part number and PCB layout is exactly the same in both designs.

Conclusion, it seems something is wrong with this PSOC6 part number.

Now I'm stuck with 5 boards that costed a lot of money to  manufacture and can't have a high accuray clock source!

EDIT

I HAVE TO TAKE MY WORDS BACK.

It turns out that there is nothing wrong with the PSOC6 part. While trying to compare clock frequencies with the scope between old and new boards I just discovered that the crystal oscilator in the new part was assembled rotated 180 degress in the wrong position!, I have to send back these boards for remanufacturing.

GuGa_1322886_0-1697819059644.png

 

View solution in original post

0 Likes
4 Replies
Panometric
Level 5
Level 5
10 likes received 100 sign-ins 100 replies posted

Guessing, but it's failing the second reset cycle (Warn : Connecting DP: stalled AP operation, issuing ABORT
Error executing event reset-deassert-post on target psoc6.cpu.cm0:
.../ModusToolbox/tools_2.4/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg:115: Error:) 
Is there perhaps something on your board hardwired to XRES?

0 Likes

Hi, thanks for your comments. Yes, I noticed that everything start to go weird after that failed line. Before that (not shown in the snippet that I posted) the programming section reports part erasing and programming OK, but it did not act as it should with several lines of % progress in each section.

The circuit to the XRES is exactly the same as in the  prototyping boards, an RC for normal reset, and a line to the programming connector, which is a footprint on the PCB for a Tag-Connect cable.

Last night I found the root of the problem in the System Clocks configuration. I'll explain the details next in my answer to Ekta.

0 Likes
Ekta_N
Moderator
Moderator
Moderator
750 replies posted First like given 250 solutions authored

Hi @GuGa_1322886 

There are a few things you can look into:

1. I found a threads in which a user faced a similar error: https://community.infineon.com/t5/PSoC-6/Error-Debugging-PSOC6-CY8C6116BZI-F54/td-p/286354
The issue was resolved by restoring the default configuration in the Run Configuration dialog box (under the startup tab).

Ekta_0-1697694872308.png

2. In the run configuration settings only under the main tab, ensure that the Build configuration option is set to Select Automatically.

3. In the device Configurator, under the system tab ensure that the debug is enabled with configurations made correctly.

4. Are you facing any issues when trying to attach to the running target or is it an issue only with debugging?

5. Could you mention the exact MPN you are using? What is the size of the flash for the device being used?

Best Regards
Ekta

 

0 Likes

Hi Ekta,

Thanks for the tips, the good news is that last night I found what seems to be the root of the problem, which I will explain below, but first I will answer quickly to your points:

1. I compared the screenshot in your answer with the settings in my project. There are no differences in the files to run but there are additional commands in Pre-run/Restart reset:
mon psoc6 reset_halt sysresetreq
flushregs
mon gdb_sync
stepi

However, I didn't change anything there.

2. check, no diference

3. check, that's the first thing I looked at.

4. At first I thought that the problem was at start debug section, but in fact I now see that the problem was a general device communication because the log reports erase and program OK while indeed it did not completted any of that at all for CM4.

5. The part number in this project is CY8C6247BZI-D54, and this seems to be the culprit of the problem.

BACKGROND

The custom BSP in this project reproduced all the settings of a previous BSP used in a last year's project with an apparently slightly differnt part CY8C6247BZI-AUD54, which seems to be now discontinued by Infineon...?

In this project, for what it respects to PSOC6 I have the same design as last year's board with the addition of  5 additional GPIO lines to control peripherals, and the new part number. So, I have to reproduce the BSP for this part copying all the settings from the old one.

One more thing, these boards have some timeing crytical functions, so, I use an external oscilator of 33.333 MHz with 50ppm accuracy for EXTCLK through P0.5 pin as clock source for onboard peripherals throuhg PATH_MUX0, instead of IMO.  This setup worked reliably in last year's project with CY8C6247BZI-AUD54 over weeks of programming and debugging. It is well within the specified clock range in the application note and the part datasheet:  "In PSoC™ 6 MCU, a 0–100 MHz-range clock can be connected to an EXT_CLK pin (P0[0] or P0[5])"

 

GuGa_1322886_0-1697743232511.png

 

THE PROBLEM TURNS OUT TO BE EXTCLK
Afte confirming that two out of 5 boards that came out of manufacturing behave exactly the same, I discarded the idea of a bad part for now. Long story short, after comparing system clock settings with the prototyping kit BSPs, changed the source clock of PAHT_MUX0 to IMO everything started to work. Back to EXTCLK the problem shows again. Also checked that P0.5 has the correct Digital High Z with buffer on.

The oscilator part number and PCB layout is exactly the same in both designs.

Conclusion, it seems something is wrong with this PSOC6 part number.

Now I'm stuck with 5 boards that costed a lot of money to  manufacture and can't have a high accuray clock source!

EDIT

I HAVE TO TAKE MY WORDS BACK.

It turns out that there is nothing wrong with the PSOC6 part. While trying to compare clock frequencies with the scope between old and new boards I just discovered that the crystal oscilator in the new part was assembled rotated 180 degress in the wrong position!, I have to send back these boards for remanufacturing.

GuGa_1322886_0-1697819059644.png

 

0 Likes