Cant upload/debug any more

Now all of a sudden I cant upload/debug my code any more.
I’m running vsCode on linux. The programmer is the recommended one from CY8CKIT-147.

When this happend, I noticed that when I plug in the programmer my file manager pops up displaying a drive with a single file. Also I notice that the openocd process complains about the programmer being out of date.
fw-loader recognizes the programmer as a KitProg2. Since I have been using the same programmer for quite a while I had expected to see it as a KitProg3. (has it downgraded it self by magic?)
Anyway, fw-loader --update-kp3 sorted that. Now I have KitProg3 CMSIS-DAP HID-121A0C3A00087400

But still, vsCode refuses to upload/debug.

To get a clean state I have done:

  • rm -r build
  • Clean Reconfigure
  • Clean Rebuild

With the amber light is fading in and out on the programmer I hit F5 to start debugging my code. This results in:
image

And the Adapter Output:

Open On-Chip Debugger 0.10.0+dev-2.2.0.249 (2019-09-10-18:37)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
kitprog3
0
0
adapter speed: 1500 kHz
Warn : Transport "swd" was already selected
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
1
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.2.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 : VTarget = 4.877 V
Info : clock speed 1000 kHz
Error: DAP 'psoc6.cpu' initialization failed (check connection, power, etc.)

This happes with two onethingx based modules, both the official development board and with my own prototype.

Have I somehow fried my programmer?

Ordered a few cy8ckit-147 boards to get a new programmer/debugger. Got them yesterday, but it didn’t help a bit. Exactly the same symptoms. Also I have reproduced this error on 3 different build environments.
So far it seems most likely that my two onethinx modules have died somehow.

Sorry for the delayed reply.

Can you set an CyDelay(2000); as first instruction at main()?

And can you toggle set ENABLE_AQUIRE 0 from 0 to 1 and vice versa in the launch.json?

It seems the module is running into a hardfault directly after startup. Reprogramming, toggle, reprogram will do the trick.

Fantastic, set ENABLE_AQUIRE 1 made me going again. Apparently the CyDelay(2000); was not needed.
I have even left the ENABLE_AQUIRE at 1 for now, everything seems to be working just fine. Will I regret this at a later state?

OK, it seems I was a little too fast here. Hardware indeed execute my code. But debugging doesn’t work yet. I turned to return ENABLE_AQUIRE to 0 , but that only bring me back to where I cant upload/debug at all.

Back to having ENABLE_AQUIREENABLE_AQUIRE set tp 1 iI notice the OUTPUT log keeps outputting lines like these:

Polling target psoc6.cpu.cm4 failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 300ms
Polling target psoc6.cpu.cm4 failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 700ms
Polling target psoc6.cpu.cm4 failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 1500ms
Polling target psoc6.cpu.cm4 failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 3100ms
Polling target psoc6.cpu.cm4 failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 6300ms
Polling target psoc6.cpu.cm4 failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 6300ms

And after a few moments the debugger indicates it is ready to run:

image

In the DEBUG CONSOLE I see

