Hao Ge's Lab Blog

博客的自动部署方案

2025-11-17T00:00:00.000Z

本站博客采用Markdown书写，在本地编辑完成后生成静态HTML文件，经 Git 推送至部署服务器，部署服务器基于 systemd 创建服务，实现自动部署。

整体工作流程

提示

为了简化部署时的拷贝操作，所有 HTML 文件存放在 build 目录下。

本地构建与推送

首先，在完成文章编辑及本地测试后，执行发布脚本生成 HTML 并提交到 Release 仓库。

release.sh
#!/bin/zsh

# 1. 执行 build
echo "🔨 正在构建项目..."
npm run build
if [ $? -ne 0 ]; then
  echo "❌ 构建失败"
  exit 1
fi
echo "✅ 构建完成"

# 2. 定义发布目录
RELEASE_DIR="../release-haoge-org"

# 3. 检查发布目录是否存在，如果不存在则创建
if [ ! -d "$RELEASE_DIR" ]; then
  mkdir -p "$RELEASE_DIR"
  echo "📁 创建目录: $RELEASE_DIR"
fi

# 4. 清空发布目录中除了 .git 和 .gitignore 以外的所有内容
echo "🧹 清理发布目录..."
rm -rf "$RELEASE_DIR/build"
cd - > /dev/null

# 5. 复制 build 内容到发布目录
echo "📋 复制构建内容..."
if [ -d "build" ]; then
  cp -a build "$RELEASE_DIR/"
  echo "✅ 内容复制完成"
else
  echo "❌ 构建目录 build 不存在"
  exit 1
fi

# 6. 添加 git commit
echo "💾 提交更改到Git..."
cd "$RELEASE_DIR"

# 添加所有更改
git add .

# 检查是否有更改需要提交
if ! git diff-index --quiet HEAD --; then
  TIMESTAMP=$(date -Iseconds)
  git commit -m "Deploy $TIMESTAMP"
  echo "✅ Git提交完成"

  git push origin main
else
  echo "ℹ️  没有更改需要提交"
fi

echo "🎉 部署流程完成！"

自动化部署机制

当 Release 仓库的内容被推送到部署服务器时，需要一套自动化机制来完成后续的部署工作。这里采用了基于 Git Hooks 和 systemd 的解决方案。

Git Hook 触发机制

Git Hooks 是 Git 提供的一种机制，允许我们在特定事件发生时执行自定义脚本。其中 post-receive 钩子会在 Git 服务器接收到推送内容后执行，非常适合用来触发后续的部署流程。

在部署服务上 Git 仓库的 post-receive 钩子脚本生成触发文件：

/var/lib/git-repository/blog.git/hooks/post-receive
TRIGGER_FILE="/var/lib/git-repository/blog-trigger.txt"
mkdir -p `dirname $TRIGGER_FILE`
date > "$TRIGGER_FILE"

每当有新的推送到达时，这个脚本会创建或更新一个触发文件 (blog-trigger.txt)，作为后续部署流程的启动信号。

提示

需保证git用户有写入触发文件的权限。

systemd 服务监听与响应

systemd 是 Linux 系统中的一个系统和服务管理器，提供了强大的服务管理功能。我们利用它的路径监控功能来监听触发文件的变化。

systemd.path 配置文件用于监控触发文件的变更：

/etc/systemd/system/blog-deploy.path
# /etc/systemd/system/blog-deploy.path
[Unit]
Description=Watch Git push trigger file

[Path]
PathModified=/var/lib/git-repository/blog-trigger.txt
Unit=blog-deploy.service

[Install]
WantedBy=multi-user.target

当 blog-trigger.txt 文件被修改时，systemd 会自动启动关联的 blog-deploy.service 服务。

相应的 systemd.service 配置文件定义了实际要执行的部署任务：

/etc/systemd/system/blog-deploy.service
# /etc/systemd/system/blog-deploy.service
[Unit]
Description=Deploy Git repo (release branch) to web root
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/deploy-blog.sh
User=root

这里的 Type=oneshot 表示这是一个一次性执行的任务，而非持续运行的服务。

实际部署脚本

最后，deploy-blog.sh 脚本负责具体的部署操作：

/usr/local/bin/deploy-blog.sh
#!/usr/bin/env bash

set -e

BARE_REPO="/var/lib/git-repository/blog.git"
DEST_DIR="/var/www/blog"
TMP_WORK_TREE="/var/www/blog.build"

rm -rf $TMP_WORK_TREE
mkdir -p "$TMP_WORK_TREE"

git clone "$BARE_REPO" "$TMP_WORK_TREE" 
rm -rf  $TMP_WORK_TREE/.git

rm -rf $DEST_DIR
mv $TMP_WORK_TREE/build $DEST_DIR
rm -rf $TMP_WORK_TREE

