YunTu Forum

demo里面没看到相关例子，要如何配置

78dcf82f-4cdf-400c-83cd-e578e4add045-8a902f08375322e38fe0094c4de7292b.png

欢迎使用3.2.0YT Config Tool（YCT), 下面是本次版本的更新内容，希望您在使用过程中有更好的体验。一些主要的更新内部包括：

Highlight

Update Software License File，Please check it.

Details [feat]:opt mcal agent, add openai api support, add http support [update]:update license file [feat]:add mcal eb support [bug]:fix cli mcal copyMcal feature [feat]:add cli export data arxml ability [feat]:enable secure fw build feat

1.问题背景 软件：SDK1_4_1版本及之前版本 硬件：YTM32B1系列 问题描述：
29f7e312-1bdd-4491-87e8-1dc050315286-image.png

执行软件触发mask更新操作时，偶发出现 PWM 通道波形无变化，写入的 CHMASK 值未生效

2. 问题分析 2.1 代码分析 2.1.1 chmask软件触发更新驱动代码

eTMR_DRV_SetChnOutMask() 根据 softwareTrigger 选择 CHMASK 的加载方式。软件触发分支会暂存原有加载配置，设置软件触发源，写入新的 CHMASK 值并触发加载，最后恢复原配置；另一分支则随寄存器同步加载。