Please check OUTPUT tab (Adapter Output) for output from /home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/tools_2.0/linux/openocd/bin/openocd
Launching server: "/home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/tools_2.0/linux/openocd/bin/openocd" "-c" "gdb_port 50000" "-s" "/home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/tools_2.0/linux/openocd/scripts" "-c" "set PROGRAMMER kitprog3" "-c" "set ENABLE_ACQUIRE 1" "-c" "set ENABLE_CM0 0" "-f" "/home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/config/scripts/openocd.tcl"
Launching GDB: "arm-none-eabi-gdb" "-q" "--interpreter=mi2"
Reading symbols from /home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/build/VSCodeHelloWorld-take2.elf...
0x100033c8 in Cy_SysPm_SaveRegisters (regs=0x1f4) at /home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/psoc6pdl/drivers/source/cy_syspm.c:2845
2845	    regs->CY_SYSPM_UDB_BCTL_QCLK_EN0_REG = UDB_BCTL_QCLK_EN_0;
Not implemented stop reason (assuming exception): undefined
kitprog3: acquiring PSoC device...
SWD DPIDR 0x6ba02477
SWD DPIDR 0x6ba02477
Failed to read memory at 0x16002008
mem2array: Read @ 0x16002004, w=4, cnt=1, failed
** psoc6.cpu.cm4: Ran after reset and before halt...
target halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x100033c6 msp: 0x0803ef48
Output radix now set to decimal 16, hex 10, octal 20.
target halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x100035ba msp: 0x0803eea8
psoc6.cpu.cm4: bkpt @0x100010BD, issuing SYSRESETREQ
psoc6.cpu.cm4: external reset detected
target halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x100010bc msp: 0x0803f000
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main () at /home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/source/main.c:39
39	{

Program
 stopped.
main () at /home/mogul/Onethings_vsCode/VSCodeHelloWorld-take2/source/main.c:39
39	{

Any suggestions to where to look next? What to try?

Did you use the CyDelay(2000);?

I suggest to keep the delay in place while debugging. It might that the device turns into an hardfault and therefor looses track on the CPU.

If the CPU goes into an hardfault while acquiring, problems may be twofold either with debugging as with programming. The CyDelay(2000); gives the debug adapter time to acquire before running into the hardfault.

Well, I have made some progress. I suspect something in the generated hardware configuration was damaged. I opened the hardware configuration, simply saved and then made a clean rebuild. And now everything is working for me again.

I dont feel I fully understand what happened and kinda expect it to go funky with me again in the future. But now I at least have one more thing to try and look out for when it happens.

And yes, I have tried both with and without the delay as the first line of code.

Solving the issue by using the ‘clean configure / rebuild’ action turns me into thinking that you’re able to program and debug the device while having build errors. This means you’re debugging and old .elf file with different (newer) code which causes the debugger to fail code lookup.

Which VS Code setup do you use? We’ve mitigated this and other issues in the latest VSCode_HelloWorld.

If you use the all-in-one package, I suggest to migrate to this latest version (separate dependencies pack) using this guide.

I tried to clean it many times before I got to the idea of saving, and by that regenerating, the hardware configuration.

  • Clean Reconfigure
  • Clean Rebuild
  • rm -rf build

There’s another issue with the older (modustoolbox 1.1) configuration. Enabling the System Power setting causes the configuration code to read data from SFlash which is protected by our stack. This results in an hardfault while programming which leads to debug issues (can not program or debug).

I think I have narrowed this one down to “if I put the device into sleep mode then next development cycle have a hard time reprogramming/debugging”. I guess this makes sense since SWD probably get disabled when device is asleep.

If you (@Rolf) agree on this observation, perhaps a note along the documentation for LoRaWAN_Sleep could help the next guy hitting this.

Hmm, the weekend ended with a situation where one of my modules is again stuck in a situation where I cannot get it going not matter what I do. I believe I have tried every trick in the thread here:

  • plain programmers and the voltage modded one
  • both the mixed stack and the newer one where core and application are in separate repos
  • both my own application and a fresh helloworld example
  • CyDelay(2000); and set ENABLE_AQUIRE 1
  • Clean Reconfigure
  • Clean Rebuild
  • rm -rf build

I wonder, if is possible to brick the module somehow? To program some odd configuration which will make it impossible to recover from.

It can be hard to get a module recovered, however I always succeeded. The CyDelay will give the debugger some time to acquire the ARM core before going into a fault state. The set ENABLE_AQUIRE should be toggled a few times (from 1 to 0 to 1 etc) for programming / debugging. Sometimes multiple iterations are needed. Are you sure the code builds well and can you share the debug-adapter output?

Ok. I have been back and forth between ENABLE_AQUIRE 0 and 1 more than 10 times now.

The test program is your helloworld code with a blinky loop right after __enable_irq();. Of course with CyDelay(2000); as first statement in main()

while(1){
	LED_B_SET(LED_ON);	
	LED_R_SET(LED_OFF);	
	CyDelay(200);
	LED_B_SET(LED_OFF);	
	LED_R_SET(LED_ON);	
	CyDelay(200);
}

It compiles fine, and blinks nicely on the other module.

When trying on the problem board this is the debug adapter output:

Open On-Chip Debugger 0.10.0+dev-2.2.0.249 (2019-09-10-18:37)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
kitprog3
1
0
adapter speed: 1500 kHz
Warn : Transport "swd" was already selected
adapter speed: 1000 kHz
** Auto-acquire enabled, use "set ENABLE_ACQUIRE 0" to disable
cortex_m reset_config sysresetreq
1
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.2.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: powering up target device using KitProg3 (VTarg = 3300 mV)
Error: kitprog3: power_control command failed (target already powered?)
Warn : Target voltage (3.946 V) is not within 5% of requested 3.300 V
Info : VTarget = 3.946 V
Info : kitprog3: acquiring PSoC device...
Info : clock speed 1000 kHz
Info : Power dropout detected, running power_dropout proc.
Sensed power dropout.
Info : SWD DPIDR 0x6ba02477
Error: DAP 'psoc6.cpu' initialization failed (check connection, power, etc.)

There’s a power dropout initially. Maybe try with the non modified programmer or use 1N400x diodes?

I have tried:

  • Both programmers
  • Both modules

I see the power dropout on all 4 combinations.

I have tried to feed the problematic module a stable 3.3V.

As I understand it, it is openocd that does the actual communication with the programmer. Do you know alternatives to this tool. Might be something out there better at performing the needed reset procedure?
openocd can do many things. All we need is a flash-tool. Of course it should keep it’s tentacles away from the protected parts of the module…

It’s hard to tell the problem. If you tried all options, you’re probably out of luck and the module may be damaged.

Can you diode / resistance test on the XRES / SWDCLK / SWDIO pins and compare between the working and the non working module?

Do you have the jumpers set correctly?

I don’t know if I have tried all options. I believe I have tried everything you have suggested.

Measuring between GND and XRES / SWDCLK / SWDIO on both modules yield similar results.

The faulty module isn’t on your development board but on my own prototype board. Not many jumpers there.

Connections are inspected and verified: visual, mechanical and electrical.

What bugs me is that I’m quite confident the module died as a result of a piece of code being uploaded. Code or configuration, but at least from the software domain.
I know I have programmed it at least 20 times with the modded programmer before this happened. And ad you can see the module get it’s power from a 3V lithium cell.

If I cant get to a point there it can be explained what happened it will be hard to work with the module. Of course it can just have randomly died on my workbench here, but that would be considered a rare case.

I need to understand or it will happen again.

Itt’s really hard to get a grip on what happend. Timing for programming is critical, especially if there’s something wrong in code. The ‘acquire window’ will be very short if the MCU directly runs into a fault state. Also if SWDIO and SWDCLK traces are running next to each other closely, crosstalk can happen on these lines resulting in problems as well.

For the developing stage, I suggest to maintain the CyDelay(1500); as first instruction at main in order to prevent such cases.

Hope this helps!