Unable to connect to APM32E030R Micro-EVB via SWD (ST-LINK / J-LINK)

aleix

Hello,
I am currently working with the APM32E030R Micro-EVB board and I am experiencing issues connecting to the MCU for programming or debugging.
According to the board manual, the MCU should be programmable either using the onboard Geehy LINK or via an external probe through the JP1 SWD connector after disconnecting the onboard debugger.
However, I cannot establish communication with the MCU using any of the available methods.

Setup

Board: APM32E030R Micro-EVB
OS: Windows 11 Pro 64 bits
Tools tested:
STM32CubeProgrammer
SEGGER J-LINK tools
GeehyProg v1.0.6
External probes tested:
ST-LINK
SEGGER J-LINK

SWD connection test (JP1)

Configuration used:
Board powered via USB-C
H2/H3 removed (disconnecting onboard Geehy LINK)

SWD wiring:
T_VCC → VTref
GND → GND
T_SWDIO → SWDIO
T_SWCLK → SWCLK
T_NRST → NRST

Checks performed:
3.3 V present on JP1
Pin orientation verified with multimeter
Continuity between JP1 pins and signals verified
SWD frequency tested from 100 kHz to several MHz

Results:
STM32CubeProgrammer reports “No STM32 target found”
J-LINK also fails to connect

GeehyProg tests

I also attempted to connect and program the MCU using GeehyProg, but the board is not detected in any mode supported by the software:
ISP mode (UART)
DFU mode (USB)
PROG mode (burner/SWD)

The device does not appear or connect in any of these modes even though the board is powered and connected to the PC.
According to the GeehyProg manual, the software should support APM32E030 devices and allows programming through DFU, ISP, or PROG modes.

Is there any additional jumper or hardware configuration required to enable SWD programming via JP1?
Is there any boot configuration or option byte that could disable SWD access on this board?
Is the onboard Geehy LINK required for initial programming before external SWD probes can be used?
Is there a specific procedure required to enable DFU or ISP mode on the APM32E030R Micro-EVB?
Any guidance would be greatly appreciated.

Best regards,
Aleix

Geehy

aleix hi Aleix, we totally get that you’re feeling worried about what’s going on. Just give us a sec while we check things out for you.

and we’ve noticed that you’ve posted the same content multiple times. To ensure we can respond to you promptly, we’ll hide the duplicate posts and reply to you through this latest one. Please rest assured that we’ll do our best to help you resolve the issue. :)

Geehy

hi Aleix,

What you describe doesn’t look like a normal software or configuration issue at first glance.

According to Geehy’s own board manual, the external SWD via JP1 should work once the onboard Geehy-LINK is disconnected, and the board also requires the H1/VDD pins to be shorted so that the target MCU is actually powered.

The manual also notes: “For debugging, connect H2/H3 or H4/H5 to use the onboard Geehy-LINK. After disconnecting the Geehy-LINK, use a third‑party tool via JP1 for MCU programming and debugging.”

Therefore, the first thing to verify is H1 (VDD), not just H2/H3. Even if you measure 3.3 V somewhere on the board or USB power is present, the target MCU power domain might still not be correctly powered.

As for your question:

Yes, H1/VDD must be shorted to power the chip. Geehy’s manual explicitly confirms this. Once the onboard Geehy-LINK is disconnected, JP1 is indeed the intended external programming/debug path.
There are option bytes related to protection on APM32 devices, including read protection. Geehy documentation and SEGGER’s APM32 notes both indicate APM32 families have option bytes for protection, and those settings can affect debug behavior. and for your problem, this pattern is more consistent with either:

target MCU not actually powered / not reset correctly,
wrong board jumper state,
SWD lines held or loaded by remaining onboard circuitry,
physical board fault / bad MCU,
USB/driver issue only for GeehyProg, plus a separate hardware problem for SWD.

Yang Chao

Hi Aleix, to eliminate the influence of Geehy Link on the programming function of the APM32E030 Micro-EVB, we recommend using soldering equipment to temporarily remove resistors R27 and R28 located on the Geehy Link section. This will avoid SWD interface conflicts to the greatest extent, and it is much more effective and reliable than simply removing the jumpers.

Meanwhile, please verify that the APM32E030 series MCU is available for selection in your Segger J-Link software suite.

Regarding the emulators from other manufacturers that you mentioned, please note that we might not provide the exact same ARM Core ID as those manufacturers.

Regarding the Geehy Prog programming needs you mentioned, this software serves the APM32 PROG (a standalone offline programmer with internal storage) to configure firmware for offline programming.

Designed for offline programming machines, it is ideal for 1-to-1 bare-chip programming. Specifically, it checks the reset circuit, can execute chip erase first, and allows you to set read protection and a maximum limit for programming times. It does not provide power by default; power must be supplied by your production environment.

If you want to test the Geehy Link programming features, unfortunately, this CMSIS-DAP device doesn’t have a fixed PC host software. We do offer a Python-based programming tutorial on our forum. Alternatively, you can use IDEs like Keil MDK, IAR EWARM, or Eclipse for programming and simulation.

If you have any further questions, please feel free to let us know.

aleix

Hello,

I would like to provide an update on this issue.

I have managed to successfully establish communication with the APM32E030R using GDB Remote Server and OpenOCD via SWD with both Geehy Link / J-LINK. However, I am still unable to connect using GeehyProg or ST tools (STM32CubeProgrammer, ST-Link).

From my investigation, the main issues seem to be:

Geehy LINK not detecting the MCU in any of its available modes, possibly due to firmware limitations or incomplete support for this specific device.
Incompatibility of STCubeProgrammer / ST-Link tools with the APM32E030R, which prevents successful connection or recognition of the target.
Toolchain limitations or lack of proper configuration in GeehyProg and ST-Link utilities, rather than issues with the SWD physical connection itself.

The working solution was:

Launching a remote GDB Server from STM32CubeIDE
Connecting via OpenOCD with a custom configuration (cmsis-dap.cfg/jlink.cfg and apm32e1x.cfg)
SWD speed: 100 kHz)
Forcing reset halt during initialization

This setup allows stable debugging and flashing via GDB/OpenOCD.

However, GeehyProg still does not detect the device, and ST-Link tools continue to fail to connect.

As I already have successfully established connection with the APM32E030R, I no longer need technical assistance with this issue. I appreciate the responses and the guidance provided, which helped me better understand the limitations and arrive at a working solution.

Best regards,
Aleix

Geehy

aleix
Hi Aleix,

Thank you for the detailed update on your progress. It’s great to hear that you’ve successfully established communication with the APM32E030R. We really appreciate your thorough analysis and will share this update with our engineers. If you need any further assistance in the future, please don’t hesitate to reach out. We’re always happy to hear from you!