执行软件触发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 测试例程使用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数据签名验签吗？感谢
使用环境：
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 的官方接口名称、示例或补丁，谢谢。
IO 每 40ms 反转一次
6e1c7ba6-a570-4abf-bfc1-c9714302fd73-image.png
反转100 次后（约 4s），IO 停止反转，随后系统会因 WDG 超时而复位，复位后，程序会重新开始执行
80730bc4-938a-45b8-97e2-494a71c79776-image.png
此方法可以扩展到更长时间的 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
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 初始测试现象：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
使用YTM32B1HA0系列100pin，PTD17配置为Dio输出，无法控制输出高低电平。
存在问题的MCAL版本:YTM32B1HA0 2_3_0 以及之前的版本
问题分析仿真调试发现在写DIO时，执行到DIO_LLD_VALID_PORT_PIN判断时会出现错误。生成的Dio_Cfg.h文件中的宏定义DIO_PORTD_PINS_MASK默认为0x1FFFC，第17位为0，导致Det报错。
a0f25fb9-c1da-41cc-8a33-c6fe20b129c8-image.png
21ad88c5-7034-47cb-a273-88b914991c49-image.png
实际YTM32B1HA0 100pin存在PTD17。
d4ee0eb3-ab18-40a3-924b-1ba2a1ad8295-image.png
解决方法DIO_PORTD_PINS_MASK修改为0x3FFFC。
LE15 UDS LIN FBL demo(SDK 1_3_1)
本方案基于YT Config Tool开发，使用Vscode+Cmake+Ozone工具链开发编译调试；基于Demo板硬件搭建实施；使用同星科技TC1012P CAN/LIN工具及同星科技TSmaster软件。
f4a50300-1cf4-4b4d-acea-b125d11fcf9f-image.png
我这边环境是 YTM32B1MC0 SDK 1_4_0
然后我这边使用SPI读值的时候发问题：
SPI_DRV_MasterTransferBlocking Task任务中调用的时候读值正常；但是放到lpTMR0_IRQHandler的时候，直接导致程序崩溃；
SPI_DRV_MasterTransferPolling 放到lpTMR0_IRQHandler的时候读值，但是陀螺值偶尔变成346.34765625，没法用；
想问下我在定时器SPI采集数据，有什么更好的方式吗；目前暂时还是 SPI_DRV_MasterTransferBlocking 然后在 Task任务采集，不过由于新算法耗时较长，所以要把采集放到定时器保证采集的稳定；
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哦...
