YunTu Forum

MCU休眠模式Standby，PTC2为CANRX引脚，休眠前切换成ICU模式，发现可以进入中断，但没有唤醒MCU，8d17f795-d0e5-47cd-8a0a-72e0b9b368c3-image.png 5aa53303-36a5-470a-a7da-be4a86b21582-image.png

我在原来 can 模式基础上添加了 fd 发送支持，目前发现无法正常发送数据。具体关键代码如下：

#define YTM_CANFD_MODE_ENABLE int board_can_init(uint32_t baudrate) { // 使能 CAN0 时钟 REG32(IPC_FLEXCAN0) |= 0X01; // 修改为 ALT5 模式 PTE4 can0 rx/PTE5 can0 tx REG32(PCTRLE_4) &= ~(0XF << 8); REG32(PCTRLE_4) |= 0X5 << 8; REG32(PCTRLE_5) &= ~(0XF << 8); REG32(PCTRLE_5) |= 0X5 << 8; REG32(CAN0_MCR) &= ~CAN0_MCR_MDIS_MASK; REG32(CAN0_MCR) |= (CAN0_MCR_FRZ_MASK | CAN0_MCR_HALT_MASK); while ((REG32(CAN0_MCR) & CAN0_MCR_FRZACK_MASK) == 0X0); #ifdef YTM_CANFD_MODE_ENABLE // 修改 maxmailbox counts REG32(CAN0_MCR) &= ~CAN0_MCR_MAXMB_MASK; REG32(CAN0_MCR) |= 0X6; REG32(CAN0_MCR) |= CAN0_MCR_FDEN_MASK; // TODO 修改 CAN0_FDCTRL #endif // 使用晶振 24MHz 时钟源 REG32(CAN0_CTRL1) &= ~CAN0_CTRL1_CLKSRC_MASK; REG32(CAN0_CTRL1) &= 0X0000FFF8; #ifndef YTM_CANFD_MODE_ENABLE // PRESDIV RJW PSEG1 PSEG2 PROPSEG REG32(CAN0_CTRL1) |= (1 << 24 | 3 << 22 | 7 << 19 | 7 << 16 | 6); #else // EPRESDIV ERJW EPROPSEG EPSEG1 EPSEG2 REG32(CAN0_CBT) |= 1 << 31 | (2 << 21 | 1 << 16 | 4 << 10 | 7 << 5 | 1); // FRESDIV FRJW FPROPSEG FPSEG1 FPSEG2 // 按需修改 CAN0_FDCBT REG32(CAN0_FDCBT) = (0 << 20 | 1 << 16 | 6 << 10 | 2 << 5 | 1); REG32(CAN0_ERFCR) |= CAN0_ERFCR_ERFEN_MASK ; // 复位 FIFO 引擎 REG32(CAN_ERFSR) |= (1<<27); // TODO 配置 ERFCR 寄存器 NFE 和 NEXIF // TODO 配置滤波器表 0X3000 偏移处 #endif // 清零 RAM 区 for (int i = 0; i < 0X200; i++) { REG32(CAN0_MB0_HEAD0 + i * 4) = 0X0; } REG32(CAN0_RXMGMASK) = 0XFFFFFFFF; REG32(CAN0_RX14MASK) = 0XFFFFFFFF; REG32(CAN0_RX15MASK) = 0XFFFFFFFF; REG32(CAN0_RXFGMASK) = 0XFFFFFFFF; // 配置 RAM REG32(CAN0_CTRL2) |= CAN0_CTRL2_WRMFRZ_MASK; #ifdef YTM_CANFD_MODE_ENABLE // TODO 修改 CAN0_FDCTRL 为 64 bytes REG32(CAN0_FDCTRL) |= (CAN0_FDCTRL_MBDSR0_MASK | \ CAN0_FDCTRL_MBDSR1_MASK | \ CAN0_FDCTRL_MBDSR2_MASK | \ CAN0_FDCTRL_MBDSR3_MASK); REG32(CAN0_FDCTRL) |= (CAN0_FDCTRL_TDCEN_MASK); #else REG32(CAN0_FDCTRL) &= ~(CAN0_FDCTRL_MBDSR0_MASK | \ CAN0_FDCTRL_MBDSR1_MASK | \ CAN0_FDCTRL_MBDSR2_MASK | \ CAN0_FDCTRL_MBDSR3_MASK); // 设置 8 字节/ message buffer REG32(CAN0_FDCTRL) = 0X00; #endif // 关闭 Self Reception REG32(CAN0_MCR) |= 1 << 17; /* REG32(CAN0_CTRL1) |= 1 << 3; */ REG32(CAN0_MCR) &= ~(CAN0_MCR_HALT_MASK | CAN0_MCR_FRZ_MASK); return 0; } int board_can_send(const struct bl_can_msg *msg) { int ret = 0; if (!msg) { return -RT_EINVAL; } //1. 检查相关的中断 bit 是否置位并清零 //2. 如果 MB 是激活态，写 ABORT（1001）-> CODE /C/S，等待 IFLAG 置位，然后读回 CODE filed 并清除对应的中断寄存器 flag //3. 写 ID word //4. 写要发送的数据 //5. 设置 ide, 设置 rtr, 设置 dlc， 激活 MB REG32(CAN0_IFLAG1) |= (1 << 0); REG32(CAN0_MB0_HEAD1) = msg->id << 18; REG32(CAN0_MB0_DATA(0)) = msg->data[0] << 24 | msg->data[1] << 16 | msg->data[2] << 8 | msg->data[3]; REG32(CAN0_MB0_DATA(1)) = msg->data[4] << 24 | msg->data[5] << 16 | msg->data[6] << 8 | msg->data[7]; REG32(CAN0_MB0_HEAD0) = msg->dlc << 16 | msg->rtr << 20 | msg->ide << 21; #ifdef YTM_CANFD_MODE_ENABLE // canfd 帧 REG32(CAN0_MB0_HEAD0) |= 0xC0000000; #endif REG32(CAN0_MB0_HEAD0) |= 0xC << 24; return ret; }

