I've been tinkering around with this Generalplus microcontroller: GPM32F0118B and there are datasheets/some materials here: https://www.generalplus.com/GPM32F0118B-MkCri-1LVBMBILN4897SVpnSNproduct_detail.

In my application there is a UART to the MCU and I'm curious to try to talk to it. Based on what I saw in the datasheet, the MCU has in system programming functionality and if it is powered up in a "special 'SWD mode'" then you can communicate to it via the serial port.

It doesn't look like there are any boot pins, rather there are registers to control the boot behavior. It's a bit vague but it sounds like if I can get it to boot from the system memory, then I may be able to talk to it via the UART. It's not really clear to me how someone would be able to change the boot behavior. The UART port is exposed so I'm assuming that's how the MCU was programmed while installed on the board but I didn't see any activity on a terminal when I tried connecting to the RX/TX pins & GND via a USB to serial FTDI chip. I also tried looking at the TX pin with an oscilloscope on power up/power down of the system, but I didn't see anything substantial. The TX line pulsed high momentarily and then when back to an idle state.

My main curiosity is if other people have encountered something similar on other MCU's? I found info online mainly about the STM32, which looks like it has physical pins to control the boot behavior. I found this thread: https://community.st.com/t5/stm32-mcus-embedded-software/official-stm32-bootloader/td-p/591959 which looks like it describes some commands that can be sent via serial. From what I could tell the STM32 and this GPM32 share a similar architecture, so perhaps there is a similar functionality on this IC. It seems like this would be specific to the GPM32 and unfortunately I don't see any mention of such commands in their documentation.

It seems to me like there must be a serial code that needs to be sent to this MCU in order for me to try to communicate to it, but I'm admittedly somewhat new to the world of practical embedded programming (though I have done a fair bit with Arduinos). Does this seem plausible? Any other insights or thoughts are welcome and appreciated!

Thanks in advance

Excerpt from Generalplus datasheet on ISP

Excerpt from Generalplus datasheet on boot register

Boot register

  • \$\begingroup\$ This seems like a standard flash read/write protection feature. More or less every single MCU out there made during the past 25 years has some flavor of it. It started to become mainstream somewhere around year 2000, with the advent of flash memories. And usually you don't have to meddle with this manually unless you are writing a bootloader: decent flash programmers have an option to secure the parts for you during production programming. \$\endgroup\$
    – Lundin
    Commented Apr 3 at 13:26
  • \$\begingroup\$ Thanks for your thoughts! Yeah I agree that this seems like there read/write protection. I've been poking around this device in hopes that I may be able to access the firmware and it seems like it can be done through the serial port (I say that because on the device the serial port is exposed), but it may require a specific programmer or something. \$\endgroup\$
    – Ceiling
    Commented Apr 3 at 18:26

1 Answer 1


SWD stands for "Serial Wire Debug" and is a common debug interface with ARM cores. See ARM's documentation for details. However, it is not comparable to common asynchronous protocols that we know from UARTs.

According to the data sheet, the SWD interface is active only under certain security levels, see chapter The security level is controlled by the value in USER_OPT3.

The clock line SWCLK is shared with the reset input (for example, page 17):

RESETn / SWCLK [...] Reset pin with Serial Wire Debug clock pin function

The data line SWDAT is an alternate function of P2 bit 15 (for example, page 20):

P2.15 [...] General purpose I/O Port 2.15

SWDAT [...] Serial Wire Debug Port data pin

This alternate function is enabled per default after a reset (page 346):

GPIO2_ALT1.Px15_ALT default value is 0x1, 0001 = SWDAT.

To use SWD on your MCU, you need some device that knows the protocol and connect it. And additionally the security level must not be "too" secure.

  • \$\begingroup\$ Thanks for your thoughts! I guess it seemed odd to me, because on the device that I'm working with, the serial port is exposed, which led me to think that would be the method to interact with the MCU; but it also seems like the UART is not active unless placed in SWD mode, which entails making connections to the SWD pins described. I wonder if there's perhaps some other way to place it in this SWD mode via the UART, but there's no mention of that. It seems like if I want to continue with the project and try to interact with the device, I need to try to make a connection with a debugger \$\endgroup\$
    – Ceiling
    Commented Apr 3 at 18:36
  • \$\begingroup\$ @Ceiling I wanted to extend my answer, but unfortunately the website does not allow me to download the data sheet again. I have changed machines. -- I see SWD as a fixed technical term assigned to ARM's protocol. -- Many MCUs have an additional interface over the UART, but commonly this is called ISP, not SWD. For NXP, for example, you need to send '?' as the first character for auto-baud detection, and some more. -- But we are talking about a Chinese design here, aren't we? :-D \$\endgroup\$ Commented Apr 3 at 18:52
  • \$\begingroup\$ yeah ISP is how it's described in that first excerpt and that sounds more akin to the behavior I'm trying to achieve but it's odd that it mentions SWD mode in that same section. Like you said though it's Chinese/Taiwanese design/documentation so who knows haha. I might try to send some characters to it via the serial port at various Baud rates etc. maybe I'll get some response. I have this dev kit: silabs.com/development-tools/mcu/32-bit/… which has a debugger on it, so maybe I can try that too if I'm feeling fancy. \$\endgroup\$
    – Ceiling
    Commented Apr 3 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.