企业官网建设流程全解析

拿到STM32L562 DK这块板子的第一反应是——板载资源真多，然后第二反应是——文档真厚。作为ST在安全低功耗这条线上的主力MCU之一，STM32L5系列最显眼的标签就是TrustZone，而我这次试用没有急着去碰安全分区，反而踏踏实实把基础外设体验了一遍：GPIO、串口、ADC、定时器PWM，外加一个I2C传感器。这套流程走下来，最大的感受是：L5的外设库和之前用过的L4差别不大，真正让新手卡住的地方往往在工程配置和安全边界上。这篇就把我踩过的坑、验证过的配置、以及实际跑通的代码一起整理出来，想玩L562 DK的可以直接照着走。

1. 项目概述与整体设计思路

1.1 STM32L562 DK到底是一块什么样的板子

STM32L562 DK是围绕STM32L562系列芯片出的一块开发套件，核心是Cortex-M33内核，主频最高可以到110MHz。和之前ST主流的M4内核MCU相比，L5系列最大卖点不是跑分，而是TrustZone安全架构，也就是把芯片内部逻辑划分成安全世界和非安全世界，代码、数据、外设都能按区域隔离。板子本身集成的东西也很多，板载调试下载器、OLED显示屏、摇杆、温湿度传感器、LED灯、麦克风之类，基本开箱就能跑不少Demo。

我这次试用选了一个相对“复古”的切入方式：先不管TrustZone，不管低功耗极限调优，就把基础外设挨个跑一遍。为什么这么做？因为我始终觉得外设驱动是嵌入式的老本行，你再怎么搞安全隔离、再怎么压功耗，最后落地还是得控制GPIO、收发串口、采集ADC。如果这些基础操作还需要临时查手册、翻Demo，那后面做安全启动、做低功耗状态机的时候，心态肯定崩。

1.2 基础外设体验的目标拆解

拿到板子之后，我给自己列了一个很明确的清单，总共五项：

• GPIO：点亮板子上的一个LED，再读一个按键，覆盖数字输出和数字输入。
• UART：通过板载虚拟串口输出调试信息，顺便验证printf重定向。
• ADC：采集板载电位器输出电压，计算实际电压值。
• 定时器PWM：用PWM做呼吸灯，吃透频率和占空比计算。
• I2C：读取板载温湿度传感器寄存器，拿到真实数据。

这套外设组合其实是嵌入式最常用的一套“全家桶”：数字量、模拟量、异步通信、同步通信、定时器。把这五个东西打通，整个板子的基本功就算过关了，后续不管做协议解析、传感器采集还是电机控制，都是在这些基础外设上叠逻辑，不会有太大的认知跳跃。

1.3 为什么“基础外设体验”值得单独写一篇

很多开发板试用文章上来就是“创建工程—配置—点灯”，中间的关键细节全被吞掉了。比如时钟树到底怎么配、调试器版本不对导致下载失败、BSP头文件路径找不到、TrustZone工程里外设访问遇到hard fault，这些才是真正让人卡住的地方。我这次踩了不少坑，有的坑甚至和L5本身关系不大，纯粹是工具链和工程模板的问题。

写这篇的意义在于，把你可能浪费一周时间踩的坑提前排掉。比如我刚拿到板子的时候，用CubeMX生成默认工程，下载后LED死活不亮，查来查去才发现是没有使能对应的GPIO时钟；又比如串口输出乱码，最后发现是CubeMX自动生成的时钟配置和板子实际晶振频率对不上。这些经验不写出来，代码再漂亮也是白搭。

2. 开发环境准备与工程搭建要点

2.1 软件工具链：CubeMX、CubeIDE和固件包

要跑L562 DK，标准配置是STM32CubeMX做图形化配置，STM32CubeIDE写代码、编译、下载。我用的版本是CubeMX 6.12、CubeIDE 1.15，固件包是STM32CubeL5的1.4.0版本。安装的时候有一点要注意：CubeMX第一次打开MCU/板卡选择界面时，如果找不到STM32L562 DK，说明CubeL5固件包没有自动下载完整，需要在CubeMX的Help -> Manage Embedded Software Packages里手动安装。

工程生成路径上也有个选择：CubeMX可以生成几种不同IDE的工程，包括STM32CubeIDE、MDK-ARM、IAR。我这次直接用CubeMX生成STM32CubeIDE工程，生成之后用CubeIDE打开编译，流程最顺，不需要额外导入操作。如果你平时习惯Keil，生成MDK工程也没问题，但后面我在第4章会提到一个Keil和CubeIDE工程之间复制代码时容易踩的坑。