相比原来的 can ，主要增加了修改 CAN0_FDCBT 和 CAN0_CBT（之前用的 CAN0_CTRL1），以及寄存器CAN0_FDCTRL和CAN0_MCR开启canfd。
canfd报文发送时，追加了 EG32(CAN0_MB0_HEAD0) |= 0xC0000000;。
请问是不是还有哪些遗漏项目没有修改？

请问，MD24的BOOTLOADER有例子代码吗， 特别是FLASH相关的部分的。

UDS FBL Demo合集参考：
https://forum.ytmicro.com/topic/1537/ytm32b1le04-uds-can-fbl公版操作指南

https://forum.ytmicro.com/topic/1201/ytm32b1le05-uds-can-fbl公版操作指南

https://forum.ytmicro.com/topic/1603/ytm32b1le05-uds-lin-fbl公版操作指南

https://forum.ytmicro.com/topic/1200/ytm32b1le15-uds-can-fbl公版操作指南

https://forum.ytmicro.com/topic/1641/ytm32b1le15-uds-lin-fbl公版操作指南

https://forum.ytmicro.com/topic/1199/ytm32b1mc03-uds-can-fbl公版操作指南

https://forum.ytmicro.com/topic/1202/ytm32b1mc03-uds-lin-fbl公版操作指南

https://forum.ytmicro.com/topic/1179/ytm32b1md14-uds-can-fbl公版操作指南

https://forum.ytmicro.com/topic/1180/ytm32b1md14-uds-lin-fbl公版操作指南

https://forum.ytmicro.com/topic/1257/ytm32b1me05-uds-can-fbl公版操作指南

https://forum.ytmicro.com/topic/1447/ytm32b1ha01-uds-can-fbl公版操作指南

3267ff79-0046-42c7-ac68-36eadc6efe15-image.png 你好我想问下我使用硬件CRC进行校验flashdrive的值，和上位机校验出来的值不一样。我再网按照手册上的CRC16 (CRC-CCITT):使用这个进行校验也不对。请问这个是需要怎么配置，但是我再demo中又和在线校验的又对上了。e4889ef0-5145-4e7c-ae14-fe04dc5d0d8f-image.png

