STM32 FOC调试记录：从串口无数据到电机闭环

最近在学习无刷电机的FOC控制硬件平台是STM32F103C8T6MT6701磁编码器SPI接口三相全桥驱动双ADC注入组采样电流上位机用VOFA看波形。程序架构参考了一个开源例程ADC中断里执行FOC核心算法Clarke、Park、PID、SVPWM主循环只做printf和LED闪烁。按照例程移植完之后遇到了两个问题在这里记录一下排查过程。问题一串口发不出数据现象程序烧录后LED正常闪烁说明主循环在跑。但VOFA接收区没有任何数据。试了printf和直接调用HAL_UART_Transmit都收不到。先检查了软件层面fputc函数已重定向到USART2Keil里Use MicroLIB已勾选波特率115200COM口选的COM3硬件TX/RX没接反GND也共地了这些看起来都没问题。然后我把while(1)里改成只发一句最裸的测试HAL_UART_Transmit(huart2, (uint8_t*)HELLO\r\n, 7, 100);HAL_Delay(500);结果还是收不到。我做了什么测试把商家提供的能正常运行的例程和自己的工程做了逐文件对比usart.c里的MX_USART2_UART_Init函数——配置完全一样main.c里的SystemClock_Config——看起来也一样但仔细看SystemClock_Config的最后一行PeriphClkInit.AdcClockSelection RCC_ADCPCLK2_DIV2例程里是RCC_ADCPCLK2_DIV6。打开CubeMX的Clock Configuration看了一下ADC预分频选的是/2ADC时钟显示36MHz而且是红色的查到的资料翻STM32F103的数据手册ADC时钟的最大值是14MHz。36MHz超了2.5倍还多。根因ADC时钟超频导致外设时序紊乱USART2的发送被干扰了。解决在CubeMX里把ADC Prescaler从/2改成/6ADC时钟变成12MHz。重新生成代码编译烧录串口立刻正常了。小结CubeMX里红色的配置项不能忽略它是在提示你配置不合法。ADC超频这种问题表面上看和串口无关但实际上会影响整个芯片的外设时序。问题二程序卡死电机发现象串口通了之后把电流模式加进while(1)结果程序卡在这行之后motor_control_context.type control_type_torque;后面的printf不打印了。同时电机开始发烫——PWM还在输出但FOC中断似乎没有更新占空比。我做了什么测试在case control_type_torque:前后加printfcase control_type_torque:printf(T-start\r\n);lib_torque_control(motor_control_context.torque_norm_d, motor_control_context.torque_norm_q);printf(T-end\r\n);break;结果T-start打印了T-end没打印。说明卡在lib_torque_control里。继续往里加void lib_torque_control(float torque_norm_d, float torque_norm_q){printf(L1\r\n);float d torque_d_loop(torque_norm_d);printf(L2\r\n);float q torque_q_loop(torque_norm_q);printf(L3\r\n);foc_forward(d, q, rotor_logic_angle);printf(L4\r\n);}结果打印了L1、L2、L3L4没打印。说明卡在foc_forward。再往里void foc_forward(float d, float q, float rotor_rad){printf(F1\r\n);float d_u 0, d_v 0, d_w 0;svpwm(rotor_rad, d, q, d_u, d_v, d_w);printf(F2\r\n);set_pwm_duty(d_u, d_v, d_w);printf(F3\r\n);}结果打印了4个F1进入函数、三个变量初始化、svpwm完成第5个F1set_pwm_duty之后没打印。卡在set_pwm_duty函数里。查到的资料打开foc.c发现里面有一个weak版本的set_pwm_dutyvoid set_pwm_duty(float d_u, float d_v, float d_w) __attribute__((weak));void set_pwm_duty(float d_u, float d_v, float d_w){while (1);}而我的main.c里也有一个同名的set_pwm_duty是真正写寄存器的版本。我查了一下__attribute__((weak))的机制它表示这是一个“弱符号”如果链接时发现别处有强符号普通函数就用强符号。如果没有才用这个弱符号。按理说我的main.c里有强符号链接器应该用main.c的版本。但实际上链接器选了foc.c里的weak版本导致程序卡在while(1)。关于weak我的理解作者在foc.c里放一个weak版本的set_pwm_duty我理解是为了解耦foc.c只负责FOC的数学计算不应该关心底层硬件是哪个芯片、哪个定时器。它只需要知道调用set_pwm_duty就能输出PWM就够了。所以foc.c里放一个weak版本的占位函数如果你的工程里有实现就用你的如果没有实现就执行这个占位函数。占位函数写成while(1);是故意的如果忘了实现底层驱动程序会卡死在这里让你立刻发现。** 如果占位函数是空的程序会静默地不输出PWM电机不转但你不知道是哪里出了问题更难查。这个设计思路是对的但在我这里翻车了——链接器选了weak版本而不是强符号。我查了一些资料可能和链接顺序、编译器的weak符号处理有关。删掉foc.c里的weak函数定义只保留一行声明void set_pwm_duty(float d_u, float d_v, float d_w);这样链接器只能去main.c里找实现没有选择余地。重新编译烧录程序不再卡死。小结weak符号的机制虽然灵活但调试时容易让人抓狂——链接器选错版本时不会报错运行时才暴露问题。如果是我自己写代码我会在foc.c里只放声明不放定义让链接器在编译期就报未定义符号第一时间暴露问题。总结这两个问题花了我不少时间记录几点心得1. CubeMX里红色的配置项必须处理。ADC时钟超频这种问题表面看和串口无关实际上会影响整个系统2. 调试时按信号链逐层隔离。从主循环→中断→算法函数→底层驱动一层层加printf定位比瞎猜有效得多。3. weak符号有它的设计意图但调试时要小心。链接器的行为依赖于工具链跨编译器可能不一致。更安全的做法是只声明不定义。后续会继续记录PID调参和VOFA在线整定的过程。