chown -R www-data:www-data $DEST_DIR

该脚本会克隆最新的代码到临时目录，移除 Git 相关文件，然后将构建好的内容移动到 Web 服务器目录，并设置正确的文件权限。

启用和测试服务

在添加上述服务文件后，需要启用对应的服务使之生效：

# 重新加载配置
sudo systemctl daemon-reload

# 启用并启动
sudo systemctl enable --now blog-deploy.path

# 查看状态
systemctl status blog-deploy.path

可以通过手动更新触发文件来测试整个部署流程是否正常工作：

date > /var/lib/git-repository/blog-trigger.txt

这套自动部署方案实现了从本地编辑到线上发布的全流程自动化，大大简化了博客内容的更新流程。

STM32F103C8T6 开发板 PB3 引脚作为普通 GPIO 引脚

2025-11-07T00:00:00.000Z

STM32F1xx 系列的部分引脚默认作为 JTAG/SWD 调试接口引脚。官方文档对这些引脚的功能定义如下：

SWJ_CFG [2:0]	JTAG-DP	SW-DP	PA13 / JTMS / SWDIO	PA14 / JTCK/SWCLK	PA15 / JTDI	PB3 / JTDO/TRACE SWO	PB4 / NJTRST
000	✅	✅	❌	❌	❌	❌	❌
001	✅	✅	❌	❌	❌	❌	✔️
010	🚫	✅	❌	❌	✔️	✔️	✔️
100	🚫	🚫	✔️	✔️	✔️	✔️	✔️

备注

每次 Reset 后，默认模式为 000，即 JTAG-DP 和 SW-DP 都被启用。
激活 SWD 时，仅当调试器没有激活 SWO 时，PB3 引脚才可以作为普通 GPIO 引脚使用。

HAL 库提供了如下宏来设置使用的 JTAG/SWD 模式：

stm32f1xx_hal_gpio_ex.h
/**
  * @brief Enable the Serial wire JTAG configuration
  * @note  ENABLE: Full SWJ (JTAG-DP + SW-DP): Reset State
  * @retval None
  */
#define __HAL_AFIO_REMAP_SWJ_ENABLE()  AFIO_DBGAFR_CONFIG(AFIO_MAPR_SWJ_CFG_RESET)

/**
  * @brief Enable the Serial wire JTAG configuration
  * @note  NONJTRST: Full SWJ (JTAG-DP + SW-DP) but without NJTRST
  * @retval None
  */
#define __HAL_AFIO_REMAP_SWJ_NONJTRST()  AFIO_DBGAFR_CONFIG(AFIO_MAPR_SWJ_CFG_NOJNTRST)

/**
  * @brief Enable the Serial wire JTAG configuration
  * @note  NOJTAG: **JTAG-DP**Disabled and SW-DP Enabled
  * @retval None
  */

#define __HAL_AFIO_REMAP_SWJ_NOJTAG()  AFIO_DBGAFR_CONFIG(AFIO_MAPR_SWJ_CFG_JTAGDISABLE)

/**
  * @brief Disable the Serial wire JTAG configuration
  * @note  DISABLE: **JTAG-DP**Disabled and SW-DP Disabled
  * @retval None
  */
#define __HAL_AFIO_REMAP_SWJ_DISABLE()  AFIO_DBGAFR_CONFIG(AFIO_MAPR_SWJ_CFG_DISABLE)

如果使用 CubeMX 生成的项目模板，则会在HAL_MspInit()中设置 JTAG/SWD 模式，例如：

stm32f1xx_hal_msp.c
void HAL_MspInit(void)
{
  __HAL_RCC_AFIO_CLK_ENABLE();
  __HAL_RCC_PWR_CLK_ENABLE();

  // **JTAG-DP**Disabled and SW-DP Enabled
  __HAL_AFIO_REMAP_SWJ_NOJTAG();
}

使用 SWD 调试，在关闭 SWO 功能时 PB3 引脚就可以作为普通 GPIO 引脚使用。使用 VSCode 调试时，修改启动配置文件launch.json，删除或关闭 swoConfig 配置项即可关闭 SWO 功能：

launch.json
{
  "showDevDebugOutput": "raw",
  "showDevDebugTimestamps": true,
  "cwd": "${workspaceRoot}",
  "executable": "build/Debug/${workspaceRootFolderName}.elf",
  "name": "Launch STM32",
  "request": "launch",
  "type": "cortex-debug",
  "servertype": "openocd",
  "preLaunchTask": "CMake: build",
  "device": "STM32F103C8",
  "svdFile": "./STM32F103.svd",
  "runToEntryPoint": "main",
  "configFiles": ["openocd.cfg"],
  "swoConfig": {
    "enabled": false,
    "source": "probe",
    "swoFrequency": 115200,
    "cpuFrequency": 72000000,
    "decoders": [
      {
        "port": 0,
        "type": "console",
        "label": "SWO output",
        "encoding": "ascii"
      }
    ]
  }
}

