743aad6c-aea2-44e2-ac33-0fb7d4ba6cb5-image.png const wdg_user_config_t wdg_config0 = {
.clockSource=WDG_SIRC_CLOCK,
.opMode={
.deepsleep=false,
.debug=false,
},
.updateEnable=true,
.intEnable=false,
.winEnable=false,
.windowValue=30000,
.timeoutValue=65535,
.apbErrorResetEnable=0,
};我使用合这个配置去修改超时时间，从数据上看实际值比理论值多2ms。这个2ms初始化是时钟和IO口的时间吗？
一个面向 YTM32B1 MCU 的紧凑型、位置无关（Position-Independent）Flash 驱动，编译为一个小型二进制镜像（FlashDriver.bin）。应用既可将它作为 C 数组内嵌，也可下载到 SRAM，再通过固定的函数表调用。该设计面向引导加载程序（Bootloader）/OTA 场景——当需要擦除、编程正在被修改的 Flash 区域时，驱动代码本身必须运行在别处。
定位与 PIC 优势 位置无关代码（PIC）：镜像以 -fpic -fpie 编译，不含任何绝对地址假设。主机应用从镜像基址（FLS_DRV_BASE_ADDR）处的函数表中解析每个函数入口，因此二进制可被加载到不同的 SRAM/Flash 地址而无需重新编译。 从 SRAM 运行：驱动在 SRAM 中执行，因此可以擦除、编程任意 Flash 区域，包括应用自身所在的区域——这正是 Bootloader/OTA 更新的典型需求。 占用极小：整个镜像（函数表 + 代码 + 常量）必须放入 4 KB 链接区域（link/relative.ld）；当前 YTM32B1ME1 构建产物仅约 856 字节。 单头文件集成：主机侧只需 fls_drv_bin.h（数组模式下另需生成的 data 头文件）。API 签名遵循 SDK Flash 驱动惯例并返回 status_t，覆盖引导加载所需的核心操作（Init/Deinit、扇区擦除、编程、BootSwap）。它是 SDK 驱动的紧凑子集，并非完整替代品。 多芯片一次构建：一次 CMake 调用即可产出全部芯片变体。 注意事项 校验函数表：FLASH_DRV_GetVersion() 应返回 1。否则说明 FLS_DRV_BASE_ADDR 处的镜像不正确（数组未链接，或二进制下载到了错误的 SRAM 地址）。 PRESCALER：在 FLASH_DRV_Init() 之前且每次时钟变更后将 EFM CTRL 的 PRESCALER 配置为 flashClockHz / 2,000,000；以目标芯片 SDK/参考手册为准。 对齐：EraseSector 的 dest/size 为扇区大小整数倍；Program 的 dest/size 为 FEATURE_EFM_WRITE_UNIT_SIZE 整数倍且 pData 4 字节对齐。 先擦除再编程：编程前目标区域必须为 0xFF（已擦除）；操作后回读校验。 SRAM 模式：FlashDriver.bin 必须实际加载到 FLS_DRV_BASE_ADDR 处；地址错误会在首次 API 调用时导致硬错误（Hard Fault）或未定义行为。 链接溢出：若构建报 "region m_text overflowed"，说明镜像超过 4 KB 链接区域。 缺少 bin2h.exe：若 bin_project/tools/bin2h.exe 不存在，生成 fls_drv_bin_data.h 的构建后步骤将失败。 中断/cache：若 ISR 可能访问被操作的 Flash 区域，请在擦除/编程期间屏蔽中断；建议在 Flash 操作前禁用 cache。 BootSwap：仅在芯片支持时调用，且仅在具备已验证恢复路径的流程中使用。 不建议将驱动作为常驻可执行内容持久保存：函数表中保存的是基于 FLS_DRV_BASE_ADDR 解析的相对偏移。建议仅在需要执行 Flash 操作时，将镜像加载到受控的 SRAM 地址，并在调用任何擦除/编程 API 前校验基址和 FLASH_DRV_GetVersion()。若基址错误、镜像损坏或程序异常跑飞，可能解析到错误的函数地址，进而造成 Flash 误擦除或误编程。提示： 请在使用前，仔细阅读项目根目录下的 README 文档，以获取完整的环境配置与运行说明。
关于各版本的迭代细节与功能变更，敬请参阅 CHANGELOG 文件。
https://forum.ytmicro.com/topic/164/ytm32mc03-有没有ram-flashdriver的案例-做boot用的?_=1767074645275
工程下载：flash_driver_bin-v1.1.1-20260814.zip
Config Tool Version：2.7.6
MC03 SDK version：1.3.1
有硬件ABswap后FEE历史数据保持的需求。由于YTM32B1MC系列MCU⽆内置EEPROM，故对需要使⽤EERPOM的应⽤场景可通过DFlash及软件模拟实现EEPROM功能。
本⽂简述云途YTM32B1MCx系列的硬件ABSwap原理和FEE历史数据保持实现过程和使用方法。
不同型号的芯片描述不一样，MC03描述如下：
32fe0b96-559f-48f5-b014-01b478142442-image.png
ME05描述如下：
6ace7f21-b914-457e-a9fb-ee8325e64733-image.png
简单来说，BOOT_INFO寄存器可以用来判断程序是从PFLASH0还是PFLASH1启动。
如下图为MC的AB_Swap地址重映射流程说明。
当STS[BOOT_INFO]=O时执行BOOT_SWAP命令，然后复位EFM，STS[BOOT_INFO]将置为1，地址将重新映射：
1.P_Flash0的Soc地址重映射到P_Flash1时，D_Flash0的Soc地址重映射到D_Flash1。
2.P_Flash1的Soc地址重映射到P_Flash0时，D_Flash1的Soc地址重映射到D_Flash0。
当 STS[BOOT_INFO]=1时执行BOOT_SWAP 命令，然后复位EFM将切换回地址映射并清除STS[BOOT_INFO]标志。
4c336365-6c1f-4ff5-93e2-81d0a801411a-image.png
如下图为各个FLASH区域之间支持边读边写的关系。
1.异步访问：因为P_Flash0,D_Flash0在同一个FLASH块，P_Flash1,D_Flash1在同一个FLASH块。所以P_Flash0对D_Flash1支持边读边写，P_Flash1对D_Flash0支持边读边写，即异步访问。
2.当程序从P_Flash0启动时，建议将FEE数据存储在D_Flash1，这样在读写D_Flash1时CPU无需等待，实现异步操作。反之亦然。
ee8ef5cd-f712-4175-9e76-baf64e691b44-image.png
如下图为MC的AB_Swap流程图。
当程序从A区（P_Flash0）切换到B区（P_Flash1）时，如果想用相同的FEE配置去读写FEE，就需要在AB_Swap之前将D_Flash1的内容copy到D_Flash0。因为D_Flash的地址也会重映射。
4245730f-76c1-4ce5-9360-1b2698815b8c-image.png
AB_Swap_MC03.zip
本来想实现硬件的 但是看了下原理 我的bootloader+app1已经超了PFLASH0 128KB啦。
0x0000_0000 ~ 0x0001_17FF 0x11800 Bootloader（含 IVT）
0x0001_1800 ~ 0x0002_7FFF 0x16800 APP_A 运行区
0x0002_8000 ~ 0x0003_E7FF 0x16800 APP_B 升级缓冲区
0x0003_E800 ~ 0x0003_E9FF 0x200 APP_A appinfo
0x0003_EA00 ~ 0x0003_EBFF 0x200 APP_B appinfo
0x0003_EC00 ~ 0x0003_FFFF 0x1400 保留/扩展区
6073db06-7d03-448f-9f09-b6e0f4790a16-image.png
68bf2716-3507-4b84-b451-4b80c728a0d6-image.png
9f3f733a-dab8-4b35-a4f7-8b2024b97503-image.png
使用如图的MCU型号(YTM32B1MD1),然后使用Secure Boot功能产出的newFw-0x4000档案的BVT表中的CMAC数值是算错的,我用JLINK单步执行,发现假如Encrypted flag勾选的话,程序在Section Config 加密后的解密就不对了,然后不勾后就可以往下跑到CMAC的验证,但结果还是错误(程序卡死在Secure Boot),但我用直接用写入的钥用软件算出CMAC值直接复写到BVT表中,就可以跳转到预期的BOOTLOAD中,我认为是YT Config Tool 转换的加密Section Config和CMAC的程序根本不是用YTM32B1MD14这颗MCU去作动的(但我的YT Config Tool device是选对的,如上图所示),请问是那出问题了吗?
使用环境：
MCU：YTM32B1ME0 SDK：1.4.1 SPI3 Slave，Mode 0，8-bit DMA：TX Channel 0、RX Channel 1 Master 时钟约 8 MHz 每次 CS 完成固定 512 Byte 全双工传输，Master 可能连续发起下一帧目前使用 SPI_DRV_SlaveTransfer()。查看 SDK 实现发现，RX DMA 完成后，SPI_DRV_SlaveCompleteDMATransfer() 会先调用 SPI_DRV_SlaveAbortTransfer()，然后才调用应用层的 SPI_EVENT_END_TRANSFER 回调。应用在回调中再次调用 SPI_DRV_SlaveTransfer() 装载下一组 TX/RX buffer。
这样在相邻两个 CS transaction 之间会有一段 Slave DMA 未装载的窗口。长时间连续通信时，Master 偶发收到整帧 0xFF；如果 Master 等待 MCU 重新装载完成后再发下一帧，则不会出现。
想请教：
YTM32B1ME0 的 SPI Slave DMA 是否有官方 continuous、ping-pong、double-buffer、queue 或 descriptor ram-reload 接口，使当前帧结束后自动切换到下一组 TX/RX buffer，中间不 Abort、不关闭 DMA、不清 FIFO？ 通用 DMA 驱动已有 DMA_DRV_ConfigRamReloadTransfer()，是否有与 SPI Slave 正式集成的官方 Demo、SDK补丁或推荐配置？应用层不希望绕过 SPI Driver 直接操作 DMA/SPI 寄存器。 如果当前 SDK 不支持连续 Slave DMA，官方推荐的用法是否是增加一根 READY GPIO：Slave 完成后先 deassert READY，在任务上下文重新调用 SPI_DRV_SlaveTransfer()，成功后再 assert READY，Master 每一帧发送前都等待 READY？ SPI Slave 的 SPI_EVENT_END_TRANSFER 回调运行在 DMA ISR 上下文。是否允许在该回调中立即再次调用 SPI_DRV_SlaveTransfer()？如果不允许，建议的最小安全重装流程是什么？希望能提供适用于 YTM32B1ME0 SDK 1.4.1 的官方接口名称、示例或补丁，谢谢。
Announcements regarding our community
A place to talk about whatever you want or ask a question
Blog posts from individual members
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...
