1. 烧录Bootloader
   新建YTM32B1MD24的JFLASH工程
   
   找到Bootloader编译的烧程文件
   文件路径：.\uds_can_fbl_md24_release_20260828\uds_can_bootloader\build\uds_can_bootloader.hex
   
   加载Bootloader文件
   
   擦除芯片（或者快捷键F4）
   
   
   烧录程序（或者快捷键F7）
   
   
2. 上下电运行Bootloader
   拔掉JLINK烧录器，重新上下电后，板子重新工作，LED按照100ms快速闪烁，程序工作在Bootloader里面。
3. 升级上位机配置
   将FlashDriver文件、Application文件、SeedAndKey.dll几个文件放到升级上位机目录下。
   文件路径：.\uds_can_fbl_md24_release_20260828\UDS_CanFbl_TsMaster
   
   打开升级上位机工程（如上图中.TSProj_x86文件）配置收发ID
   
   配置TP时间参数，配置加密dll
   
   配置FlashDriver和Application和校验方式
   
   若是修改 flashdriver/app 文件命名，需要修改对应校验的请求值
   
   配置自动诊断流程
   
4. 执行升级
   4.1 从Bootloader升级
   
   升级完成后，LED灯1000ms闪烁，运行在Application程序中（Bootloader程序中LED灯100m闪烁）。
   4.2 从Application升级
   从Bootloader升级成功运行到Application后，再次点击运行，从Application升级。
   
   升级过程中，运行在Bootloader程序中，LED灯100ms闪烁，升级完成后，LED灯1000ms闪烁，运行在Application程序中。

4.3 StayInBoot升级
从Application升级中，是有升级请求标识的（KeepInBootVar变量）。
本方案设计上认为：
运行到Bootloader以后，如果通讯一半断开未发生升级服务（擦除芯片/请求下载/数据传输/下载退出等UDS服务），则即使有升级请求，可以超时退出重新跳转到Application运行；反之则必须StayInBoot等待重新升级。
4.3.1 未发生升级流程请求
升级一半，拔掉CAN线模拟通讯断开，升级失败

通讯断开超时后，Bootloader重新进入Application运行，Demo板上LED灯1000ms闪烁。
4.3.2 已发生升级流程请求
执行到升级流程后，拔掉CAN线模拟通讯断开，升级失败

通讯断开超时后，Boootloader不能进入Application，执行StayInBoot（重新复位或者上下电等均保持StayInBoot）。
重新执行升级

升级成功，Demo板上LED灯1000ms闪烁。
5. 附件代码
uds_can_fbl_md24_release_20260828.zip

3f36cdbbeddfccb2b107dd3d16b03aee.png

• 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 重新装载完成后再发下一帧，则不会出现。

想请教：

1. YTM32B1ME0 的 SPI Slave DMA 是否有官方 continuous、ping-pong、double-buffer、queue 或 descriptor ram-reload 接口，使当前帧结束后自动切换到下一组 TX/RX buffer，中间不 Abort、不关闭 DMA、不清 FIFO？
2. 通用 DMA 驱动已有 DMA_DRV_ConfigRamReloadTransfer()，是否有与 SPI Slave 正式集成的官方 Demo、SDK补丁或推荐配置？应用层不希望绕过 SPI Driver 直接操作 DMA/SPI 寄存器。
3. 如果当前 SDK 不支持连续 Slave DMA，官方推荐的用法是否是增加一根 READY GPIO：Slave 完成后先 deassert READY，在任务上下文重新调用 SPI_DRV_SlaveTransfer()，成功后再 assert READY，Master 每一帧发送前都等待 READY？
4. SPI Slave 的 SPI_EVENT_END_TRANSFER 回调运行在 DMA ISR 上下文。是否允许在该回调中立即再次调用 SPI_DRV_SlaveTransfer()？如果不允许，建议的最小安全重装流程是什么？

希望能提供适用于 YTM32B1ME0 SDK 1.4.1 的官方接口名称、示例或补丁，谢谢。

z123456111
APP和BOOT共享变量的保持需要通过链接文件和RamInit0函数共同保证，你这个看起来是这个数据段被ECC初始化写过了。
1.检查一下RamInit0是否有下图操作（如果是手动移植代码可能会遗漏）
d522950c-d58a-4d48-8b59-df2820a83de7-0cac737599736d0820ca130a4937cd20.png
2.检查下main函数中是否有清除POR上电复位标志。
41225059-922a-4774-bed0-8e8e36284e30-e9ecc1a51da51cea158a0cbfed785256.png

总的来说SDK版本的迭代和链接文件的修改都不要用手动移植的方式，一定要用工具去配置生成，手动移植把握不住，容易有遗漏

嗯嗯·，谢谢，找到了，RamInit0是没有对刷写标志位进行判定的，我这边加了过后就好了