1. 前言 在汽车电子领域，CAN总线通信是核心的数据交互方式。随着系统复杂度的提升，ECU节点往往需要同时接收和处理大量不同ID的报文。然而，受限于芯片成本和硬件设计，微控制器通常只提供有限数量的CAN接收邮箱（通常为32个或64个）。 当系统需要接收的报文ID数量远超硬件邮箱数量时，就会出现“邮箱不够用”的场景。如果处理不当，极易导致接收邮箱溢出、报文丢失，进而引发系统故障。针对这一痛点，本文基于云途YTM32B1LE05芯片，针对不同的报文特征和CAN控制器工作模式，提出了三种针对性的解决方案，并完成了Demo开发与验证，旨在为开发者提供一个设计参考。 2. YTM32B1LE05 CAN控制器基本介绍 YTM32B1LE05具备以下主要特性： - 最多32个邮箱。 - 支持经典CAN与CAN FD模式：CAN FD模式下支持最高8字节到64字节的数据场，可变波特率使数据传输更高效。 - 硬件掩码过滤：每个接收邮箱支持独立的ID和掩码配置，可实现硬件级别的报文过滤。 - 中断及FIFO机制：支持接收中断及硬件Legacy FIFO（深度6）。 3. 三种场景及原理介绍 根据报文ID的分布特征（集中或分散）以及CAN工作模式（经典模式或FD模式），邮箱不够用的场景可归纳为以下三种，其解决原理分别如下： 3.1 场景1：经典模式/FD模式，报文数量多，ID基本都在某个区间 - 原理：邮箱掩码过滤法 - 分析：当多个报文ID集中在某个区间（如连续的ID段，或高几位相同、低几位变化的ID群），可以利用CAN硬件的Mask（掩码）机制。Mask寄存器中置0的位表示“不关心”，置1的位表示“必须匹配”。通过配置一个邮箱的Mask，使其只校验ID的公共高位，忽略低位变化，从而实现“一个邮箱接收一组ID”的效果，极大释放了邮箱资源。 3.2 场景2：经典模式，报文数量多，ID比较分散 - 原理：硬件FIFO法 - 分析：在经典模式下，ID毫无规律且跨度极大，Mask方式无法有效合并。此时应将多个连续的硬件邮箱硬件邮箱区域配置为接收FIFO模式。在FIFO模式下，匹配ID的报文基本不会因为缓冲区填满而被覆盖，这种方式增加了接收缓冲深度，给予CPU更充裕的响应时间来统一读取和软件分发。 3.3 场景3：FD模式，报文数量多，ID比较分散 - 原理：软件轮询法 - 分析：在CAN FD模式下，由于报文数据场长度最大可达64字节，报文长度差异极大。由于MCU对硬件Legacy FIFO和FD的支持存在冲突）。因此，这里用单个邮箱对多个报文进行周期性轮询配置和接收，一旦检测到接收缓冲区有数据就转移数据并清空缓冲区，等待下一次接收，无数据则跳过。此方式牺牲了一定的实时性，但换来了FD模式下的兼容性。 4. 实现方式 4.1 场景1实现：邮箱Mask方式 实现步骤： 设置掩码类型为独立掩码。 设置一个目标区间的基准ID（如0x100）。 配置Mask寄存器，将需要忽略的低位设为0，必须匹配的高位设为1（如Mask = 0x7F8，表示低3位不关心，可接收0x100~0x107）。 配置接收邮箱。
39f40923-312e-4e94-aea9-18a820c980ba-image.png 测试结果： 向总线发送0x100~0x10F的报文，芯片均能正常触发接收中断。 区间之外的ID则无法接收。 4.2 场景2实现：FIFO方式 实现步骤： 将硬件邮箱Mailbox_0至Mailbox_17配置为接收FIFO。 配置FIFO的过滤方式为FORMAT A（所有ID位都过滤）。 配置滤波表
006422da-75d9-404d-ab4d-779efe7de07c-image.png
4acfa582-7eaf-4235-ae4c-c0ef8a2b9285-image.png
Legacy FIFO模式下，因为NumberofLegacyRxFIFOFilters（RFFN）最大为15，因此滤波表参数最多为（15 + 1）* 8 = 128个。 4.3 场景3实现：邮箱轮询方式 实现步骤： 先将邮箱配置为独立接收模式，单独配置固定报文ID。 在主程序中，同一类型的的报文（比如都是标准帧）可通过同一邮箱遍历所有TX ID和TX data的方式进行发送。 在主程序中周期性的切换配置接收邮箱，切换周期越短，丢帧率越低。 为防止总线拥堵时轮询周期不够导致溢出，可增加溢出标志位监控及错误恢复逻辑。 测试结果： 在CAN FD模式下（仲裁段500kbps，数据段2Mbps），发送ID分散的报文。 轮询周期设为100ms，数据均可正常接收。 在负荷率比较高的情况下，可能会出现单个邮箱溢出覆盖，但通过软件逻辑检测溢出标志位并丢弃旧帧，也可保证基本功能。 结论：轮询方式扩大了总线接收报文的数量，虽然实时性略有下降（取决于轮询周期），但在FD分散ID场景下也能实现了较为稳定可靠的数据接收。 5. 总结

