的确可能碰到这个现象。 先把CubeMx的版本最新化。 然后H7分Y 版本和Z版本，在CUBEMx RCC那里有选择，还有供电范围选择Scale 0. 记住，频率越高，这个电压scale选择越低，最高是scale 3. 我看现在Cubemx在这个地都可以智能化了，会自动调整
首先可以肯定，STM32G4是支持位带操作的，在G4参考手册和M4内核手册上都有描述。 但是，位带区和别名区的地址空间空间都有明确定义。如果G4的GPIO没有落在位带区 就没法支持位带操作。我查看了手册，G4的GPIO外设寄存器地址空间都没在位带区。 当然，很多其它外设和部分片内RAM是支持位带操作的。 这里有篇文章可以参考下： STM32G4系列是否支持位带操作
[md]我看你用到了TIM8的触发事件，如果同时也开启该事件的中断的话，中断矢量跟TIM14的中断矢量入口是同一个。 换言之，TIM8的触发事件产生的中断，进入的中断服务程序跟TIM4的所有中断是同一个。 顺便说下，TIMER可以基于很多事件产生中断，常见的主要是更新事件，其实还有比较事件、捕获事件、触发事件、换相事件等。 续： 我刚又看了下配置，你应该可以避免TIM8 触发事件产生中断的，cubeMx配置这里注意下。如果不要比较中断的话，第三个勾选也可以取消。 !(data/attachment/forum/202408/02/100602s6uttptx6wvtyw1f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
STMCU-管管
回答时间：2024-7-31 17:16
准备 Linux 镜像：获取适合你的硬件平台的 Linux 镜像。这可能是一个文件系统镜像或者一个完整的 bootable image。 配置 U-Boot：确保 U-Boot 引导加载程序已经配置为支持 NAND 闪存。这可能需要修改 U-Boot 的配置文件（如 u-boot.cfg）。 烧录引导加载程序：使用 ST-LINK 或其他编程器将 U-Boot 烧录到 NAND 闪存的合适位置。 分区 NAND 闪存：使用工具（如 fdisk 或 mtd-utils 中的 nandwrite）对 NAND 闪存进行分区，为引导加载程序和文件系统创建空间。 烧录 Linux 镜像：将 Linux 文件系统镜像烧录到 NAND 闪存的相应分区。这可能需要使用 dd 命令或类似的工具。 更新 U-Boot 环境变量：根据烧录的 Linux 镜像更新 U-Boot 环境变量，确保它可以从 NAND 闪存启动。 测试启动：重启开发板，U-Boot 应该会自动检测 NAND 闪存并尝试从那里启动 Linux。 挂载文件系统：如果 Linux 启动成功，确保文件系统被正确挂载。 配置网络和设备：根据需要配置网络和其他设备。 验证功能：验证 Linux 系统的功能是否正常。
从你给出的信息来看，没法判断哪里不对。只能得知目前的发送都是失败的，第一个邮箱发送就出错了，后面的应该也没有正常发送，这个 可能跟代码的处理逻辑有关。 如果回环OK的话，就重点检查下线路，收发器这些。 如果回环模式没通过，先将回环调试OK. 另外，NORMAL模式下可以开启出错重传功能。
看你是基于标准库组织的代码，要是基于HAL库就方便了。 现在没收到数据，重点检查DMA接收这块的配置。 如果每次读到的数据剩余都是最大值，说明DMA没有发生接收。或者每次刚好收满重装了，我看你配置的是DMA接收循环模式， 但即使这样，可以通过接受缓冲看到数据。 另外，建议你先把FIFO关闭，即DMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Disable;
微信公众号
手机版
.png)
