根据现在CubeMX的生成代码，感觉这个问题是一个DMAMUX级联的问题：首先使用DMA_REQUEST_TIM1_CH1请求生成HAL_DMAMUX1_SYNC_DMAMUX1_CH0_EVT（DMA1_Stream0），然后HAL_DMAMUX1_SYNC_DMAMUX1_CH0_EVT同步触发hdma_spi2_tx的发送DMA（DMA1_Stream2），问题的关键在于不知道如何建立DMA_REQUEST_TIM1_CH1和HAL_DMAMUX1_SYNC_DMAMUX1_CH0_EVT的联系
STM32H7 + LWIP 能收包却 ping 超时一站式排查表 症状：网口灯闪、MCU 能进接收中断、Wireshark 能看到 ICMP Echo-reply，但主机依旧“Request timeout”。 1. 校验和（Checksum）→ 90 % 踩坑点 表格复制 现象 Wireshark 展开 ICMP 协议树，Checksum = 0x0000 或非法值 根因 MAC 硬件自动清零 + lwIP 未同步使能 HW checksum offload 验证 抓包看 ICMP Checksum 字段 修复 1. 使能 MAC 发送硬件校验和2. 让 lwIP 把校验工作交给硬件 c复制 /* 1. 在 ETH 初始化处 */ heth.Init.TxConfig = ETH_TXCONFIG_CHECKSUMOFFLOAD; // H7 寄存器位 /* 2. 在 lwipopts.h */ #define CHECKSUM_BY_HARDWARE 1 #define CHECKSUM_GEN_ICMP 1 #define CHECKSUM_CHECK_ICMP 1 老版本 icmp.c 需手动把 iecho->chksum = 0; 保留，防止软件提前填充。 2. ARP / IP 冲突 表格复制 现象 第一次 1-2 个包能通，之后全部超时 验证 arp -a 看目标 IP 对应的 MAC 是否等于板子 MAC 解决 arp -d 清缓存；给板子分配唯一 IP；必要时发 Gratuitous ARP 3. Cache 污染（D-Cache 与 DMA 不一致） 表格复制 现象 大包 1500 B 必现超时；开-O2 优化后必现 验证 把待发缓冲区打印出来与 Wireshark 对比，内容不一致即命中 解决 方法 A：MPU 把描述符 & pbuf 区设为 Device/Strongly-ordered方法 B：在发送/接收处手动 Clean / Invalidate c复制 /* 发送前 */ SCB_CleanDCache_by_Addr((uint32_t *)p->payload, p->len); /* 接收后 */ SCB_InvalidateDCache_by_Addr((uint32_t *)p->payload, p->len); 4. pbuf 泄漏（PBUF_POOL 耗尽） 表格复制 现象 连续 ping 前 N 次 100 % 通，N == PBUF_POOL_SIZE 后永远超时 验证 memp_get_stats() 观察 PBUF_POOL 可用数每 ping 减 1 解决 恢复 icmp.c / etharp.c 中所有pbuf_free(p) 调用 5. 一键自检清单（复制打钩） [ ] Wireshark 回包 ICMP Checksum ≠ 0 且主机无 “Bad Checksum” 提示 [ ] arp -a 目标 IP ↔ MAC 正确，无 IP 冲突 [ ] 1500 B 大包连续 ping 稳定，不掉包 [ ] 连续 ping > PBUF_POOL_SIZE 次仍正常
楼上总结的很全面。 如果是空片的话，建议检查一下硬件环境，很多小伙伴忘记了给芯片供电。 怀疑是ST-LINK的话，可以找其他的板子对比测试一下。 如是原厂的ST-LINK 有电平转换芯片，很少坏的。
我这个现象应该不是时钟问题，因为我的其他外设跳转后都是可以正常运行，就FMC和XSPI异常。看架构这两个都是挂在A X I上的，不知道是否与之相关。我在跳转前Deinit了XSPI，app里初始化不死机了。但是还是不能正常使用XSPI进行操作。
你好: 我看目前sdmmc_stm32.c 內已經有stm32_sdmmc_clock_enable()內已經採用clock_control_get_rate, 目前也是卡住在這邊無法獲取正確的clock, m4 overlay中也已經移除pll2相關clock設定但是目前看起來還是讀取異常問題 看起來M7/M4所讀取道的系統時鐘差異蠻多導致。 Starting stm32h747i_disco with CPU frequency: 400 MHz m7 PLL1_P: 400000000 Hz m7 PLL1_Q: 200000000 Hz m7 PLL1_R: 400000000 Hz m7 PLL2_P: 240000000 Hz m7 PLL2_Q: 120000000 Hz m7 PLL2_R: 48000000 Hz UART device 'serial@40007c00' is ready. Msg Service [master] demo started _id=0 Starting stm32h747i_disco with CPU frequency: 200 MHz m4 PLL1_P: 128000000 Hz m4 PLL1_Q: 64000000 Hz m4 PLL1_R: 128000000 Hz m4 PLL2_P: 76800000 Hz m4 PLL2_Q: 38400000 Hz m4 PLL2_R: 15360000 Hz PLL2_R = 64000000 [00:00:10.019,000] [1;31m stm32_sdmmc: Failed to enable SDMMC domain clock [0m [00:00:10.019,000] [1;31m stm32_sdmmc: failed to init clocks[0m /* m4 SDMMC2 node */ &sdmmc2 { status = "okay"; compatible = "st,stm32-sdmmc"; clocks = , ; clock-names = "bus", "sdmmc"; bus-width = ; pinctrl-0 = < &sdmmc2_d0_pb14 &sdmmc2_d1_pb15 &sdmmc2_d2_pb3 &sdmmc2_d3_pb4 &sdmmc2_ck_pd6 &sdmmc2_cmd_pa0 >; pinctrl-names = "default"; /* 如果沒有 Card Detect，可以移除這行 */ cd-gpios = ; disk-name = "SD"; }; // &clk_hse { // clock-frequency = ; // status = "okay"; // }; // &clk_hsi48 { // status = "okay"; // }; // &pll { // div-m = ; // mul-n = ; // div-p = ; // div-q = ; // div-r = ; // clocks = ; // status = "okay"; // }; // &pll2 { // div-m = ; // mul-n = ; // div-p = ;//ori div-p = ; // div-q = ; // div-r = ; // clocks = ; /* Assuming 25MHz HSE */ // status = "okay"; // };
1、确认编译器真的开了 FPU Keil: Options → Target → Floating Point Hardware → Single Precision STM32CubeIDE: Project → Properties → C/C++ Build → Settings → MCU Settings → -mfpu=fpv5-sp-d16 -mfloat-abi=hard 再全清重新编译，map 文件里看到符号带 “vfp” 字样 才算数 2、确认运行时 FPU 使能 复位缺省 FPU 是 disable ！
如果你研究了基于stm32n6芯片的 XIP工程，L&R工程跟XIP模式的很多操作及环节是一样的， 只是一个是APP直接在外边FLASH运行，一个是FSBL将外部APP代码拷贝到RAM后再运行。 有篇应用笔记 LAT1491 STM32N6的FSBL基本流程介绍 建议阅读下。 然后这里再跟你分享一篇文章供参考。 LAT1587使用STM32CubeMX创建STM32N6的LOAD&RUN工程_V1.0.pdf
.png)
STMCU小助手
回答时间：5 天前
STM32WB09KE 的 BLE 协议栈本身并不限制一条链路只能有一个 notify 属性 ，也没有“只能开一个虚拟时钟”的硬性约束 。 官方 Heart-rate 例程里就是靠 两个虚拟定时器 （VTimer0 / VTimer1）分别完成 1 s 心率 notify 和 100 ms 电池 notify 的，所以“双服务 + 双 notify + 双 VTimer”这条技术路线在芯片层面完全走得通。 你目前“service1 能收，service2 收不到”的现象，99% 是软件/任务调度 问题，而不是硬件或协议栈限制。
基于STM8芯片做IAP的话，通常使用两个独立的工程，即一个bootloader、一个用户APP功能代码。 芯片的复位矢量及中断程序入口从硬件层面来讲是固定而唯一的，就是0x8000开始的一个矢量表。不同中断在这个表中找到各自的响应入口地址。理解这点很关键。 现在芯片里要放两套工程，即BOOT和APP工程。APP代码往往放在别的地址区域，假设0x9000开始的地方，APP里通常有更多或更频繁的中断响应需求。对于这些中断，CPU是没法直接在APP区找到中断响应入口的，因为所有中断响应入口都在0x8000开始那块表格里。于是先在0x9000开始的地方先建立一个矢量表，矢量表的内容就是各个APP中断服务函数的地址。同时,把这个表格本身的地址依次对应地填到BOOT区的0x8000开始的矢量表中，换言之，0x8000表格里的内容，除了复位矢量外，其它都对应到APP区的矢量表地址。这就是所谓的矢量重定向。 基于这个设计，也就不难理解为什么BOOT区不能开启中断了。【当然，这个要求不是绝对的，但基于这个方案就不建议在BOOT区开启中断了】 具体到你当前的设计，BOOT工程的矢量表需要你依照APP的矢量表的地址自行改写，没有简单覆盖的说法，也没有复杂的操作，仿照例程写法即可。这个过程中，注意各个中断矢量编号别搞乱了，否则会出现张冠李戴的情形。比方说，别把TIMER中断入口矢量安排到UART头上去了。
