Example code compiles and flashes but causes microcontroller resets?

[MerrimanInd]

I'm trying to run the Rust GPIO example on the T2G Body Entry Starter Kit. I seem to have the toolchain set up correctly, the code compiles, and it seems to flash but immediately halts on the microcontroller.

I'm using the ARM GNU toolchain v13, the attached OpenOCD, etc. One issue I had was with the version of KitProg3. I updated the firmware on the PSoC chip and am now running v2.40, which I don't believe is what came on the eval board but it seems to be working.

@shahzeb I didn't want to clutter up the comments on your Getting Started w/ Rust post, hope you can help here instead!

Here's my terminal output when I run the openocd Debug M0 Master

Open On-Chip Debugger 0.10.0+dev-1.1.0.901 (2020-06-09-06:04) 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 '. adapter speed: 2000 kHz adapter srst delay: 25 adapter srst pulse_width: 5 ** Auto-acquire enabled, use "set ENABLE_ACQUIRE 0" to disable cortex_m reset_config sysresetreq adapter srst delay: 100 Info : Listening on port 50002 for tcl connections Info : Listening on port 50004 for telnet connections Info : CMSIS-DAP: SWD 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.40.1241 Info : KitProg3: Pipelined transfers enabled Info : VTarget = 4.816 V Info : kitprog3: acquiring the device... Info : clock speed 2000 kHz Info : SWD DPIDR 0x6ba02477 Info : traveo2.cpu.cm0: hardware has 4 breakpoints, 2 watchpoints Info : traveo2.cpu.cm0: external reset detected

---

Use overriden Main Flash size, kb: 1088 Use overriden Work Flash size, kb: 96 Silicon: 0xE3DA, Family: 0x101, Rev.: 0x23 (B2) Detected Device: CYT2B75CAE Flash Boot version: 3.1.0.515 SFlash version: 318083 ** Chip Protection: NORMAL

---