问题排查

如果按照上述配置后 PB3 仍无法作为普通 GPIO 引脚使用，请进行以下检查：

确认在调试器终端选项中 SWO 功能已确实关闭，如 VSCode 终端下确实没有 SWO 终端了
断开电源并重新上电，确保配置生效
检查代码中是否正确调用了相应的 GPIO 初始化函数

Github 网络访问疑难杂症

2024-11-14T00:00:00.000Z

配置代理

git config --global http.proxy 192.168.10.2:20172
git config --global https.proxy 192.168.10.2:20172
git config --global http.version HTTP/1.1 

基于MINGW编译arm-none-eabi-gcc 14.1

2024-09-02T00:00:00.000Z

准备编译环境

安装必要包：

pacman -S --needed base-devel

下载MINGW包仓库

git clone https://kkgithub.com/msys2/MINGW-packages.git

编译arm-none-eabi-binutils

修改MINGW-packages/mingw-w64-arm-none-eabi-binutils/PKGBUILD的pkgber和pkgrel：

pkgver=2.42
pkgrel=1

修改checksum

cd MINGW-packages/mingw-w64-arm-none-eabi-binutils
updpkgsums 

编译

makepkg-mingw --cleanbuild --syncdeps --force --install --noconfirm

如果提示gpg key错误，可以gpg --recv-keys ${keys}导入key。

测试

编译arm-none-eabi-gcc

修改MINGW-packages/mingw-w64-arm-none-eabi-gcc/PKGBUILD的pkgber和pkgrel：

pkgver=14.1
pkgrel=1

更新checksum

cd MINGW-packages/mingw-w64-arm-none-eabi-gcc
updpkgsums 

编译

makepkg-mingw --cleanbuild --syncdeps --force --install --noconfirm

测试

STLink Mini刷v2固件

2024-09-01T00:00:00.000Z

1. 解除Read Protection

STLink V2的bootloader开启了Read Protection，导致起始的8KB Flash不能被修改，在刷写Flash前需要解除Read Protection。

可以使用openocd命令来解锁：

openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \
-c "init" -c "reset init" \
-c "stm32f1x unlock 0; reset init" \
-c "reset" -c "shutdown"

输出如下：

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J43S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.102632
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x1ba01477

看上去是手上的板子使用的仿制的mcu，在openocd安装目录(如*/usr/local/Cellar/open-ocd/0.12.0_1/share/openocd/scripts/target*)下找到target/stm32f1x.cfg，复制一份并命名为apm32f1x.cfg，将apm32f1x.cfg里的0x1ba01477修改为0x2ba01477:

...
#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0008 Section 26.6.3
      set _CPUTAPID 0x3ba00477
   } {
      # this is the SW-DP tap id not the jtag tap id
      set _CPUTAPID 0x2ba01477 #  <== replace 0x1ba01477 with 0x2ba01477!
   }
}
...

再次尝试使用openocd解锁flash：