2.2 工程结构：认识L5的TrustZone工程

L5系列和之前最大的不同就是TrustZone，工程生成的时候CubeMX会问你要不要启用TrustZone。这里我的建议非常明确：第一次跑基础外设，直接选Non-secure，不要勾TrustZone。

原因很简单，启用TrustZone之后，工程会被拆成两个子工程：安全工程和非安全工程。外设默认归安全世界所有，非安全代码要去访问这些外设，必须先通过SAU/NSBA等机制把外设开放给非安全世界。这一整套机制本身是L5的核心价值，但对“点个灯、打印个串口”来说就是纯成本和复杂度。先把Non-secure工程跑通，确认硬件和工具链没问题，再回头去研究TrustZone的划分，这个顺序更平滑。

提示：就算你最终做的是安全启动、安全存储这类项目，也建议先用Non-secure工程把每个外设的驱动、引脚映射摸清楚，然后再用一个独立的TrustZone Demo去验证隔离逻辑。两步分开做，出问题才好定位。

2.3 时钟与调试器配置

时钟配置是基础外设体验里很容易翻车的一步。L562 DK板载的晶体我这边用的是16MHz，而我用的是内部MSI时钟倍频到110MHz的高速主频。如果你在CubeMX里选择外部高速时钟HSE，务必确认板子实际晶振频率和CubeMX里填的值一致，否则后面串口波特率、定时器定时值全部会偏。

调试器这块，板载ST-LINK默认使用SWD接口。生成工程后检查Debugger选择是否为ST-LINK，Interface选SWD，频率不用太高，默认的就行。下载时如果提示找不到目标芯片，先看看ST-LINK的驱动固件是否需要升级，这个在STM32CubeProgrammer或者CubeIDE的Debug Configuration里都能看到。

3. 核心外设实操记录

3.1 GPIO点亮LED：从“点灯”看时钟与引脚配置

GPIO是所有外设里最简单的，但也是最容易因为缺一个步骤而全盘不工作的。我这块L562 DK板上有好几个LED，原理图上都有对应的MCU引脚标注。用CubeMX配置时，选中对应的GPIO引脚，模式设为GPIO_Output，初始电平设成High或者Low，生成代码。

生成的代码核心就三行：使能GPIO时钟、设置引脚模式、写电平。在STM32CubeIDE里，直接用HAL库调用：

HAL_GPIO_WritePin(LD1_GPIO_Port, LD1_Pin, GPIO_PIN_SET);

这里要注意，CubeMX生成的头文件里会自动定义类似LD1_Pin、LD1_GPIO_Port这样的宏，前提是你给这个引脚在CubeMX里设置了User Label。养成给引脚起用户标签的习惯，几周之后回来看代码会轻松很多，板子引脚叫什么一目了然。

我踩的第一个坑就在这：生成工程后没先看RCC是否使能了GPIO的时钟，结果在初始化函数里直接调用HAL_GPIO_WritePin，LED毫无反应。后来回去检查，发现CubeMX确实自动生成了时钟使能代码，但前提是配置界面里没有把引脚误设成别的模式。如果你芯片引脚多、工程又是从零开始，最稳妥的办法是生成代码后先看一眼main.c里的MX_GPIO_Init函数，里面应该有对每个GPIO端口的时钟使能调用。

按键输入的配置思路也类似，区别是模式选GPIO_PIN_INPUT，然后根据按键原理图接法选上拉还是下拉。L562 DK的按键我配置成输入模式加内部上拉，按下时读回来的电平是低电平。轮询读取很简单，但如果是做产品，建议直接用外部中断EXTI，别在主循环里用delay消抖填时间，高负载情况下会把整条逻辑拖垮。

3.2 UART串口打印：printf重定向和波特率之谜

串口是嵌入式调试器之外的“第二双眼睛”。L562 DK板载ST-LINK自带虚拟串口功能，枚举出来的串口设备可以直接在PC上打开，省掉外接USB转串口线，这点很舒服。

用CubeMX配置UART时，选一个空闲的USART外设，我这里用的是USART2，波特率先定115200，数据格式8N1。引脚映射在CubeMX里会自动分配，生成工程后调用HAL_UART_Transmit就能往外发数据。但真正用起来，每次都写一长串HAL函数太啰嗦，所以一般都会做printf重定向，把标准输出的fputc钩到串口发送上去。在Keil里要勾选MicroLib，在STM32CubeIDE里则是在代码里加一个fputc实现：

