双STM32协同设计实战：通信、电源与调试全解析

1. 为什么一块板上要塞两颗STM32这事的真实动机先讲个场景。上个月我在调一块带无刷电机驱动的传感器采集板主控用的是一颗STM32F103跑着三路PID闭环。电机的PWM一开电流采样中断偶尔会抖本来2kHz的采样率硬被挤掉几百赫兹。更要命的是附近还有一个RS485总线要实时响应上位机指令这边一忙那边就超时。后来我干脆加了第二颗STM32一颗专门管电机和电流环另一颗专管通信和采集问题立刻消失。一块PCB上放两颗STM32听上去有点大炮打蚊子但很多实际项目里这是性价比极高的解法。它背后真正的需求通常是这几类实时性硬隔离电机控制、开关电源这类对中断响应时间有硬要求的任务和需要跑协议栈、人机交互的任务放在同一颗MCU上调度冲突只是时间问题。模拟采集与数字通信的地噪声隔离高精度ADC采样时数字总线翻转带来的电源毛刺会直接耦合进模拟信号。两颗芯片分别供电中间加磁珠或者LDO隔开实测可以把采样噪声从几个mV压到几百µV。外设资源不够有些封装只有3个UART同时要挂GPS、RS485、蓝牙和调试口怎么排都差一口。两颗芯片等于把可用外设翻倍而且每颗芯片都能工作在比较低的时钟频率降低EMI。安全冗余虽然不是双MCU锁步那种等级但两颗芯片互相做心跳监测至少一颗死掉时另一颗能接管关键IO对非安全认证但要求高可靠的产品来说简单实用。如果你遇到的是这类场景那这篇文章就是为你准备的。我会从通信方案选型、电源和时钟架构、启动顺序设计、调试下载坑点、PCB布局EMC这几个维度把双STM32方案里真正值得注意的地方全部过一遍包括我在实际测试中翻车后总结的经验。先说结论双STM32设计成败的关键八成不取决于软件而取决于三个硬件层面的决定——通信接口怎么选、复位时钟怎么分配、调试和烧录口怎么共存。下面一个个展开。2. 双MCU之间怎么通信UART、SPI、I2C的实测对比与选型逻辑两颗芯片放一块板上通信方式比两个独立模块之间通信的选择余地大得多。因为距离近、环境可控你可以用并行总线、SPI、UART、I2C甚至直接映射内存地址。但每种方案的性格差别很大不是随便选一个都行。2.1 UART最稳妥但别忽略波特率误差叠加UART是绝大多数人的第一反应——简单、现成、调试方便。但它有两个容易被忽略的问题。一个是波特率误差。两颗芯片的HSE晶振或内部RC都有自己的精度F103这类芯片用内部RC时误差可以到1%~2%当双方波特率误差方向相反时UART的采样窗口会被压缩。常规做法是两边都用同一个外部晶振一根晶振输出接两个芯片的OSC_IN或者通信双方都改用内部高速时钟但进行软件校准。我实测过一颗用内部RC、一颗用8M外部晶振的板子波特率115200时偶发乱码改成双芯片共用同一个外部时钟源之后就干净了。如果没法共用时钟建议把波特率降到38400以下并用奇偶校验位增加容错。另一个是中断延迟。UART收发是字节级的9600波特率下每字节差不多1ms如果主循环里同时处理电机控制和通信解析很容易丢字节。双MCU方案里我习惯给两边的UART都配DMA并用空闲中断来判断一帧数据结束。STM32的HAL库对空闲中断支持得不错开启HAL_UARTEx_ReceiveToIdle_DMA之后CPU基本不需要逐字节介入。2.2 SPI高速大数据量场景的主力如果两边的数据量上来了比如一个芯片采集音频、另一个做FFT运算UART就不够看了。STM32的SPI在36MHz或更高时钟下轻松跑满几十Mbps而且全双工一次传输同时收发数据非常适合握手协议。但SPI做双机通信有个很实际的坑片选和主从关系。如果你设置一颗为主、一颗为从从机侧的程序必须准备好随时响应否则主机的数据就丢。我的做法是双MCU之间不使用标准SPI的主从CS机制而是把CS引脚当普通GPIO用发送前拉低、结束后拉高从机侧用外部中断检测CS下降沿再开始接收。这样从机无需一直轮询。还有一个建议SPI线上的信号完整性在板内短距离小于10cm通常没问题但如果走线经过了连接器或者长排线建议把时钟降到10MHz以下必要时串33Ω或47Ω电阻抑制过冲。这部分后面EMC章节会一起说。2.3 I2C能不用尽量别用尤其跨芯片I2C虽然只需两根线但跨芯片通信时问题很多。首先是地址冲突——两颗STM32的I2C外设地址都是可配的但如果你还挂了其他I2C设备地址空间很快就紧张了。其次是I2C是开漏结构需要上拉电阻板内短距离还好一旦线长一点上升沿变慢速度只能降到100kHz甚至更低。更麻烦的是I2C的阻塞问题。从机拉低时钟线进行流控的时候如果从机程序卡死总线会一直锁住。很多工程师在双MCU通信上栽跟头就是I2C总线被拉死之后查了半天不知道是哪边的问题。所以我的结论很直接板内双MCU通信I2C只适合低速状态信息传输比如传递温度和电压阈值这类低频数据不适合做主数据通路。2.4 并行总线与共享内存什么时候值得上两颗STM32之间如果数据量达到几百KB/s以上SPI也不太够了这时可以用FSMC或FMC并行总线把从机映射到主机的外部存储区域。F103系列带FSMC的型号F4和H7系列带FMC理论上可以把另一颗STM32当SRAM来读写速度非常快。但并行总线会占掉大量GPIOPCB布线也变复杂。除非你的场景确实是高吞吐比如双芯片协同做软件无线电或者图像处理否则我不建议普通项目上并行总线。做了并行总线之后还需要在固件里定义一套共享内存结构体包含数据序号、长度、校验和防止读到半写的帧。2.5 CAN工业场景下的隐藏选项如果你已经在用CAN总线再多接一个STM32的成本几乎为零。CAN的仲裁机制天然适合多节点而且抗干扰能力强。我做过的一块板卡就是一颗F103做伺服驱动另一颗做IO扩展和状态监控两者通过CAN通信波特率1Mbps一条双绞线搞定。CAN的缺点是协议栈稍微复杂但只要用HAL库的CAN外设加FIFO比你想的简单。下面是我总结的选型参考表通信方式典型速率引脚占用抗干扰能力协议复杂度适合场景UART≤1.5Mbps2或4含流控一般低低速控制、调试日志、状态同步SPI≤36Mbps3~4较好中大数据量采集传输、双核分工I2C≤400kHz2较差低低速低频状态信息CAN≤1Mbps2强中工业现场、多节点组网FMC并行数十MB/s20一般需注意总线噪声高高吞吐场景我在项目里的默认组合是一颗为主控Master一颗为执行/采集从机Slave通信主链路走SPI状态走UART心跳和错误上报走CAN如果系统里本来就有CAN。SPI三根线加一根CS加一根中断线从机有新数据时拉高通知主机这个组合实测最稳。3. 电源、时钟、复位、调试口的四大共地设计两块芯片放一块板上硬件上的麻烦不是多一个芯片而是多一个芯片之后那些本来只需要管一次的东西都要管两遍。电源、时钟、复位、调试口每一项都值得单独过一遍。3.1 电源架构独立LDO还是共用一路电源这是我的血泪教训。第一次做双STM32板子时为了省事两颗芯片的VDD直接并到同一个3.3V电源轨上。结果电机一启动电源轨瞬间跌了200mV通信SPI偶发CRC错误查了整整两天最后用示波器看到电源纹波和SPI错误的对应关系才破案。正确的做法分两档。如果两颗芯片工作性质差别不大都用同一路3.3V问题不大但前提是每个芯片的VDD引脚都放100nF陶瓷电容并且靠近MCU侧再加一个4.7µF~10µF的钽电容或MLCC做中频储能。如果其中一颗芯片带电机、加热丝、继电器这类负载另一颗主要做精密采集那必须分两路供电——一路给执行芯片一路给采集芯片两路之间用磁珠或小阻值电阻做单点连接模拟地和数字地在MCU附近单点汇合。实测数据共用电源轨时ADC采样值跳动范围大约±8LSB12位模式下分离供电之后降到±1~2LSB。对采集类应用这个差距是决定性的。3.2 时钟设计共享晶振还是各自独立双STM32的时钟方案有几种选择各有优劣各自独立晶振电路最简单每颗芯片一个8MHz晶振互不干扰。缺点是一旦需要对时间同步敏感的通信比如PWM同步、高速SPI两边时钟频率的微小差异会累积成相位漂移。单晶振双负载一个8MHz晶振输出接到两颗芯片的OSC_INOSC_OUT空接。这个方法只要晶振驱动能力够就行F103系列通常可以。缺点是噪声会同时灌给两颗芯片晶振附近要预留足够的铺地。主机输出MCO给从机主芯片的MCO引脚输出8MHz或更高频率接到从机OSC_IN从机不用自己的晶振。这样两边时钟完全同源SPI和USB的同步最稳。缺点是如果主芯片死了从机也失去时钟整体可靠性下降。我的建议如果你的双MCU之间经常要进行时间戳对齐或者同步采样直接上第三种方案如果只是各自干各自的活偶尔传个状态选第一种最省心。注意从机用外部时钟输入时OSC_OUT引脚要悬空并且RCC配置要选外部时钟源而不是外部晶振别选错。3.3 复位电路RC值怎么选才不互相干扰复位电路看似简单双MCU时却有个隐蔽问题。如果两颗芯片用同一个RC复位电路上电时电源爬升过程会让复位引脚电位缓慢上升可能导致某颗芯片在电源还不稳定时就开始运行另一颗还在复位状态。我的做法是两颗芯片各用独立的复位电路RC时间常数取10ms~100ms。比如100kΩ电阻配100nF电容时间常数约10ms配合STM32的上电复位机制足够。使用外部复位芯片的话选择带手动复位输入和开漏输出的型号可以做到一个按键同时复位两颗芯片。复位芯片的输出接两颗芯片NRST引脚之前最好各串一个100Ω电阻防止一颗芯片内部下拉时把另一颗的复位引脚也拉低。另外STM32的NRST引脚内部有弱上拉如果你在NRST上外接电容做延时电容值不要太大否则复位释放沿变缓芯片可能进入异常状态。我见过有人放大10µF电容在NRST上结果芯片一直复位不过去上电后就是起不来。3.4 调试口JTAG/SWD引脚冲突怎么破这是很多人第一次做双STM32最崩溃的地方。每颗STM32的SWDIO和SWCLK引脚在F103上是PA13和PA14F4也是类似位置。两颗芯片都用SWD时如果你把两颗芯片的SWDIO直接并到一起ST-Link会不知道跟谁说话甚至因为引脚驱动力度不同导致通信失败。解决方案有三个按推荐度排序分时复用J-Link/ST-Link接口板上放一个2x5的SWD排针中间串0Ω电阻或跳线。调试芯片A时焊上A路的电阻调试芯片B时焊上B路的。缺点是调试切换麻烦但最可靠适合调试阶段。用SWD接口的断开功能有些调试器支持target interface切换但物理上你还是需要把两根线分别连到两个芯片的SWD引脚中间加跳线帽或拨码开关。这个方案适合开发板量产板不建议因为拨码开关容易误触。两块芯片用不同调试口F103系列可以把SWD映射到其他引脚但需要早期在代码里配置AFIO重映射而且重映射后调试器第一次连接会麻烦。另一个思路是芯片A用SWD芯片B用串口ISP或自定义Bootloader升级用串口打印调试信息代替在线调试。这个在量产阶段反而最实用因为芯片B的固件已经稳定不需要频繁断点单步。如果你是做量产产品我建议最终固件里把两颗芯片的调试接口都禁用省下的引脚拿去干正事。注意F103禁用JTAG时需要调用GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)否则PA13~PA15和PB3、PB4继续被调试器占用。4. 启动顺序与双核握手防止两棵死锁的一整套逻辑两颗芯片上电后谁先跑没关系但如果互相依赖对方的初始化数据就很容易出现你等我、我等你的死锁。这个问题的本质是从芯片的角度看它不知道对方此刻处于什么状态——是还在复位、已经在运行、还是卡死了。所以必须建立一套显式的启动握手协议。4.1 启动顺序设计主从角色要在硬件上确定先确定角色。我的习惯是主机Master由电源直接上电从机Slave的电源由主机的GPIO控制一个P沟道MOSFET或负载开关。这样主机软件可以在完全准备好后再给从机供电从机看到的电源是干净利落的上升沿不会因为电源爬升缓慢而反复复位。如果两颗芯片同时上电也没有关系但要确保复位时序有足够的错开。上文说的各自独立RC复位电路就保证了这一点。更好的做法是用一颗电源监控芯片比如TPS3823这类它的复位输出有固定的延时可以保证输出到两颗芯片NRST的时间差至少有200ms。硬件准备好之后从机Boot0引脚要拉低让从机从Flash启动。有些人会把Boot0悬空这在单芯片时可能没问题但双芯片时悬空引脚容易受旁边走线干扰导致从机偶尔进入Bootloader模式程序跑不起来。量产的板子Boot0和Boot1都通过10kΩ电阻下拉到地不要偷懒。4.2 握手协议别用延时等对方这种野路子有人在从机初始化时直接HAL_Delay(2000)以为等主机准备好就行。这在单板上可能碰巧能用但只要主机初始化稍微慢一点或者中间某个步骤卡住从机就在那儿干等然后两边都以为对方有问题整个系统启动时间莫名其妙多出几秒。靠谱的做法是定义应用层握手协议。我用的是这个结构从机上电后立即拉高READY引脚一个GPIO主机用外部中断检测告诉主机我从机已经启动进入等待命令状态。主机检测到READY后发送SYNC帧比如0xAA 0x55 0x01 0x02 0x03 0x04 0x04最后一个字节是校验和。从机收到SYNC帧后回复ACK帧0x55 0xAA 0x81 0x81同时进入运行状态。主机收到ACK后才允许发送业务数据。如果主机在500ms内没收到ACK主动重启从机电源或拉低从机NRST引脚。这套协议的精髓是谁超时谁负责。主机负责监控超时并决定是否重启从机从机不需要关心主机状态它只要在收到SYNC前不断重发READY信号或者保持等待即可。这个设计避免了两边同时等对方的经典死锁。时序参数上SYNC重发间隔取100ms超时阈值取500ms比较合适。太短容易在上电瞬间误判太长会让系统启动显得迟钝。4.3 双看门狗独立看门狗窗口看门狗怎么分配双MCU系统里看门狗策略也需要区分。我的分配方式是主机启用独立看门狗IWDG超时时间约1秒在主循环里喂狗。如果主机卡死在某个中断里IWDG会把它拉回来同时从机通过心跳超时检测到主机异常接管关键IO。从机启用窗口看门狗WWDG窗口期设置得比较窄确保从机主循环严格按周期执行。如果从机中断风暴导致主循环被挤掉WWDG会比IWDG更快地发现问题。另外两颗芯片之间最好有硬件心跳线主机每100ms翻转某个GPIO电平从机用另一个GPIO检测这个翻转。如果从机在300ms内没看到电平变化就认为主机死机从机执行安全动作比如关闭电机驱动、拉高报警信号。这个心跳线用代码翻转GPIO即可不需要额外硬件但比纯粹的软件心跳靠通信触发更可靠因为它不经过协议栈。4.4 共享Flash和EEPROM的细节如果两颗芯片要共用外部SPI Flash或者板载EEPROM有一个陷阱叫双写覆盖。比如主机在地址0x00写系统参数从机在地址0x100写校准数据。如果两边共用SPI总线和片选但某一个芯片在写操作进行到一半时被另一个芯片打断比如SPI片选被意外拉低数据就会写坏。我的建议是共享存储必须加一把信号量锁。最简单的方式是用一个GPIO做硬件锁要写EEPROM之前先请求锁拉高/拉低某根线对方检测到后暂停自己的写操作写完释放。软件上再配合页写入缓冲和CRC校验基本就不会出现双写覆盖了。如果数据量不大其实更省心的方案是两颗芯片各自保留一段专属的存储区域不需要共享。主机用前1/2的Flash空间从机用后1/2中间留出隔离区域。这样两边各写各的完全不需要协作省掉通信协议和锁定的麻烦。5. 这块PCB的布局、布线与EMC双芯片不是画两遍那么简单双STM32的PCB设计最容易犯的错误是把单芯片的成熟布局复制两份然后拼在一起。这样出来的板子大概率在EMC测试时被搞得很惨。因为我实际调试中遇到的噪声、串扰、地弹问题绝大多数都出在两套系统共用一套地这个环节。5.1 分区布局数字区、模拟区、功率区要划清楚晶振的位置很关键两个晶振不能贴近放。8MHz晶振输出的是模拟小信号而SPI、UART这类数字信号翻转时会在参考地上激起噪声。如果晶振离数字走线太近时钟抖动会变大。我的经验是两个晶振至少相隔2cm以上并且远离开关节点电机驱动桥、DC-DC电感。如果板上同时有模拟采集和电机驱动布局上以功率区→中间隔离带→模拟区为基本顺序。主控芯片放在中间ADC输入和传感器接口放在一侧电机驱动放在另一侧。两个STM32分别承担不同任务时执行芯片贴近功率区采集芯片贴近模拟前端中间用铺地隔离不要用一根细线连接两边。5.2 电源和地星型接地不是玄学双芯片的电源和地规划单点汇聚是关键。最容易出现的问题是两颗芯片地通过各自的外设回路形成环流。最典型的表现是当芯片A的某个GPIO翻转驱动LED时芯片B的ADC采样值会跟着跳这就是共地阻抗耦合。解决方法是采用星型接地每颗芯片的地引脚先在芯片下方通过过孔汇聚到内层完整地平面然后从地平面的中心点通常是电源输入端单点引出不要再有多条地线在图间来回穿梭。不要用串联接地方式——芯片A的地返回电流流经芯片B的地引脚区域这是最糟糕的。对于ADC采样部分模拟地AGND和数字地DGND用0Ω电阻或磁珠单点连接这个点通常放在ADC芯片或MCU的AGND引脚附近。芯片内部模拟和数字部分已经做了隔离外部只需要保证回流路径干净即可。5.3 SPI走线高速信号别追求越短越好的唯一标准有人以为SPI走线越短越好这没错但不够。短是基础更重要的是回路面积要小。SPI的SCK、MOSI、MISO、CS四根线尽量在同一层走并且旁边有连续的地平面跟随。如果必须换层换层位置旁边要放地过孔保证返回电流可以平滑地跳层否则信号回路面积变大辐射噪声显著增加。时钟线尽量远离复位线和中断线。SCK 18MHz翻转的谐波很强如果跟从机的NRST引脚走线相距太近可能造成复位误触发。我有一块板子SPI时钟线从NRST边路过结果主机偶尔意外复位后来把线距拉开到3W规则线间距是线宽的3倍才解决。5.4 连接器和排针的引脚分配如果板子需要引出调试口或通信口连接器引脚分配时注意不要把两个芯片的SWD引脚放在同一个连接器的相邻脚位上否则调试时跳线帽戴错位置可能同时驱动两颗芯片的SWD引脚烧坏IO。一个更稳妥的做法是调试连接器上分配独立引脚给两套SWDJ-Link和ST-Link都不支持同时连两颗芯片所以板上留一个拨码开关或者0Ω电阻选择开关。量产板上直接把调试口改成2.54mm间距的测试点生产时用测试夹子批量烧录平时不需要预留连接器。6. 下载与调试的完整方案从单独烧写到量产批量烧录双芯片方案里下载调试是最能逼疯人的环节。因为两颗芯片固件不同一根ST-Link只能连着调试器连一颗另一颗完全看不到经常出现我改了芯片B的代码但忘了给芯片B烧录程序跑的还是旧的这种低级错误。6.1 开发阶段的接线方案开发阶段最省事的方式是板上保留两个SWD接口分别对应芯片A和芯片B。同时插两个ST-Link到电脑上一起烧写或者用STM32CubeProgrammer命令行一次烧两个hex都很方便。STM32CubeProgrammer支持-c portSWD modeUR和-w firmware.hex的参数写一个批处理脚本就可以一次调用两次命令分别烧两颗芯片。我自己的习惯是写个Makefile目标比如make flash-all里面依次执行STM32_Programmer_CLI -c portSWD modeUR resetHWrst -w build_master/master.hex STM32_Programmer_CLI -c portSWD modeUR resetHWrst -w build_slave/slave.hex如果你用STM32CubeIDE也可以右键项目名选Build Targets→Add新建一个target把两个项目的post-build命令都放在里面。这样每次改完代码一个快捷键就把两颗芯片都烧了不会漏。6.2 量产阶段的批量烧录和校验量产时两颗芯片如果都留SWD需要两个测试点测试架上一个双头探针同时接触两个SWDIO/SWCLK这是可行的因为量产时两颗芯片之间没有通信可以分别烧录。不过实际生产中更常见的做法是芯片A主控用SWD直接烧录因为主控固件更新频率高。芯片B从机固件放到主机固件的末尾做成镜像区。主机启动时检查从机固件版本如果版本不一致就通过UART或SPI把新固件推给从机从机收到后写入自己的Flash再跳转运行。这就是IAPIn-Application Programming方案。IAP方案的优点是产线上只需要一个SWD口烧录主机从机由主机完成首次烧录或升级省掉一个探针位还方便以后现场远程升级。缺点是Bootloader代码要提前烧进从机而且从机的Bootloader要做好Flash写入保护防止应用程序把Bootloader覆盖掉。关于烧录保护STM32的RDPRead Protection等级建议设成Level 1防止固件被读出来同时允许后续升级。如果把RDP设成Level 2芯片就永久锁死了现场升级就彻底不可能量产前想清楚。6.3 调试会话里最容易踩的坑两个SWD调试器冲突有时你想用两个调试器同时调试两颗芯片这在软件上可以但有几个坑要避免电源冲突两个ST-Link如果都从目标板取电会同时给板上3.3V供电电流方向不好说有时会把某个调试器保护触发。让其中一个调试器不连目标板电源把ST-Link的3.3V脚断开或选不供电模式只连SWDIO/SWCLK/GND/Reset。复位冲突两个调试器同时接管复位引脚如果一方在复位引脚上做电平控制另一方也会受影响。有些调试器通过NRST做硬件复位两个调试器的复位信号会互相打架。建议调试时只让主调试器连接NRST从机用软件复位或者只使用SWD通信不用硬件复位。断电顺序同时调试两颗芯片时拔掉一个调试器后发现另一个芯片程序也乱了这是供电瞬间跌落导致的。每次拔插调试器前先断开调试会话再拔线顺序反了容易导致芯片进入异常状态有时候得重新上电才能恢复。6.4 日志与状态监控两块芯片怎么打日志双芯片有一个天然优势就是可以分开打日志。比如主机把日志发到串口1接USB转串口从机把日志发到串口2接另一个USB转串口然后开两个串口助手同时看。两个人各开一个窗口效率极高比单芯片上靠软件区分任务日志方便多了。如果只有一个调试串口可以用时间戳前缀区分来源比如主机日志前缀[MASTER]从机日志前缀[SLAVE]都发到同一个串口上。但要小心两个串口的发送时间重叠一个芯片发到一半另一个芯片也发了造成串口数据交错乱码。这种情况下建议两颗芯片都先送入自己的Ring Buffer再由一个专门的转发任务统一从串口输出避免直接并发写UART。7. 写在最后双STM32方案的边界与几个亲测有效的小建议最后说点实在的。双STM32不是性能问题的万能药。如果你是因为单颗芯片算力不够而想加一颗那大概率方向错了——这种情况应该换更高性能的型号比如STM32H7或直接用带双核的芯片STM32H745就是双核Cortex-M7M4。双STM32适合的是任务必须物理隔离的场景不管是实时性隔离、电源域隔离还是为了降低单点故障率。如果你已经决定用双STM32方案我实际用下来觉得最有价值的几点通信协议一定要定义好版本号和校验和哪怕只是主从两个节点。因为两颗芯片的固件有可能分开升级升级节奏不一致时旧协议和新协议直接不兼容。我吃过这个亏主机升级后从机没升级主从无法通信现场查了半天才发现是协议版本不一致。从机最好支持烧录失败回退机制也就是Bootloader里保留固件B的副本升级失败时还能从旧版启动。这个机制看着像服务器才需要的东西但实际现场的尴尬场景太多了值得预留。PCB打样回来不要急着焊两颗芯片先只焊主机把主机所有外设电源、时钟、SWD、串口全部调通再焊从机。这次序能帮你把问题隔离在单芯片侧不会出现两颗芯片都有问题不知道先查谁的局面。散热方面如果两颗STM32都跑在72MHz以上且板上还有功率器件尽量让两颗芯片间距远一点不要紧贴着放避免热量集中。更关键的是两颗芯片的电源引脚旁边都要留足过孔电源回路电感直接影响高温下电压跌落的风险。以上就是我在双STM32方案上的完整实践经验。从通信选型、电源和时钟架构、启动握手、PCB布局到烧录调试每一环都踩过坑、填过坑。如果你按这个思路走一遍应该能比我自己第一次做双芯片时省下至少两周的调试时间。