看看芯片焊接的方向或者是不是板上的电容瞬间测量引起误判。 看起来你是采用第2种供电模式，但不知为何会有R76存在。 另外电容也不太合适，建议和评估板原理图比对一下吧。 PDR_ON 引脚不要悬空。
从应用笔记Getting started with MMT(Memory Management Tool) 中介绍看，这个工具主要是RAM的分配管理。 其中列举了H7 单核中FMC的内容，只针对sdram有影响。也就RAM的分配的三种可能。 所以对NAND 以及 LCD 都不会有变化。你可以再核对一下。 另外不建议这样同一个外设分时用，管理起来会有难度以及效率拉低了。
根据厂商的手册资料看，AP1和AP2 是访问特殊区域的，并且要在一定条件下。 比如AP1只能访问D3域而且是在D1和D2域关闭后才可以。而实验中的地址并非SRAM4. 通常调试用AP0 和 AP3 已经覆盖了常用的的功能，许多软件并没有特意做对应的功能。 所以一般用户都没有使用。
没发现这个问题和勘误表上有这样的描述。 你是不是直接调用了底层函数，实际上擦除是有例程的，建议参考例程试试。 好多小伙伴都是参照例程的方式擦除和改写数据，并非自己调用函数实现的。 在FLASH中执行擦除时，是会暂停取指一定时间，这时候要考虑应用是否能接受这点时间，单步调试时就能感受到。
哪里的例程？ 如果是HAL库中例程，通常都是相对路径，一般不会出现。看看是不是有编译器配置问题。 当然日常开发时，会经常遇到这类问题，如同大家说的，把需要的文件路径添加进来就可以了。
特权模式和安全模与非安全属性不太一样。 什么是特权模式Privileged在同一个安全状态（Secure/ Non‑Secure）内部： 特权模式：可以访问全部寄存器、全部外设、可以修改控制寄存器、可以切换栈指针、可配置 MPU、SAU。 非特权模式：访问受限制，部分系统寄存器不能写，外设可通过 MPU 做权限拦截。 Secure 域的特权 ≠ Non‑Secure域的特权。 即使 Non‑Secure 侧跑在特权模式，依然不能直接访问 Secure 的资源，由 SAU+IDAU 隔离。 模式切换（Cortex‑M55） 异常进入时：自动进入对应域的特权模式 不管进入异常前是特权还是非特权，中断 / 异常响应后，都会变成该安全域下的特权模式，默认使用该域的主栈 MSP（Secure 异常用 MSP_S，Non‑Secure 异常用 MSP_NS）。 这和 Cortex‑M0/M3/M4 行为一致：异常处理函数永远是特权。 线程模式下切换特权 / 非特权 线程模式下，靠 CONTROL 寄存器的 bit‑0 控制当前域内特权级别： CONTROL.bit0 = 0 → 特权线程模式 CONTROL.bit0 = 1 → 非特权线程模式 只有特权代码才可以改写CONTROL.bit0；非特权代码写CONTROL 会被忽略。厂家有个编程手册，上面有一些关于内核介绍的
之前我还以为BLE文件夹内是两个项目，进一步了解之后才知道只有HeartRata是心率检测项目的文件夹，而Common文件夹内是BLE的一些基本文件，是HeartRata项目中必须的一部分。
你玩板子不看原理图的吗，MB1373 这玩意串口是在PA9/PA10或者PB11/PB10，接到PC做什么？你如果没有改板上跳线电阻的话，连到的是USART1：PA9/PA10上的。PC11那个物理上又没有跟stlink的虚拟串口连接
哥们，下载了一下，在固件包文件夹的Demonstrations里面，Modules有BLE的示例!(data/attachment/forum/202608/22/201750kzqg9p37ib1c8130.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
建议检查下VCAP的处理，主要器件参数、质量，这点在手册中有明确说明。 另外，检查下boot脚的连接、焊接情况，不要有虚焊。 有没有可能程序方面也有卡死的情形，可以换个简单代码测试下。
可能是发生NAK 后，软件错误地把整个192B 传输重新提交了。这会引出两个现象： 1、HCTSIZ / PKTCNT 被重新写。 这时会看到，本来还剩一部分没发完，结果 PKTCNT 又回到 3。 2、NPTX FIFO 被重复灌数据。 因为同一段 192B 又被重新塞进FIFO，最后可能卡在 USB_WritePacket()。 原因很可能是控制 OUT 的NAK 重试逻辑有问题。 你要确认下，设备回了 NAK 之后，主机是不是把整段192B 又从头提交了一遍。 具体来说，就是观察在出错或被 NAK 后再次发送时，是否简单地再次SubmitRequest(192)，并把 xfer_count 清零。 正常情况下，主机只应重试还没成功发送的那一包，而不是不管前面已经发出去多少，又把整段数据重新发一遍。
这段发送流程里通常没必要手动 SNAK，SNAK 一般是需要停止传输时才使用的动作。 STALL状态在 F4系列OTG模块 上通常不是硬件操作的，而是软件处理的。 可以重点搜索代码里哪里写了 DIEPCTLx.STALL，再跟踪是谁、因为什么条件触发了这条路径。
.png)