status_t eTMR_DRV_SetChnOutMask(uint32_t instance, uint8_t maskEn, uint16_t maskVal, bool softwareTrigger) { DEV_ASSERT(instance < eTMR_INSTANCE_COUNT); eTMR_Type *etmrBase = g_etmrBase[instance]; etmr_sync_trig_src_t trigSrc; etmr_mask_sync_sel_t opportunity; eTMR_ClearLdok(etmrBase); if (softwareTrigger) { /* keep mask loading trigger source */ trigSrc = (etmr_sync_trig_src_t)eTMR_GetMaskLoadTrigSrc(etmrBase); /* keep mask loading opportunity */ opportunity = (etmr_mask_sync_sel_t)eTMR_GetMaskLoadOpportunity(etmrBase); /* select CHMASK loading trigger source */ eTMR_SetMaskLoadTrigSrc(etmrBase, SW_TRIGGER); /* select CHMASK loading opportunity */ eTMR_SetMaskLoadOpportunity(etmrBase, CHMASK_SYNC_WITH_TRIG); } else // sync with register loading { /* select CHMASK loading trigger source */ eTMR_SetMaskLoadTrigSrc(etmrBase, DISABLE_TRIGGER); /* select CHMASK loading opportunity */ eTMR_SetMaskLoadOpportunity(etmrBase, CHMASK_SYNC_WITH_REG); } /* set channel Mask enable and value */ eTMR_SetChnOutMask(etmrBase, maskVal, maskEn); /* set ldok */ eTMR_SetLdok(etmrBase); if (softwareTrigger) { /* generate one bus clock cycle pulse trigger */ eTMR_GenSoftwareTrigger(etmrBase, true); /* restore CHMASK loading trigger source */ eTMR_SetMaskLoadTrigSrc(etmrBase, trigSrc); /* restore CHMASK loading opportunity */ eTMR_SetMaskLoadOpportunity(etmrBase, opportunity); } return STATUS_SUCCESS; }

2d4f461f-3243-4d04-b11e-76ced0fcd753-image.png

2.1.2 软件触发路径的寄存器写入顺序

在 softwareTrigger 为 true 的分支中，与 CHMASK 加载直接相关的寄存器写入可概括为以下四步：

① eTMR0->SYNC |= CLDOK; // 清 LDOK，锁定本次加载 ② eTMR0->CHMASK = ...; // 写入新值（暂存 buffer） ③ eTMR0->SYNC |= LDOK; // 置 LDOK，允许加载 ④ eTMR0->SYNC |= SWTRIG; // 软件触发，将 CHMASK 从 buffer 载入输出

LDOK 是"加载许可"标志：只有 LDOK=1 时，软件触发才能将 CHMASK buffer 载入实际输出。一次加载完成或到达 MOD 加载点后，硬件自动将 LDOK 清零。

2.1.3 失效场景的 SYNC 配置：

在本次失效场景中，软件触发已启用（softwareTrigger=true），SYNC 寄存器的相关位域如下：

SYNC 寄存器位域 配置值 含义 REGLD[7:6] 0x01 REG 寄存器（VAL0/VAL1/MOD 等）在 CNT 到达 MOD 点时加载 MASKLD[15:14] 0x01 CHMASK 寄存器仅在触发源到来时加载 TRIGS2[13:12] 0x01 CHMASK 加载触发源 = 软件触发（写SYNC[16] SWTRIG）

关键点：REGLD[7:6]=01（MOD 同步），MASKLD[15:14] =01（触发同步）。这意味着 MOD 点会加载 REG 并清零 LDOK[0]，但不会加载 CHMASK（CHMASK 只等 SWTRIG[16] 软件触发）。

2.2 问题原因

9a2c7c57-b28a-443d-857d-e33ac8266b38-image.png

正常段： SWTRIG 发生在 CNT 到达 MOD 之前。此时 LDOK 仍为 1，缓冲区中的 CHMASK 新值随软件触发加载为生效值，输出开始使用新掩码；本次加载完成后 LDOK 清零。

失效段： 置位 LDOK 后，CNT 先到达 MOD。该时刻 REG 按配置加载并清零 LDOK，而配置为触发加载的 CHMASK 仍停留在缓冲区。随后 SWTRIG 到来时 LDOK 已为 0，新的 CHMASK 不能成为生效值，输出继续使用旧掩码。

3. 规避方案 3.1 修复方案：合并 LDOK 与 SWTRIG 写操作（最小改动，推荐优先实施）

d7a7bf05-6e61-4211-9443-6222b205c79b-image.png

优点：改动最小，消除 CPU 周期级竞态窗口

局限：理论上仍存在硬件内部 LDOK 置位与 SWTRIG 处理之间的极短窗口（纳秒级），实际几乎不可触发

3.2 修复方案波形测试记录

c085020d-868f-4c44-a2fa-7888f43ba10b-image.png

3.3 测试例程

LE15_MASK.zip

使用YTM32B1HA01的SDK包中的MBEDTLS进行RSA4096+SHA256签名验签，已经验证了0x1000字节的数据可以正常验签通过，CRYPTO_ENGINE_BUF_SIZE配置为20480；
115ab909-7ca6-4b72-b15d-38a3ae906be4-image.png
验证正式APP程序时，验签失败，返回值是-141，PSA_ERROR_INSUFFICIENT_MEMORY（运行时内存不足）
2acccdc3-cb0b-4234-a706-8045f999bf85-img_v3_0215r_7fe2c7ec-9d9f-4de6-939b-6b958a05e45g.jpg
因为数据长度较大，将近400K的数据，如果增大宏CRYPTO_ENGINE_BUF_SIZE来匹配数据量，会编译错误，没有这么多flash空间可用。有什么办法可以支持400K数据签名验签吗？感谢

上位机启动CAN发送数据，显示ACK err。CAN0 ECR->RCERRCNT 0x81。不能进CAN中断。
d6b62e38-b65c-4381-8cd5-25868e897db0-image.png
8c119760-6273-495c-a54f-a1e7b8ee93d6-image.png

1.结论摘要 MD24 MCAL 的 EWDG_SetCompareHigh() 形参类型为 uint8，而 EWDG 的 CMPH 寄存器字段为 16 位。客户配置 1s 超时（CompareHigh = 10000）时，高 8 位被静默截断，实际写入寄存器的值为 0x10（= 16），实测看门狗 2.3712ms 即触发复位。MC03 的同名函数形参为 uint16，不存在该问题。 影响：所有 CompareHigh（及 CompareLow，见第 5 节）配置值 大于 255 的 MD24 客户，看门狗都会提前复位；由于配置值 ≤ 255 时表现正常，该缺陷在简单测试中不易暴露。 修复：将形参类型改为 uint16（与寄存器字段位宽一致），并补充超范围参数校验以防再次静默截断。修复后的实测结果见第 6节。 2. 问题描述

客户在 MD24 上配置 EWDG 超时时间为 1s，实际超时时间远小于 1s，看门狗持续触发复位；相同配置在 MC03 上表现正常。
客户的 EWDG 硬件设计如下图所示：EWDG_OUT 通过一个二极管连接到复位脚，EWDG_OUT 拉低即触发复位。
图 2-1：客户 EWDG 硬件设计
949a49eb-503d-4cdc-835d-4adc25890572-image.png
MD24 侧的 MCAL WDG 配置如下：
图 2-2：MCAL WDG 配置（CompareHigh = 10000）
3077c656-3c0c-46fb-b586-a8a38109b87c-image.png
实测现象：EWDG_OUT 从初始化完成到拉低仅 2.3712ms，远小于配置的 1s。
图 2-3：实测 EWDG_OUT 波形（2.3712ms）
68d97214-0730-4ed2-8d51-753721fecf93-image.png

3. 复现步骤 基于 MCAL 配置工具，将 EWDG 的 CompareHigh 配置为 10000（按配置工具口径对应 1s 超时，即 1 计数 = 100µs）； 初始化并启动 EWDG，不再喂狗； 用示波器测量 EWDG_OUT 从启动到拉低的时间； 实测结果为 2.3712ms，而预期为 1s。
说明：客户原始场景中上一步骤的"停止喂狗"由功能未及时喂狗自然触发，此处为便于复现改为主动停止。 4. 根因分析 4.1 配置值与寄存器实际值的差异
配置项 CompareHigh = 10000，但读回寄存器发现实际写入值为二进制 10000b，即 16。
图 4-1：配置项截图
225ffde0-4c4f-47c2-87d0-fdacb017e2b1-image.png
图 4-2：寄存器实际值截图
890d7d6f-bfe2-4de1-9b0a-020054682360-image.png 4.2 定位：形参类型与寄存器字段位宽不匹配
对比 MC03 与 MD24 驱动实现，发现 EWDG_SetCompareHigh 的形参类型存在差异： MC03：形参 Value 类型为 uint16； MD24：形参 Value 类型为 uint8。
图 4-3：MC03 与 MD24 形参类型对比
094836fb-cdb7-4e7d-8dc5-e6c92aa8c053-image.png
而 MD24 的 EWDG -> CMPH 寄存器字段与 MC03 一致，均为 16 位：
图 4-4：MD24 EWDG CMPH 寄存器定义（16 位）
cfc07a0a-e5aa-40cb-b9dd-4c48da793984-image.png 4.3 失效机理 CompareHigh = 10000 ↓ 十进制转十六进制 0x2710 （占 16 位） ↓ 传入形参 uint8 Value（仅 8 位），高位被丢弃 0x10 = 16 （写入寄存器的实际值）

由于该截断发生在赋值处，既不会有编译告警，也不会触发 DET 参数校验，属于典型的静态静默截断：配置工具显示正常、代码编译通过、只有运行时行为异常。

5.修复方案

当前临时修复：在 EWDG_SetCompareHigh 的条件编译处补上 MD24 分支，使其形参类型与寄存器字段位宽一致（uint16）。
图 5-1：修复代码
d77575aa-a3fb-4c3f-b2c5-f92ff19457e5-image.png

6. 回归验证

实测结果：
图 6-1：修复后实测波形
f06e34bd-9935-49d3-820f-a70ba3adb8af-image.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 重新装载完成后再发下一帧，则不会出现。

想请教：

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 的官方接口名称、示例或补丁，谢谢。

can收发时会进入CAN1_Error_IRQHandler函数，调用回调后，Can_ErrorType = CAN_ERROR_OVERRUN，可能是什么情况

2eeb6b7a-09c2-44e9-a303-de44d14c6e6b-image.png

请提供云途官方HA01-EVB板子设计制作pcb的资料，包含但不限于：

最新版本RevB 原理图 HA01封装库

84538089-4b4d-4d12-acc1-f3ad8491edec-image.png

1. 问题背景 软件：MD24 SDK_1_4_1 Wdg_Demo 硬件：MD24 EVB 背景描述： 有客户反馈 MD24 WDG 的定时器只有 16bit，无法设置较长的 WDG 复位时间，因此可以使用 WDG IRQ 实现较长时间的 WDG 超时复位。 2. 实现原理 2.1 硬件配置 WDG时钟源：FXOSC (24MHz) WDG时钟分频：16 WDG超时值：60000 中断周期：(24MHz / 16) / 60000 = 25Hz → 40ms 2.2 软件实现 WDG初始化：配置 WDG为 40ms 中断一次 中断处理：在 WDG 中断中计数，每 40ms 计数一次 喂狗逻辑：计数小于 100 时继续喂狗（40ms × 100 = 4s） 超时处理：计数达到 100 时停止喂狗，等待 WDG 复位 2.3 关键代码 WDG 配置 const wdg_user_config_t wdg_config0 = { .clockSource=WDG_IPC_CLOCK, .opMode={ .deepsleep=false, .debug=false, }, .updateEnable=true, .intEnable=true, .winEnable=false, .windowValue=30000, .timeoutValue=60000, .apbErrorResetEnable=0, }; 中断处理函数 /** * @brief WDG中断处理函数 * @details 每40ms触发一次，计数到100次时（4s）停止喂狗，导致WDG复位 */ void WDG_TSTIRQHandler(void) { /* 清除中断标志 */ WDG0->INTF = WDG_INTF_IF_MASK; /* 翻转 IO，指示中断触发 */ PINS_DRV_TogglePins(GPIOD,1<<8); /* 增加4s计数器 */ Wdg_flag_4s++; /* 当计数小于100时喂狗（40ms * 100 = 4s） */ if(100 > Wdg_flag_4s ) { WDG_DRV_Trigger(0); } else { /* 计数达到100，停止喂狗，等待WDG复位 */ } } 3. 使用方法 编译代码：使用 IDE 编译整个工程 下载程序：将编译好的程序下载到 MD24 开发板 观察现象：

IO 每 40ms 反转一次
6e1c7ba6-a570-4abf-bfc1-c9714302fd73-image.png

反转100 次后（约 4s），IO 停止反转，随后系统会因 WDG 超时而复位，复位后，程序会重新开始执行
80730bc4-938a-45b8-97e2-494a71c79776-image.png

4. 注意事项 时钟配置：确保 WDG 时钟源和分频设置正确，以获得准确的中断周期 计数设置：根据需要的超时时间调整计数阈值（当前为100，对应4s） 中断优先级：确保 WDG 中断优先级设置合理，避免被其他中断长时间占用 喂狗时机：在实际应用中，应在适当的时机喂狗，确保系统正常运行 5. 扩展应用

此方法可以扩展到更长时间的 WDG 超时复位：

10s 超时：计数阈值设置为 250（40ms × 250 = 10s） 30s 超时：计数阈值设置为 750（40ms × 750 = 30s） 1min 超时：计数阈值设置为 1500（40ms × 1500 = 60s）

YTM32B1HA01芯片MCAL Dio Demo中
NC_TEXT(start 0x2000c00 length 0xb400)区域在YT_link.ld文件中设置为none cache，但是在Mpu_Lld_Cfg.c 文件中直接对2MB的PFlash设置成了Cache属性，并且没有更高优先级的region覆盖，请帮忙确认下，是否有该问题？
链接文件中地址区域的属性和Mpu_Lld_Cfg.c中的设置如何保持一致？
e4bc9c86-49b8-432d-a5fc-fa048dd963ad-image.png

c6340f12-f45a-45ac-ba6f-3d074645af96-image.png

1. 问题背景 问题描述： HCU_DRV_RSASSA_PSS_VerifySignature -> HCU_SHA256_Check 这样调用会报 HardFault_Handler 解决方案： HCU_DRV_RSASSA_PSS_VerifySignature -> HCU_DRV_Init -> HCU_SHA256_Check 这样操作就不会进入 HardFault_Handler 背景说明 软件：MD24 SDK_1_4_1 版本及其之前版本的 HcuDemo 都会有这个问题，HcuDemo 下载路径为https://forum.ytmicro.com/topic/1208/ytm32b1md2x-hcu-demo-%E5%B1%95%E7%A4%BA?_=1789955578721 硬件：MD24 EVB** 2. 问题复现 2.1 HCU_DRV_RSASSA_PSS_VerifySignature -> HCU_SHA256_Check 这样调用会报 HardFault_Handler hcu_sha_demo -> hcu_sha_demo1 直接仅执行 HCU_DRV_RSASSA_PSS_VerifySignature 函数

595b7924-470a-4f7b-b98a-195a86a277aa-image.png

HardFault_Handler 后根据 Call Stack 可以得知出错前，代码是在 HCU_ConfigAlgorithm 函数里，HCU_ConfigAlgorithm 这个函数是 HCU 静态库（iar_hcu.a，；lib_hcu.a）里的函数，无法看到函数的内部执行

2edff760-af82-478a-82e0-ec394ac44d54-image.png

2.2 HCU_DRV_RSASSA_PSS_VerifySignature -> HCU_DRV_Init -> HCU_SHA256_Check 这样操作就不会进入 HardFault_Handler hcu_sha_demo -> HCU_DRV_RSASSA_PSS_VerifySignature -> hcu_sha_demo 就可以正常运行，不会进入 HardFault_Handler，因为 hcu_sha_demo 里有调用 HCU 初始
42a4ea23-2c7f-4531-9b77-a94c18025b94-image.png
e1104fb4-ad60-4277-99b7-1f16bd538d92-image.png 3. 问题结论 根据 Debug 现象推测 HCU_DRV_RSASSA_PSS_VerifySignature 函数里有执行 HCU 反初始化，从而导致再次执行 HCU 操作是若未调用 HCU_DRV_Init 则会导致 HardFault_Handler（hcuState 结构体里的配置都被释放了，可能会出现空指针的情况） MD24 HCU 所有 padding 方式带 SHA 的，内部都有 HCU Init + HCU Deinit，ECDSA 也一样的，内部涉及到 AES or SHA 算法的都是这样的。调用类似 API 后，如果要继续使用 HCU 运行，都要重新调用一下 HCU 初始化

8ca1ee47-975c-4501-8425-b58d753592cb-image.png

测试现象：MCU没有任何日志输出，外设供电正常，看门狗正常喂狗（硬件定时器中断回调函数中喂狗），Ozone调试器连进去后显示 LINFlexD_UART_DRV_RxIRQHandler 中断回调函数一直在触发，但是isRxBusy 状态位处于false，导致中断flag没有清除，中断一直在触发。（已知MCU UART0 对端连接PC端，但是测试过程中 PC端没有向串口发送数据）。帮忙看下该问题应该如何修复。
8ef69452-c82f-4cb7-bcf9-91057a808802-2eb115e01bd5f99cee21e9fd625909f.png
9d5eae25-ebfc-4eb8-84a0-f81788bc8843-89a01268b02b7cdc70ffe463c46e13b.png
串口中断状态寄存器如下：
17e0de43-f414-4159-81ec-997084567156-6f816a50c160593e2189c5270ecdcf8.png

目前云途的UDS公版只支持物理寻址，而我们的控制器开发要求支持功能寻址（7DF），是否有移植文档参考

用Jflash烧录代码过程不断电，烧录成功后运行正常，断电放了一段时间上电，代码没有运行，并且用JFLASH读取flash的数据，出现如图片提示微信图片_2026-09-18_165853_258.png 麻烦帮忙分析一下是什么原因导致

64bdd325-64b9-4b01-b8f9-c6b379564e0f-image.png
添加了MCAL示例工程，但其中的模块报签名验证失败错误，如何解决呢