手上刚好有一块Nucleo 板，测试了一下PB1口，上拉10K电阻，设置成输出，断开MCU VDD后，MCUVDD几乎为零，没有发现很高的电压。 楼主可以看看周边电路是否有影响。按说10K电阻，即使有灌电流，也很小，不大可能有近2v的电压。
在LD 文件中添加一段 .noinit (NOLOAD) : { . = ALIGN(4); *(.noinit) * (.noinit*) } > RAM #define __no_init __attribute__((section(".noinit"))) __no_init int keep_data; // 和 IAR 一模一样！
STM32F1系列属于Cortex-M3内核，没有硬件FPU及DSP模块，所有浮点运算都是软件模拟。 现在使用STM32进行开发，多使用cubeMx进行配置，在配置时在中间件那里选择X-CUBE_ALGOBUILD,并勾选DSP Library。创建工程时在middleware目录里就有了DSP库 文件。使用时Include arm_math.h，调用的函数都是arm_打头，比方： arm_mat_mult_f32(pSrcA, pSrcB, pDst) arm_mat_trans_f32(pSrc, pDst) arm_mat_inverse_f32(pSrc, pDst) arm_cfft_init_f32(&fft_inst, FFT_SIZE); arm_cmplx_mag_f32(input, mag, FFT_SIZE);
原来的软件可能是越来越庞大了，启动运行效率不高。 所以现在单独安装STM32CubeMx，配置好生成project， 再打开。 互相之间影响少。
[md]| # 【踩坑记录】STM32电机FOC驱动：MC Workbench 6.4.1生成代码参数配置错误导致死循环死机大家好，分享一个使用**MotorControl Workbench 6.4.1**生成STM32 FOC电机驱动代码时遇到的致命问题：因工具界面核心参数配置不匹配，导致代码时序计算溢出，最终触发死循环死机，给各位同好避个坑。一、问题现象基于MotorControl Workbench 6.4.1生成的FOC驱动代码，电机初始化阶段直接卡死。通过调试定位，程序陷入`r3_2_f4xx_pwm_curr_fdbk.c`文件的以下while循环无法退出：while ((TIMx->CNT) < (pHandle->pParams_str->Tw)){ /* wait for a maximum delay */}复制代码核心异常点：1. TIMx->CNT是16位PWM计数器，最大值约8400 ticks（由20kHz PWM频率 + 168MHz定时器时钟计算得出）；2. 工具生成的Tw参数值却为65503；3. 因8400永远小于65503，循环条件恒成立，程序彻底死锁。二、问题根因：界面参数配置不匹配 + 无符号数溢出本次问题的核心是**STMC Board Designer**两个关键配置页面的参数不兼容，以下是具体溯源和计算过程。1. 错误的界面配置参数（附截图）问题源于Phase Voltage Generation和Current Sensing两个页面的参数搭配错误，关键配置如下：Phase Voltage Generation页面：TNoise=50ns、Dead Time=300ns、驱动ATK_PD6010B+MOS管IRFS3607PBFCurrent Sensing页面：TRise_NS=120ns、ADC_SAMPLING_CYCLES=15、ADC_CLK=21MHz、高级定时器时钟=168MHz这些参数会被工具自动写入`power_stage_parameters.h`头文件：#define TRISE_NS 120#define TNOISE_NS 50#define HW_DEAD_TIME_NS 300#define ADV_TIM_CLK_MHz 168#define ADC_CLK_MHz 21#define ADC_SAMPLING_CYCLES 15复制代码2. 工具生成代码的时序计算过程MC Workbench自动生成的时序计算逻辑存在无符号数溢出风险，步骤如下：Step 1：计算TW_AFTER（有效采样起始点）#define TW_AFTER ((uint16_t)(((HW_DEAD_TIME_NS + TRISE_NS) * ADV_TIM_CLK_MHz) / 1000UL))// 代入值：(300 + 120) * 168 / 1000 = 70.56 → 取整71 ticks复制代码Step 2：计算SAMPLING_TIME（ADC采样所需时钟）#define SAMPLING_TIME ((ADC_SAMPLING_CYCLES * ADV_TIM_CLK_MHz) / ADC_CLK_MHz)// 代入值：15 * 168 / 21 = 120 ticks复制代码Step 3：计算MAX_TWAIT (Tw)（采样等待窗口，核心溢出点）#define MAX_TWAIT ((uint16_t)((TW_AFTER - SAMPLING_TIME) / 2))// 代入值：(71 - 120) / 2 = -24.5 → 取整-24// 关键错误：uint16_t无符号类型将-24溢出为65512！复制代码3. 死循环触发逻辑- 工具生成的Tw=65512（溢出后的极大值）；- TIMx->CNT最大值仅8400 ticks（168e6 / 20e3 = 8400）；- 循环条件`TIMx->CNT < 65512`永远为真，程序卡死。三、根本原因总结界面参数不匹配：配置的TW_AFTER(71) < SAMPLING_TIME(120)，导致减法结果为负；代码类型缺陷：工具生成代码使用uint16_t存储计算结果，负数直接溢出为大正数；工具无校验：MC Workbench未对时序参数的合法性做前置检查，放任非法值生成。四、解决思路与方法针对该问题，有3种可落地的解决方式，优先推荐第一种：1. 调整MC Workbench界面参数（最直接） - 方案A：在Current Sensing页减小ADC_SAMPLING_CYCLES，如改为3，此时SAMPLING_TIME=24 ticks，71>24，计算结果为正； - 方案B：在Phase Voltage Generation页适当增大Dead Time，提高TW_AFTER值； - 核心原则：确保TW_AFTER > SAMPLING_TIME。2. 修复工具生成的代码逻辑 - 中间计算步骤改用int32_t有符号类型； - 添加保护判断，若TW_AFTER
可以和以太网采用类似的方案，分组嘛，不过由于can总线是竞争型的网络，所以你需要把分组进行编号，作为报文内容传递，在接收端重建，当然这个时候可以接收端的can应该配置rx fifo而不是rx buffer，如果cpu处理足够快就不用太大的深度
微信公众号
手机版
