初学STM32，我遇到的那些问题

初学STM32标准库时，我遇到过几个“代码和接线都对，但硬件死活没反应”的怪问题。排查后发现，它们大多不是逻辑错误，而是藏在硬件接触、配置细节里的坑。本文记录了其中几个典型案例和我的解决过程

1. 电路导通异常

明明代码和电路连接跟教程里的一模一样，但是编译下载完后硬件那边毫无反应，我怀疑电路某些地方接触不良，于是把最小系统板用力往下摁，发现预期现象出现了，类似的，LED长脚和短脚，杜邦线等也可能出现接触不良的情况。
原理：硬件存在虚接，造成间歇性通路断开

2. 复位后USB无法自动重连

点亮一个LED，代码编译和下载都没问题，但是发现重新拔插ST-Link，灯才能亮，通过ai的解释，我知道了是我Keil设置的问题，为了方便观察现象，我把设置调了调，以后就不用频繁拔插USB，下载程序直接能观察到现象了




原理：复位模式不匹配，芯片不会自动加载 Flash 程序

3. 调用函数时代码写错

将点亮LED的功能封装成LED_ON()函数，从LED.h文件中复制粘贴到main.c文件中调用，没有对.h文件中的函数声明语句进行修改，直接编译下载，编译器未报错，但是LED不亮，起初很自信地认为代码没问题，是不是电路连接出了问题？仔细检查一番问题出在代码上。这里我想说，编译器不报错不代表代码是对的，写代码时一定要细致。

//错误调用voidLED1_ON(void);//正确调用LED1_ON();

原理：声明语法错误不会触发编译告警，但函数无法正常链接

4. 头文件未导入

在按键控制LED的程序中，使用了uint8_t类型，但是报错了

这表明编译器“不认识”uint8_t，需要导入头文件，这种情况在C语言的学习中也遇到过，有一定经验的话可以很快找到解决方案
这里给出两种方案：
①导入stdint.h头文件。uint8_t不是C语言原生类型，这个类型定义在stdint.h里

#include<stdint.h>

②若不清楚uint8_t类型具体定义在哪个头文件，也可直接导入芯片头文件。原因：#include “stm32f10x.h” → 内部链式引入了 core_cm3.h → core_cm3.h 里面自带 #include <stdint.h>

原理：uint8_t 不是 C 原生类型，在标准头文件定义

5. 时钟开启端口和GPIO初始化端口不匹配

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA,ENABLE);//开启GPIOA时钟GPIO_Init(GPIOB,&GPIO_InitStructure);//却初始化GPIOB引脚

复制粘贴也要检查啊！
原理：外设必须开启对应端口时钟才能供电工作

持续更新中…