Info : traveo2.cpu.cm4: hardware has 6 breakpoints, 4 watchpoints Info : traveo2.cpu.cm4: external reset detected Info : Listening on port 50000 for gdb connections Info : Listening on port 50001 for gdb connections Info : accepting 'gdb' connection on tcp/50000 target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000 Info : New GDB Connection: 1, Target traveo2.cpu.cm0, state: halted semihosting is enabled Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000, semihosting Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800 Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000, semihosting Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800 [100%] [################################] [ Erasing ] Info : Padding image section 0 at 0x10001558 with 8 bytes Info : Padding image section 1 at 0x10001688 with 376 bytes (bank write end alignment) [100%] [################################] [ Programming ] Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000, semihosting Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800 Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000, semihosting Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800 [100%] [################################] [ Erasing ] Info : Padding image section 0 at 0x10008c48 with 8 bytes Info : Padding image section 1 at 0x10008e74 with 396 bytes (bank write end alignment) [100%] [################################] [ Programming ] Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000, semihosting Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800 Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x000002a4 msp: 0x08020000, semihosting Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800 Info : accepting 'gdb' connection on tcp/50001 Info : New GDB Connection: 2, Target traveo2.cpu.cm4, state: halted semihosting is enabled Info : SWD DPIDR 0x6ba02477 Info : kitprog3: acquiring the device... Device acquired successfully traveo2.cpu.cm4: Ran after reset and before halt... target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001bc msp: 0x0801f800, semihosting

And over in the debug console there's quite a bit of printout but this seems like a possibly relevant section:

Program -> ~" received signal SIGINT, Interrupt.\n" received signal SIGINT, Interrupt. -> ~"0x000002a4 in ?? ()\n" 0x000002a4 in ?? () -> *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x000002a4",func="??",args=[],arch="armv7e-m"},thread-id="1",stopped-threads="all" mi2.status = stopped 32-break-delete -> 32^done 33-target-disconnect -> =thread-exited,id="1",group-id="i1" -> =thread-group-exited,id="i1" -> 33^done

[marcomas2000]

It seems that I have a very similar problem. Identical setup, very similar output, probably identical. The output of the Debug Console reports

Launching gdb-server: ./traveo_debug/CypressAutoFlashUtility/bin/openocd.exe -c "gdb_port 50000" -c "tcl_port 50002" -c "telnet_port 50004" -s ./traveo_debug/CypressAutoFlashUtility/scripts -f "c:/Users/.../.vscode/extensions/marus25.cortex-debug-1.12.1/support/openocd-helpers.tcl" -f interface/kitprog3.cfg -f target/traveo2_1m_a0.cfg Please check TERMINAL tab (gdb-server) for output from ./traveo_debug/CypressAutoFlashUtility/bin/openocd.exe Finished reading symbols from objdump: Time: 27 ms Finished reading symbols from nm: Time: 27 ms Official(ToolchainDesc { channel: "stable", date: None, target: TargetTriple("x86_64-pc-windows-gnu") }) [Official(ToolchainDesc { channel: "stable", date: None, target: TargetTriple("x86_64-pc-windows-gnu") }), Official(ToolchainDesc { channel: "stable", date: None, target: TargetTriple("x86_64-pc-windows-msvc") }), Official(ToolchainDesc { channel: "nightly", date: None, target: TargetTriple("x86_64-pc-windows-msvc") })] 'arm-none-eabi-gdb-py.exe' is not recognized as an internal or external command, operable program or batch file. Error: Unable to start GDB even after 5 seconds or it couldn't even start Make sure you can start gdb from the command-line and run any command like "echo hello". If you cannot, it is most likely because "libncurses" or "python" is not installed. Some GDBs require these GDB session ended unexpectedly. exit-code: 1 GDB could not start as expected. Bad installation or version mismatch. See if you can start gdb from a shell prompt and check its version (Must be >= 9)

I have what seems to be a clean setup, and everything else seems to work, but the command indicated in bold is nowhere to be seen.

The call to arm-none-eabi-gdb-py.exe command comes from the batch file rust-gdb.bat, but I don't understand which package is supposed to provide it. My only guess at this point is that something might be missing from the arm toolchain.

[christianheussy]

@marcomas2000 arm-none-eabi-gdb-py is part of the arm toolchain which you can download here. It looks like the latest release (13.2.rel_1) doesn't include it for some reason. You may need an older version of the toolchain.

[marcomas2000]

@marcomas2000 arm-none-eabi-gdb-py is part of the arm toolchain which you can download here. It looks like the latest release (13.2.rel_1) doesn't include it for some reason. You may need an older version of the toolchain.

@christianheussy Thank you for your quick reply. I imagined it after posting, because I remembered that the link on the setup page redirects to a page on the ARM website that labels that version as kind of unsupported. I know that it's a minor issue, but since this is apparently the only very detailed example for working with Rust on a relatively cheap board for hobbyists, I believe that we could try to eliminate the dependency from Python 2.7, if possible at all.

[MerrimanInd]

@marcomas2000 I believe you can change the rust-gdb.bat file to point to the non Python version of GDB but you lose some printing features. But this is far from the only detailed example for Rust on a cheap board. Rust's own embedded book supports the Microbit and STM32 Discovery board.

If you want to discuss further please create a new issue or a discussion as the bug in my code is still active and I want to keep this thread open for that.

[marcomas2000]

@MerrimanInd I have the same problem now, so this issue needs some clarification. I know about the support for other boards, of course, I just found this example to be (potentially) the best ''Getting Started'', especially because it comes with some support from the hardware manufacturer.

[schaazzz]

@MerrimanInd I have the same problem now, so this issue needs some clarification. I know about the support for other boards, of course, I just found this example to be (potentially) the best ''Getting Started'', especially because it comes with some support from the hardware manufacturer.

@MerrimanInd @marcomas2000 Sorry for taking so long to get back to you on this topic but we've been busy working on an svd2rust alternative called svd2pac and I've just started looking into this issue.

My initial guess is that this is due to an incompatibility between the newer version of KitProg that @MerrimanInd is using and the older version of OpenOCD included with the code example. I have a baremetal example that works with the latest versions but I need to test it a bit more and check if the GDB debug configuration works as expected. Will try to get it done by next week.

[MerrimanInd]

@schaazzz thanks, appreciate the attention! I've also been distracted with other projects but finally looking back into this. I've actually had a few different versions of KitProg on the PSoC on the board. I accidentally flashed it and haven't been able to determine what it shipped with so I've tried a few versions. If you're aware of a specific version that would be compatible with this modified version of OpenOCD I can test with that.

Recently I attempted to flash my board with IAR EWARM and I wasn't able to get the debugger working there either, even though it's recognized correctly in Device Manager. Hope I didn't brick it.

It would be great to move to the upstream version of OpenOCD since that seems to be the only part of the toolchain that's specifically Windows-only. Not sure what changes were made between the Infineon version and the main version or if that's feasible/reasonable at all.

[MerrimanInd]

Hey any updates on the OpenOCD/Cypress Auto Flash Utility incompatibility?