int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart2, (uint8_t *)&ch, 1, 10); return ch; }

这样连着写很多个printf，其实就是直接把字符串逐个字符通过串口发出去。实测下来，115200波特率下打印普通日志没有任何问题，但如果你的应用里有大量打印，建议单独开一个低优先级任务做打印调度，别在主循环里死等发送完成。

串口这里我最想强调的坑是波特率偏差。之前在某块板子上遇到过串口输出全乱码，调了半个下午没找到原因，最后发现是CubeMX的时钟树配置里HSE频率填错了，导致系统主频偏了，串口波特率跟着漂移。用L562 DK的时候，我对了一下板子的晶振标注，并确认CubeMX时钟树里的输入频率和它一致，之后串口再没出过乱码。串口打印对时钟精度的要求很直接，晶振差一点、倍频系数错一点，PC端收到的就是一堆无法解析的字节。

3.3 ADC采集电压：读取电位器和内部参考

L562 DK板上有一颗电位器，引脚直接连到MCU的ADC输入口，用起来非常方便，不需要额外接外部电路，就是专门给ADC体验用的。我配置时选了ADC1，分辨率12位，采样时间设置成比较长的档位，然后将电位器引脚对应的ADC通道加进去。

HAL库的ADC采集流程是：先校准，再启动转换，等待转换完成，最后读值。L5系列和L4一样都有校准寄存器，如果不做校准，读取的ADC值的精度会差一些，尤其在不同温度环境下误差会更明显。CubeMX生成的初始化代码不会自动执行校准，需要在启动之前手动调用：

HAL_ADCEx_Calibration_Start(&hadc1, ADC_CALIB_OFFSET, ADC_SINGLE_ENDED); if (HAL_ADC_Start(&hadc1) != HAL_OK) { Error_Handler(); } HAL_ADC_PollForConversion(&hadc1, 100); uint16_t adc_value = HAL_ADC_GetValue(&hadc1); float voltage = adc_value * 3.3f / 4096.0f;

电压计算的核心公式就是12位ADC对应的满量程是4096，参考电压3.3V，所以adc_value / 4096乘以3.3就是实际电压。你可能会问为什么不直接乘，因为整数除以4096就变成0了。

实际测量时我转动电位器，串口打印的电压值从0.1V到3.25V左右平滑变化，曲线非常线性。如果发现ADC读数一直停在4095或者0，优先检查引脚配置是不是复用成了GPIO、参考电压引脚有没有接对。另外ADC输入电压一定不要超过VDDA，超过之后芯片内部会有漏电流路径，长时间运行对芯片不好。

3.4 定时器PWM：用呼吸灯吃透频率和占空比

定时器PWM是这几个外设里最需要数学的一环，但其实只要搞懂两个寄存器就通了：PSC预分频和ARR自动重载值。PWM频率的计算公式是：

PWM频率 = 定时器时钟 / ((PSC + 1) * (ARR + 1))

占空比则由CCR寄存器决定，占空比 = CCR / (ARR + 1)。我在L562 DK上用TIM2的某个通道生成PWM，通过灯光呼吸效果来验证。先定一个舒适的目标频率，比如1kHz，触摸定时器时钟如果来自APB1定时器时钟80MHz，那么要让公式成立，可以取PSC=79，ARR=999，算下来频率正好是80MHz / (80 * 1000) = 1kHz。

CubeMX里配置好PWM模式和目标引脚后，生成的代码里已经预填了PSC和ARR，你要做的就是启动PWM输出并且不断修改占空比：

HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1); while (1) { for (uint16_t pwm_value = 0; pwm_value < 1000; pwm_value += 5) { __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, pwm_value); HAL_Delay(10); } for (uint16_t pwm_value = 1000; pwm_value > 0; pwm_value -= 5) { __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, pwm_value); HAL_Delay(10); } }

呼吸灯的效果实测非常稳定，亮度变化很顺滑，没有跳变。这个过程中我最大的体感是，PWM频率不能太低，低于100Hz就会看到明显的频闪，适合灯光控制的频率一般要在1kHz以上；占空比变化速率也别太快，每次调整之间留个10ms左右，人眼看起来才是平滑呼吸而不是闪动。

3.5 I2C读取传感器：从时序到数据校验