openocd -f interface/stlink.cfg -f target/apm32f1x.cfg -c "init" -c "reset init" -c "stm32f1x unlock 0; reset init" -c "reset" -c "shutdown"

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : clock speed 1000 kHz
Info : STLINK V2J43S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.083684
Info : [apm32f1x.cpu] Cortex-M3 r2p1 processor detected
Info : [apm32f1x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for apm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[apm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x20036410
Info : flash size = 128 KiB
[apm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
shutdown command invoked

可以看到解锁成功，并且这个仿制的mcu是128KB的，可以刷V2.1的固件。

2. 备份旧固件

openocd的flash命令可以备份固件：

flash read_bank bank_id filename [offset [length]]

确认bank_id：

openocd -f interface/stlink.cfg -f target/apm32f1x.cfg -c "init" -c "reset init" -c "flash banks"

输出如下：

Open On-Chip Debugger 0.12.0
...
[apm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08002e0c msp: 0x20001ce0
#0 : apm32f1x.flash (stm32f1x) at 0x08000000, size 0x00000000, buswidth 0, chipwidth 0
...

openocd -f interface/stlink.cfg -f target/apm32f1x.cfg -c "init" -c "reset init" -c "flash read_bank 0 stlink-old.bin"

输出如下：

Open On-Chip Debugger 0.12.0
...
Info : device id = 0x20036410
Info : flash size = 128 KiB
wrote 131072 bytes to file stlink-old.bin from flash bank 0 at offset 0x00000000 in 2.005690s (63.818 KiB/s)

...

3. 刷ST-Link v2-1固件

% openocd -f interface/stlink.cfg -f target/apm32f1x.cfg \
-c "init" -c "reset init" \
-c "program STLinkV2.J28.M18_unprotection.bin 0x08000000" \
-c "reset" -c "shutdown"

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : clock speed 1000 kHz
Info : STLINK V2J43S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.085263
Info : [apm32f1x.cpu] Cortex-M3 r2p1 processor detected
Info : [apm32f1x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for apm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[apm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
[apm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
Info : device id = 0x20036410
Info : flash size = 128 KiB
** Programming Finished **
shutdown command invoked

4. 更新固件

使用官方的stm32 cube programmer更新固件。

5. 参考资料

VSCode STM32 Debug 问题分析

2024-08-29T00:00:00.000Z

Windows环境，使用VSCode调试STM32时，从点Debug按钮开始到板子启动需等待20s左右，这明显不太正常。当前使用的主要工具：

先将Cortex-Debug的Debug Timestamps选项打开：

.vscode/launch.json
{
    "configurations": [
        {
            "showDevDebugOutput": "raw",
            "showDevDebugTimestamps":true,
            ...
        }
        ...
    ]
    ...
}

按F5开启Debug，打开底部gdb-server终端，发现openocd启动很快，查看底部调试控制台，发现在file-exec-and-symbols卡住10多秒：

10-file-exec-and-symbols
...
-> 10^done

此处应该就是问题所在了，对应的Cortex-Debug源代码：

src/gdb.ts
private startGdb(response: DebugProtocol.LaunchResponse): Promise {
...
    } else {
        this.gdbInitCommands.push(`file-exec-and-symbols "${this.args.executable}"`);
    }
    const ret = this.miDebugger.start(this.args.cwd, this.gdbInitCommands);
    return ret;
...

Cortex-Debug是以mi2方式调用的gdb，先试试手动调用gdb：

arm-none-eabi-gdb  --interpreter=mi2
...
(gdb)
-file-exec-and-symbols ${efi-file}

同样会卡住10多秒，可以确认是gdb解析符号时出问题了。换了几个不同版本的工具链测试对比测试下结果如下：

Toolchain	结果
Windows arm-gnu-toolchain-13.2.rel1	卡
Windows arm-gnu-toolchain-12.3.rel1	卡
Windows MSYS2 gdb	不卡
Windows MSYS2 gdb-multiarch	不卡
MacOS Brew arm-none-eabi-gdb	不卡
Windows xPack arm-none-eabi-gdb	不卡

只有ARM家的工具链有这个问题，改用xPack提供的工具链完美解决此问题。

MacOS npm 网络访问疑难杂症

2024-08-26T00:00:00.000Z

镜像

npm一般需要通过镜像来访问，国内常见的镜像有:

yarn https://registry.yarnpkg.com/
tencent https://mirrors.cloud.tencent.com/npm/
cnpm https://r.cnpmjs.org/
taobao https://registry.npmmirror.com/
npmMirror https://skimdb.npmjs.com/registry/
ustc https://npmreg.proxy.ustclug.org/

推荐使用nrm管理要使用的镜像:

npm --registry https://registry.npmmirror.com install nrm
nrm use tencent

CA证书问题

在通过镜像使用npm install时，大概率会提示unable to get local issuer certificate，这需要配置好npm使用的CA证书。

安装必要CA证书：

brew install ca-certificates

设置npm使用的CA证书：

npm config set cafile /usr/local/share/ca-certificates/cacert.pem

其它问题

node-gyp需要本地机场的辅助访问，方式如下：

node-gyp install --proxy= --cafile=/usr/local/share/ca-certificates/cacert.pem

Hao Ge's Lab Blog

博客的自动部署方案

整体工作流程​

本地构建与推送​

自动化部署机制​

Git Hook 触发机制​

systemd 服务监听与响应​

实际部署脚本​

启用和测试服务​

STM32F103C8T6 开发板 PB3 引脚作为普通 GPIO 引脚

Github 网络访问疑难杂症

配置代理​

基于MINGW编译arm-none-eabi-gcc 14.1

准备编译环境​

编译arm-none-eabi-binutils​

编译arm-none-eabi-gcc​

STLink Mini刷v2固件

1. 解除Read Protection​

2. 备份旧固件​

3. 刷ST-Link v2-1固件​

4. 更新固件​

5. 参考资料​

VSCode STM32 Debug 问题分析

MacOS npm 网络访问疑难杂症

镜像​

CA证书问题​

其它问题​

整体工作流程

本地构建与推送

自动化部署机制

Git Hook 触发机制

systemd 服务监听与响应

实际部署脚本

启用和测试服务

配置代理

准备编译环境

编译arm-none-eabi-binutils

编译arm-none-eabi-gcc

1. 解除Read Protection

2. 备份旧固件

3. 刷ST-Link v2-1固件

4. 更新固件

5. 参考资料

镜像

CA证书问题

其它问题