YTM32B1Mx系列均有多路CAN控制器，且MD1/ME0/HA0均支持EnhanceFIFO，基本不会出现邮箱不够用的情况，一般L系列由于邮箱数量较少且只有一个CAN控制器，当开发者使用到FD模式时经常会邮箱不够用，在实际项目中，开发者可根据报文字阵的定义和总线负载情况，灵活选择或组合上述方案，以实现YTM32B1LE05 CAN通信资源的最优配置。

在提供的资料下载部分只找到Schematic_YTM32B1HA0_Q176_EVB_RevA的原理图，需要Schematic_YTM32B1HA0_Q176_EVB_RevB的版本

为什么WDG看门狗初始化后会响应我的DFLASH的存储，我只有部分数据有时候可以存储进去，WDG的timeout是1S，200ms喂狗一次。按道理每次写FLS不至于用1s吧，这个是什么原因。每次都会调用fls_erase,不开启wdg功能就可以正常存储，我这个是不带OS的

自己写的写 flash 函数，单次写 256 Bytes，循环写 flash 后再读 flash,容易导致如下错误

psr: 0x01000000 [22:12:35.756] r00: 0x20010ec4 [22:12:35.759] r01: 0x20010ec8 [22:12:35.759] r02: 0x02150100 [22:12:35.762] r03: 0x20010ec4 [22:12:35.762] r04: 0x0200ac05 [22:12:35.765] r05: 0xdeadbeef [22:12:35.765] r06: 0xdeadbeef [22:12:35.768] r07: 0x20010e38 [22:12:35.768] r08: 0xdeadbeef [22:12:35.771] r09: 0xdeadbeef [22:12:35.771] r10: 0xdeadbeef [22:12:35.774] r11: 0xdeadbeef [22:12:35.774] r12: 0x0000000a [22:12:35.777] lr: 0x02004101 [22:12:35.777] pc: 0x02008280 [22:12:35.780] hard fault on thread: main [22:12:35.780] bus fault: [22:12:35.783] SCB_CFSR_BFSR:0x82 PRECISERR SCB->BFAR:02150100

但是我如果在写之后，添加一定的延时，比如 1ms （实测过），就可以正常运行。请问可能是什么原因？

e11f70c6-308c-495d-969e-17ced455e1f0-image.png

1.MC03芯片如果设置flash编程和擦除时间为手册上最小时间，编程5us，擦除2ms；在重复写入flash有可能出现写入数据不完全导致触发ECC吗？

手动配置SPI0，SPI1无法正常收发，麻烦帮审核一下配置project.yct

下面是给LE1系列开发的LIN自适应波特率，支持interrupt和DMA方式

为什么我通过NVM写数据最后会调用FLS_ERASE，这个是为什么

修复Demo ：Lin_AutoBaud_Interrupt_Demo
修复版本 ：0.3 -> 0.4
问题标题 ：误将ptmr捕获的0值当作sync捕获开始
问题描述：中断版 LIN AutoBaud Demo 使用 s_previousCaptureValue == 0U 作为哨兵值来判断首个 Sync falling edge。
但 pTMR 是自由运行的递减计数器，TCV == 0 是合法硬件计数值。
如果某次边沿捕获刚好读到 0，下一次 falling edge 会被误判为首个边沿，导致 Sync 采样错位，进而可能造成波特率识别失败或 Sync error。
修改策略：改用 s_captureCount == 0U 判断首个 falling edge，不再复用捕获时间戳本身作为状态标记。
LinSync_GetCaptureDelta() 只负责计算两个有效捕获时间戳之间的 delta。

febe24c0-3930-46d2-8ce5-c7b1031948fb-image.png lin_autoBaud_0_4.zip

YTM32B1MC03的RAM故障和EEPROM故障，分别读取哪个寄存器可以获取故障标志？

ebe56ce3-bb8f-4493-8ecb-a7cc73673987-image.png

请问一下，MD24的引脚未配置的时候默认应该是高阻态，配置为disable时应该也属于是高阻态，但配置引脚时有部分引脚是没有disable的选项，那有什么办法可以手动将引脚配置为高阻态（目的是为了防止串电）
342e77e8-37ba-46f1-8a9e-141864af4bc8-image.png

667a5b6d-1117-4c38-b5bb-83a3d8530404-image.png

YTM32B1LE15H0MLFT配置boot_app公用RAM配置为POR_ONLY，发现软复位后该区域也会被ECC重置为5A，进一步调试发现RCU寄存器下面的POR_BOR一直置位，所以现在每次初始化RamInit0.S中都认为是Power Reset, POR_BOR或者整个RCU寄存器需要软件主动去清么，如果清放在哪个环节比较合适？