io.c的这个文件写法似乎是有问题的
static const uint32_t gpio_reg_base_list[GPIO_COUNT] = {
#if GPIOA_ENABLE
GPIOA_BASE,
#endif
#if GPIOB_ENABLE
GPIOB_BASE,
#endif
#if GPIOC_ENABLE
GPIOC_BASE,
#endif
#if GPIOD_ENABLE
GPIOD_BASE,
#endif
#if GPIOF_ENABLE
GPIOF_BASE,
#endif
};
如果在宏定义设置为这样的情况下，
#define GPIOA_ENABLE 1
#define GPIOB_ENABLE 1
#define GPIOC_ENABLE 0
#define GPIOD_ENABLE 0
#define GPIOF_ENABLE 1
数组实际上是
static const uint32_t gpio_reg_base_list[GPIO_COUNT] = {
GPIOA_BASE,
GPIOB_BASE,
GPIOF_BASE,
};
使用GPIOF的时候 传入的参数GPIO_COUNT = 5的，因为在下面这个emum里面并不是浮动的IDX
enum gpio_idx_t {
#if GPIOA_ENABLE
GPIOA_IDX = 0,
#endif
#if GPIOB_ENABLE
GPIOB_IDX = 1,
#endif
#if GPIOC_ENABLE
GPIOC_IDX = 2,
#endif
#if GPIOD_ENABLE
GPIOD_IDX = 3,
#endif
#if GPIOF_ENABLE
GPIOF_IDX = 5,
#endif
GPIO_IDX_NUM,
GPIO_INVALID_IDX,
};
这种情况下就超越gpio_reg_base_list数组界限取值了，最后的表现是操作PF0/PF1没任何反应。

建议改为
static const uint32_t gpio_reg_base_list[GPIO_COUNT] = {
GPIOA_BASE,
GPIOB_BASE,
GPIOC_BASE,
GPIOD_BASE,
GPIOF_BASE,
};

支持RAMIO，即通过调试口访问目标芯片的特定RAM，实现数据交互，类似RTT(J-Link)及Nuconsole(Nu-Link)

目前是划线状态，是已经实现了还是放弃做这个功能了？

我寻思如果调试器默认能自动从RTT CB 读取日志数据然后通过CDC上报用起来可就太方便了。

can not build with the following command in ubuntu :

cd Vllink_Lite/vsf/project_vllink_lite/vllink_lite/cmake_vllinklite_gd32f350
cmake -GNinja -S. -Bbuild

ERROR LOG:
-- No build type selected, default to Debug
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:85 (add_subdirectory):
The source directory

/home/huyiice/git/Vllink_Lite/vsf

does not contain a CMakeLists.txt file.

-- Configuring incomplete, errors occurred!
See also "/home/huyiice/git/Vllink_Lite/vsf/project_vllink_lite/vllink_lite/cmake_vllinklite_gd32f350/build/CMakeFiles/CMakeOutput.log".
See also "/home/huyiice/git/Vllink_Lite/vsf/project_vllink_lite/vllink_lite/cmake_vllinklite_gd32f350/build/CMakeFiles/CMakeError.log".

Hi talpachen,

Thanks for your great work at first. Here I have got a bit confused by the timing and hope you are able to clarify.

I have noticed that GD32F3X0 SPI is configured as MODE3 (both CKPL and CKPH are set), see swd.c:
· SPI_CTL0(SWD_SPI_BASE) |= SPI_CTL0_MSTMOD | SPI_CTL0_SWNSSEN | SPI_CTL0_SWNSS | SPI_CTL0_LF | SPI_CTL0_CKPL | SPI_CTL0_CKPH;`

Refer to the SWD protocol, target device always put bit on(after) Rising edge of CLK while host tries to read data.
But at the same time, SPI MODE3 always try to sample data on Rising edge, too, so it seems here is a competitive condition.
If SCK goes high from low which means it will sample data from MISO, but the data is not ready (at least it is not steady) because the rising signal just tells target to put the data on.

Thanks in advance.

您好，看了原理图有些不明白，加上我对stm32系列单片机也几乎没有认识，所以有些疑问

U3的W25Q64是否需要实装，看您给的照片一个装了，一个未装？照我理解，似乎bin还未大到必须要扩到外部flash的。

另外，这个gd32在用openocd，或者 pyocd时，是否能直接用stm32的target文件?

目前9.9的PWLINK Lite使用的芯片是GD32F303CCT6，如果能刷这个固件就可以自定义固件了

I tried to use the probe with latest pyocd,
For "pyocd list" command, the probe can be recognized,

$ pyocd list
  #   Probe/Board             Unique ID                  Target
-----------------------------------------------------------------
  0   ARM DAPLink CMSIS-DAP   Vllink.Basic.BB7041D1766   n/a

While if I tried to connect the chip via below command,
pyocd cmd -t stm32f103c8

It reports something as below,
pyocd.core.exceptions.TransferError: No ACK received

Only in very seldom case, the connection can be established, while also not stable enough.

Could you help to have a check?