I2C是这些外设里最接近“真实项目”的一项，因为你要面对的不是单纯读一个寄存器，而是按照芯片手册的时序要求，先发地址、再读数据、再校验。L562 DK板载温湿度传感器，I2C总线上还有别的器件，所以地址不能搞错。

配置CubeMX时，将对应I2C外设打开，速度选100kHz标准模式，引脚自动分配。生成代码后，用HAL_I2C_Mem_Read可以直接读取传感器寄存器：

uint8_t reg_addr = 0x00; uint8_t buf[2] = {0}; HAL_I2C_Mem_Read(&hi2c1, (I2C_ADDR << 1), reg_addr, 1, buf, 2, 100);

这里的I2C_ADDR需要根据板子原理图确定，高位地址要对齐。第一次读取时我拿到一堆0xFF，后来发现是传感器在上电后需要一小段稳定时间，代码里加了一个50ms的延时再读，数据就正常了。这类问题在真实项目里太常见了，很多外设芯片上电后不能立刻响应，手册里通常会写“Reset delay”或者“Startup time”，必须先查再定延时。

I2C总线调试时，我习惯用逻辑分析仪挂在SDA和SCL上，能直观看到起始条件、地址方向位、数据位、ACK/NACK和停止条件。有一次数据一直读不对，看时序才发现地址方向位写错了，读操作时最低位应该是1，代码里没正确移位，导致从机不回应。这个经验分享给所有做I2C的人：时序不匹配时，先别怀疑芯片，第一件事是抓波形。

4. 常见问题与排查技巧实录

4.1 典型问题速查表

这次试用下来，我把遇到的问题和身边几个朋友问过的问题汇总成一张速查表，按“现象—原因—解决”三段式整理，遇到相同症状的直接对号入座。

4.2 我踩过的几个隐藏很深的坑

先说一个和本次主题直接相关的：L5的TrustZone边界。我在调试某个Demo时，为了让某外设能同时被安全和非安全代码访问，一开始没把外设的访问权限开放给非安全世界，结果非安全程序一访问这个外设就hard fault，直接进Error_Handler。当时排查了很久，最后才意识到是Secure/Non-Secure的分区问题。基础外设体验阶段我用Non-secure工程完全绕开了这个坑，但如果你在半路切换到TrustZone工程，一定记得检查外设的NSB非安全位设置。

第二个坑是工程之间的代码复制问题。有一段时间我习惯把CubeIDE项目里调好的驱动函数复制到另一个Keil工程里用，结果编译直接报错，原因是Keil默认会启用MicroLib，而CubeIDE的HAL库配置里printf重定向方式完全不同。这类工具链差异问题，表面上像代码问题，实际是工程模板差异，排查时可以看看编译器的链接选项和标准库设置。

第三个隐藏坑在低功耗测试里。基础外设都跑通后，我顺手想把L562 DK的功耗基线测一测，结果发现电流怎么都降不下去。后来一顿查，发现默认例程里调试器接口SWO还开着，再加上所有GPIO都处于浮空输入状态，这些漏电流加起来比MCU待机电流还大。做低功耗测量前，把所有外设时钟关掉、GPIO设置为模拟或固定电平、关闭调试接口，电流数据才有参考意义。

4.3 一种更高效的调试思路

这次基础外设体验，我最大收获不只是跑通了某个外设，而是形成了一套适合自己的调试习惯。第一，调试口优先级最高，先把UART打通，之后所有模块的状态都能通过串口观察到，逻辑分析仪只需要在协议调试时才用。第二，每次只改一个变量，比如调PWM频率时只改PSC，调完之后确认效果再改ARR，避免多个参数一起动导致无法判断是谁的问题。第三，多用CubeMX生成代码而不是手写，手写外设初始化在L5这种带安全架构的芯片上更容易埋坑。

另外想推荐一个被低估的排查工具：简单的万用表。很多“外设不工作”的问题，其实量一下引脚电平就能定位。比如LED不亮，先量MCU引脚有没有输出高电平，有电平再查LED通路，没有电平就查MCU配置。用测量数据做判断，比猜代码日志可靠得多。

跑完这一轮基础外设之后，我重新审视了这块板子。原先担心L5因为TrustZone会把外围驱动搞复杂，实际用下来，外设体验和传统STM32基本一致，真正不同的还是在安全框架。所以如果你手头也有一块L562 DK，我的建议是：先抛开TrustZone，把GPIO、UART、ADC、PWM、I2C都过一遍。当你对板子整体有了手感，再抬头看安全分区那套机制，就不会一头雾水了。