简介STM32-RJGT105通信demo是一套面向嵌入式开发者的演示工程用于测试STM32微控制器与RJGT105加密芯片之间命令收发、数据加密与安全认证的可行性和性能适合物联网设备、工业控制及其他有数据保护需求的场景也适合有一定STM32基础并希望接触加密芯片应用的开发者学习参考。压缩包共292个文件约24.02MB目录结构清晰既有C语言源文件.c/.h也有Keil工程配置文件.uvprojx/.uvoptx/.scvd、编译链接过程文件.o/.d/.crf/.axf/.map以及可复用的ARM数学库.a/.lib等便于直接打开工程、查看中间产物或自行编译验证。目前已有403人浏览学习。demo重点覆盖RJGT105的初始化、密钥交换、数据加解密和双向安全认证流程并集成命令发送接收、数据帧处理、错误检测与调试输出机制开发者可从源码到Hex/Axf产物完整走通一次通信验证还能利用版本号与日期标识进行迭代管理是快速评估加密芯片兼容性和启动加密通信开发的实用起点。 搞嵌入式这一行最常遇到的就是这种场景供应商或者同事丢过来一个压缩包文件名写着STM32-RJGT105-demo-v1.0-20220713.rar没有配套文档没有接线图就一句话“你先跑一下 demo”。这个包看起来普通其实是一个很典型的 STM32 外设验证工程主控是 ST 的 STM32 系列RJGT105 是板上的核心外设芯片demo 代码的任务就是在 STM32 上完成对 RJGT105 的初始化、通信和功能验证。如果你刚接触这种项目最想知道的肯定是这东西怎么打开怎么编译怎么烧进去跑起来之后怎么确认它真的在工作这篇文章我就从实战角度完整走一遍这类 demo 工程的处理流程。内容包括解压后怎么快速看懂工程结构、Keil MDK 环境怎么配、编译烧录有哪些细节、RJGT105 这类外设驱动的调用逻辑长什么样以及我在调试过程中踩过的坑。尽量做到每个步骤都能直接照着操作。1. 拿到压缩包先别急着解压先分析这个工程要验证什么1.1 从文件名还原项目背景STM32-RJGT105-demo-v1.0-20220713.rar这个名字本身就包含了不少信息别直接双击解压就完事。STM32是主控平台说明工程是给 STM32 用的具体哪个型号要看工程内的芯片型号配置。RJGT105是项目要驱动的目标器件大概率是板子上的一颗功能芯片。demo表示这是一个演示/验证工程通常是厂商或方案商写好、用来验证基本功能的不代表最终产品代码。v1.0是版本号方便追溯。20220713是打包日期可以用来判断代码的时间背景。把这个文件名拆开看能提前有个预期这个 demo 大概率是基于某一个具体芯片型号开发跑通后你会看到特定的现象比如串口打印数据、LED 闪烁、液晶屏显示等。RJGT105 具体是什么其实不影响我们打开工程的第一步但知道它的存在很重要——后面你会发现整个 demo 的代码逻辑基本都围着它转。1.2 解压后的典型目录结构与代码位置解压后常见的情况是里面有几个子目录命名风格多是多少带点厂商特色但规律是相通的。我见过最多的结构大概是这样的User或USER存放main.c、stm32f10x_it.c中断服务函数、系统初始化相关代码。Hardware或HARDWARE放置外设驱动比如rjgt105.c、led.c、key.c这是 RJGT105 驱动最可能所在的位置。Core或CORE存放 STM32 内核相关文件比如启动文件startup_stm32f10x_hd.s。Library或FWLib标准外设库文件比如stm32f10x_gpio.c、stm32f10x_usart.c等。Project或MDK-ARMKeil 工程文件后缀一般是.uvprojx直接双击打开这个就能进入编译环境。拿到目录后我建议先看两个文件一个是readme.txt如果有一个是main.c。很多 demo 虽然没配文档但会在代码开头用注释说明接线方式、硬件配置、预期现象。如果main.c里没有就去Hardware下面的驱动文件里找RJGT105 的寄存器操作、通信协议都写在里面。另外建议先确认一下芯片型号和工程目标芯片是否一致。打开 Keil 工程后点击魔术棒Options for Target在 Device 标签页能看到当前选择的芯片。如果代码是 F1 系列的你实际用的芯片也是 F1基本没大问题如果代码基于 F1 标准库但你板子上是 F4 或 G0 系列那这个工程就需要花大力气移植不能直接跑。2. 编译环境搭建Keil MDK 的版本与器件包匹配是个重点2.1 需要的软件和器件支持包绝大多数的 STM32 demo 工程都是用 Keil MDK 写的少数用 IAR 或者 STM32CubeIDE。如果你的压缩包里是.uvprojx后缀那就是 Keil 工程环境这块主要是三个东西Keil MDK 本体。建议装 MDK 5.2x 或者更高版本因为新版本可以兼容打开多数旧工程。需要注意一个事同电脑上 Keil 的 C51 版和 MDK 版本是可以共存的安装顺序先装 C51 再装 MDK 或者反过来都行但两者安装目录不要混用。DFPDevice Family Pack器件包。打开工程前先在 Pack Installer 里找到自己芯片对应的器件包比如Keil.STM32F1xx_DFP。没有这个包编译时会报一堆 “cannot open source file ...” 或 “device not found” 之类的错误。ST-Link 驱动。下载烧录用如果你的调试器是 ST-Link V2驱动不装的话 Keil 里根本识别不到调试器。安装完这三样基本能把工程打开。如果你电脑上已经装了其他 STM32 开发环境比如 STM32CubeMX那不影响CubeMX 生成的代码和 Keil 工程也可以互相配合但本篇文章的流程以 Keil MDK 为主线。2.2 打开工程时的低频错误和处理办法打开.uvprojx后常见的有这么几种情况不一定每次都一帆风顺提示 Device 不存在或未安装去 Pack Installer 里搜对应系列比如 STM32F103 或 STM32F407下载对应的 DFP。编译后头文件路径不对很多 demo 的问题出在 “Include Paths” 配置和实际目录不一致。常见报错是fatal error: stm32f10x.h: No such file or directory。解决办法是右击工程文件选择 Options for Target → C/C → Include Paths把Library、User、Hardware这几个目录按实际路径加进去。我一般习惯用相对路径比如..\Libraries\CMSIS这样整个文件夹复制到别的电脑也不会因为盘符变化而失效。报错某个.s启动文件路径不对这种情况通常在 GCC 风格编译或工程文件从别的 IDE 迁移过来时出现把对应启动文件重新加进工程或者直接改文件路径即可。如果打开后能正常编译但编译报一堆语法错误比如error: #5: cannot open source input file极大可能是工程目录里少文件或者.h文件没找到优先排查 Include Paths 而不是去改代码。3. 把 demo 烧到板子上从接线到下载配置一条龙3.1 SWD 接线与调试器配置工程一旦能编译通过烧录就相对简单了。目前比较通用的是 ST-Link V2 配合 SWD 接口只需要接四根线不用像 JTAG 那样接一堆ST-Link V2 引脚目标板引脚说明SWDIOPA13 或标有 SWDIO 的排针数据线SWCLKPA14 或标有 SWCLK 的排针时钟线GNDGND共地3.3V 或 5V板子电源端一般是给板子供电有的板子本身有电就不用接如果板子有独立供电只接 SWDIO、SWCLK、GND 三根线也够用但 ST-Link 和板子必须共地这是一个很容易被忽视的细节。接好之后Keil 里点击 Options for Target → Debug选择右侧的 ST-Link Debugger再点 Settings正常情况下能看到 SW Device 窗口出现芯片 IDCODE。如果 Settings 里识别不到设备别慌优先查三件事接线是不是松了。板子是否在供电状态。目标板上的复位电路是否异常。另外一个我经常踩的坑是板子上如果有其他程序占用了 SWD 引脚或者配置了禁用调试引脚的功能会导致调试器连不上。这时候可以采取“按住复位键、点下载、再松开复位”的操作方式或者把 BOOT0 拉高进入 Bootloader 模式再擦除具体操作后面会细说。3.2 下载配置的细节和启动流程在 Keil 的 Flash Download 页面里注意勾选 “Reset and Run”这样程序下载完成后会自动复位运行省去手动按复位键的步骤。下载时需要确认几个配置项勾选Erase Full Chip或者Erase Sectors推荐后者烧录速度更快。编程算法Programming Algorithm要匹配芯片型号比如 F1 系列选STM32F10x Med-density Flash或High-density如果选错下载时会报Flash Download failed - Cortex-M3的错误。波特率或下载速度一般不用改但如果你接线过长或者线材质量差可以把 SW 速度从默认的 4MHz 往下调比如 1MHz这样更稳定。下载完成后板子上的现象可能有很多种LED 灯在闪、串口输出数据、屏幕显示了界面这都是 demo 的正常表现。如果完全没现象先别急着改代码优先确认电源正常、晶振有没有起振、复位引脚有没有被拉低。另外提一句启动模式。STM32 的 BOOT0 和 BOOT1 引脚状态决定了复位后从哪启动。正常运行时 BOOT0 应该接低电平GND从主 Flash 启动如果 BOOT0 被拉高会进入系统存储器 Bootloader程序不会跑。这也是一个很常见的“为啥我的板子没反应”的原因。4. RJGT105 驱动代码在 demo 里的调用逻辑拿串口日志反推验证流程4.1 主程序中的初始化顺序与业务主循环打开main.c你会发现 demo 程序的骨架一般长这样先是系统时钟初始化然后 GPIO、串口、I2C/SPI 等外设初始化再对 RJGT105 做一些寄存器配置最后进入while(1)主循环循环执行功能。拿外设验证型 demo 来说主循环里往往会有几个关键行为定期采集或读取 RJGT105 的输出。把读取到的数据通过串口打印出来。根据读取结果点灯或做状态指示。如果你想快速确认 RJGT105 是否工作正常最好的方式是看串口打印。很多 demo 会用printf重定向到串口输出比如读到的版本号、寄存器值、实时采样值等。如果你在main.c里看到printf(RJGT105 ...)这类语句就可以顺着输出内容去核对硬件状态。重定向printf到串口一般需要重写fputc函数。有些工程里会把这个函数单独放在usart.c里并勾选微库Use MicroLIB如果你改代码时发现串口打印不出来可以查一下这两个部分有没有配置齐全。4.2 通信接口的选择与时序注意事项RJGT105 的通信方式通常取决于它的设计可能是 I2C、SPI 或 UART。不同接口在理论上的注意事项差别挺大但放在实际调试中有一个共性先确认电平、时序、寄存器地址再谈数据对不对。以最常见的情况为例如果 RJGT105 走的是 I2C 接口那么初始化代码里一般有这几步开启 I2C 外设时钟。配置对应引脚的复用功能比如 PB6/PB7 用于 I2C1。设置 I2C 时钟频率标准 100kHz 或快速 400kHz。按器件地址发送读/写命令。调试时遇到 I2C 读不到数据我建议先用逻辑分析仪或者示波器抓一下 SCL 和 SDA 波形确认地址字节是否正常发出。很多外设芯片的器件地址是可配置的由硬件引脚高低决定如果你板上的 RJGT105 地址和代码里写的不一致就会出现总线有波形但芯片不 ACK 的情况。这个用示波器一眼就能看出来代码排查半天反而没用。如果 RJGT105 走的是 SPI那还要注意极性CPOL和相位CPHA的配置。SPI 的毛病比较隐蔽有时候读出来的数据全是 0xFF 或全 0基本就是模式不匹配。把代码里的 SPI Mode 从 Mode0 改成 Mode3 再试一下是常见的快速验证方式。UART 则要重点确认波特率是否一致。如果代码里配了 115200而你串口调试助手用 9600 打开那出来的肯定全是乱码。另外注意串口的参考地一定要和板子共地。4.3 从驱动函数反推 RJGT105 的验证步骤打开rjgt105.c名字可能略有差异你会看到几个函数比如RJGT105_Init()、RJGT105_ReadData()、RJGT105_SendCmd()。这些函数的本质就是按照芯片数据手册通过通信接口读出或写入寄存器。在 demo 代码里RJGT105 的验证逻辑一般按这个顺序走复位/初始化让芯片进入就绪状态。读取芯片 ID 寄存器判断通信是否成功。配置工作参数。进入主循环持续读取数据并展示。我建议把第三步作为一个重要的“验证锚点”。比如 demo 里如果读取 ID 的代码返回值和期望值不一致那直接说明物理链路或者地址配置有问题后面的功能测试都不用看了。如果 ID 能读对说明通信链路基本没有问题后续数据不对重点找寄存器配置和时序细节。5. 调试过程中最常踩的坑与排查思路5.1 串口输出乱码或者完全没有输出的定位方法这是 STM32 调试里出现频率最高的一个现象几乎每个做这个 demo 的人都会碰到。乱码的核心原因是时钟频率和波特率不匹配。比如代码里期望外部晶振是 8MHz但板子上焊的是 12MHz 晶振此时串口波特率会整体偏移输出的就是乱码。处理方法核对工程里的 HSE_VALUE 宏定义和实际晶振是否一致一般在stm32f10x.h里可以找到类似#define HSE_VALUE ((uint32_t)8000000)的宏如果板子是 12M 晶振这里要改成 12000000。完全没有输出的情况通常是fputc重定向没写对串口输出只是空函数。串口引脚复用配置错误比如明明用的是 PA9/PA10代码里却配了 PB6/PB7。串口调试助手的波特率、数据位、停止位和代码不一致。串口线短路或接触不良特别是用 USB 转 TTL 模块的时候TX/RX 接反了也不输出。建议在调试时先做一个自检在初始化的 GPIO 上写一个翻转操作用示波器量引脚电平。如果 IO 能翻说明时钟、GPIO 配置正常问题大概率在串口配置层。如果 IO 完全不翻则先排查时钟和启动问题。5.2 外设通信失败的快速诊断方法RJGT105 通信失败不要直接陷入代码日志分析先用示波器看波形。这是我反复强调的一点因为波形可以直观告诉你问题出在电气层还是逻辑层。快速诊断顺序用示波器探头夹在 SCL/CLK 引脚上看有没有时钟信号。看数据线有没有数据活动。观察数据线上的高电平是否达到了预期的电压水平。比如 3.3V 电平的系统如果数据线高电平只有 1V那可能是上拉电阻没焊或者接错线。如果时钟和数据波形都有但芯片没 ACK基本可以锁定在器件地址、从机供电、复位引脚三件事上。我遇到过非常多次板子上的 RJGT105 复位引脚被默认拉低导致芯片一直处于复位状态总线怎么操作都没回应。查一遍原理图上的复位脚和使能脚往往比改代码有效率得多。5.3 调试器引脚复用与“连不上 ST-Link”的坑有一点必须特别提出来STM32 的调试接口引脚也是普通 IO如果程序里把它们复用成别的功能调试器就可能会失联。比如 PA13、PA14SWDIO、SWCLKPA15、PB3、PB4JTAG 相关都可能在用户代码里被重映射成 GPIO、PWM 等。一旦烧录了这样的程序下次想用 ST-Link 再下载很可能就提示Cannot access target。遇到这种情况我的处理方式是先按着板子上的复位键不放。在 Keil 里点击下载。看到下载进度开始后立刻松开复位键。如果这个方法不行就把 BOOT0 引脚跳到高电平复位让芯片进入 Bootloader此时内核不会执行用户程序调试器就能重新连接并擦除 Flash。擦除后把 BOOT0 跳回低电平恢复正常烧录。这个方法几乎可以救活所有“连不上调试器”的板子。5.4 看门狗没关导致程序反复复位很多 demo 为了模拟真实产品环境会在初始化里打开独立看门狗IWDG或窗口看门狗WWDG。如果你的调试停在了某个断点上几秒钟后程序会整体复位或者芯片一直在崩溃、复位循环大概率就是看门狗没喂。处理办法是先在初始化代码里把看门狗相关的初始化函数注释掉等调试完功能再打开。这是一个看起来很小、但特别容易让人怀疑人生的坑。另外如果编译选项里开了低功耗模式也会导致调试器连接异常不过这种 demo 工程一般不会特意开低功耗。5.5 编译下载成功但板子无现象的标准排查流程如果编译下载都正常但板子一点反应都没有不要抓瞎按这个顺序排查量电源3.3V 是否正常电流是否异常。量复位引脚是否被拉低。量晶振用示波器看 OSCOUT 引脚有没有正弦波/方波输出。量 BOOT0确认是低电平。用 LED 点灯法写一段最简单的 GPIO 翻转程序烧录如果灯能闪说明最小系统没问题问题在 demo 代码的业务逻辑如果连灯都不闪说明最小系统本身有故障。这个流程看起来基础但能省掉大量无效调试时间。我见过很多人一上来就怀疑 RJGT105 驱动写得不对最后发现是板子的 3.3V 稳压芯片虚焊导致的供电问题。6. 看懂 demo 之后怎么把验证代码迁移到自己的项目里跑通 demo 只是一个开始实际产品开发里你通常不会直接把 demo 代码搬过去用而是需要把关键部分抽出来放进自己的工程。这一步我建议做好三个动作精读main.c的初始化顺序把和 RJGT105 相关的代码摘出来确认依赖哪些外设和 GPIO。分析rjgt105.c里哪些是芯片底层寄存器操作哪些是业务逻辑。底层操作一般可以直接复用业务逻辑要按产品需求重新写。注意 demo 里可能有一些临时调试代码比如特意加的延时、打印日志等这些在正式工程里要清理干净。举一个典型的迁移案例。假设你的产品要用 STM32 通过 I2C 读取 RJGT105 的数据并在 OLED 上显示。从 demo 里要抽的就是I2C 初始化函数、RJGT105 的读寄存器函数。而 demo 主循环里控制 LED 闪烁的代码、串口打印数据的代码则全部不要。把这些抽出来后放进自己的工程再在main.c中调用就能保持功能整洁。迁移过程中最容易犯的错是不看芯片时钟树配置直接把 demo 里的外设初始化代码复制过来结果发现自己的工程用的是 72MHzdemo 用的是 48MHzI2C 时序完全对不上。所以复制代码时外设时钟频率、预分频值这类常量一定要和自己的主频对应起来。还有一个细节HAL库和标准库的初始化方式完全不同。如果你的工程是HAL库而 demo 是标准库那GPIO_InitTypeDef、I2C_InitTypeDef这些结构体都不能直接用要换成HAL_GPIO_Init、HAL_I2C_Mem_Read之类的模型。这个转换过程比较琐碎但没有多少技术难度只要懂 HAL 库的基本写法就能搞定。另外关于 RJGT105 这类芯片很多厂商没有公开全套寄存器手册demo 里的驱动函数本身就是最好的参考资料。读懂它你也就等于拿到了芯片的“半份数据手册”用途非常大的。我在实际使用中还有一个习惯拿到一个 STM32 demo 工程后会先在工程里全局搜索printf和while(1)把所有输出点列出来再对照硬件去逐个验证。一旦串口目标数据都正常显示了这个 demo 的核心功能就基本算是吃透了。最后再提醒一句demo 虽然能跑通但它只是“最低可行验证”真正常年运行的设备还要考虑异常处理、低功耗、掉电保存等产品化问题这些往往需要从头自己写。带着这个预期去看 demo你收获的会更多。本文还有配套的精品资源点击获取