YunTu Forum

生成的MCAL只能发送8位数

我们现在使用SDK的CAN驱动，使用freeRTOS系统。在短接CANH和CANL低后触发CAN0_ErrorCallBack，中断类型为FLEXCAN_BUS_OFF_ENTER_EVENT。我们想在这个callback中去重置CAN驱动，但是在回调中调用FLEXCAN_DRV_Deinit和FLEXCAN_DRV_Init函数会卡死在断言中。请问这个CAN驱动的销毁与重新初始化有什么方法或者示例吗？
371a01a1-e926-4c7f-8983-7a443297cbe1-image.png

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

Highlight

Add MCAL_EB support。

Details [opt]:opt eb package download, parse EB version and package name [bug]:fix eb link [bug]:fix example level and demo list missing [update]:update eb mcal resource [bug]:fix tresos cmd path in cmake [bug]:fix eb code generate [bug]:fix cli mcal copy and copyMcal cmake generate [opt]:opt eb links display [feat]:add auto setup eb links to eb_mcal [feat]:add cli mcal eb support [feat]:add mcal_eb chip description [bug]:fix package release note address [opt]:opt document tree display [opt]:update iar multi cfg support, merge include and define on regenerate [opt]:update keil ide project generate, modify all targets when merge [bug]:fix open document block on linux

MC03的芯片ecc默认是开着的还是关着的？如果全擦flash后直接读取未编程区域会触发ecc错误吗？

SDK升级到最新的1_5_0,CMAKE的模板是否发生了改变？yt_link没有变动的情况下，重新编译出现了一个警告：
LOAD segment with RWX permissions
d037c36d-f4d0-4873-ab1a-f60b2a25010f-image.png
是否有影响？

3ac8a1bc-f684-4067-96eb-7ea10870adbe-04d164e384fd4c66c6fd5199fc2d1fed.png
如图：移植can协议栈后，收发器和控制器都正常的下 busoff 而且 不加协议栈 发送单个can报文是好的

环境：
YTM32B1ME15；
Yuntu MCAL 0.8.0；

1、问题

EEPROM 单比特 ECC 错误可由硬件纠正；双比特错误不可纠正，实测读取时会触发精确 BusFault，且先于 EEPROM 中断处理。仅在 EEPROM_IRQHandler 中处理，会因故障指令反复执行而升级为 HardFault。

MCAL 0.8.0 的 Eep 驱动提供 ECC 中断使能接口，但未实现完整的错误处理和日志记录。

2、处理方案

示例在应用层实现：

单比特：在 EEPROM 中断中记录错误地址、计数等信息并清除标志，数据由硬件纠正。 双比特：通过 RAM 向量表接管 BusFault，识别 EEPROM 不可纠正错误，按 Thumb-2 指令长度跳过故障读取指令，记录错误，并将错误地址按 4 字节对齐后擦除对应字。 前提：启动代码已将向量表复制到 RAM；示例在初始化时安装 BusFault 处理函数。 3、验证结果

实板测试中，正常读写、单比特纠错、双比特检测及后续重写恢复四步均通过：Eep_EccStepResult=0x01010101，Eep_EccTestFailCnt=0。双比特错误地址为 0x02000040，程序未再出现 BusFault 升级为 HardFault。
99d327fa-a27f-4ed0-9f2c-f750d5bfa25b-image.png
c455d210-b380-4896-a820-67683f11b28c-image.png

5、注意事项 跳过故障加载指令不会产生有效读取值。实测 Eep 作业仍可能返回 MEMIF_JOB_OK，不能仅凭作业结果判断数据有效。 擦除会破坏整个 4 字节字的数据，需由应用恢复；示例未向上层报告擦除超时或命令失败，且异常上下文操作 EEPROM 可能与 Eep 作业竞争。量产前须结合芯片手册验证失败处理及数据恢复。 错误注入仅用于测试，测试会写入并擦除 EEPROM 测试区域。 6、代码实现 6.1 初始化

main.c 初始化 MCU 时钟，随后 Board_Init 调用 Platform_Init、Fls_Init、Eep_Init 和 Eep_EccDemoInit。启动代码须先将向量表复制到 RAM 并设置 VTOR。

IVT_RAM_start[5U] = (uint32)Eep_BusFault_Handler; __DSB(); __ISB(); SCB->SHCSR |= SCB_SHCSR_BUSFAULTENA_Msk; SCB->CCR |= SCB_CCR_BFHFNMIGN_Msk; EEPROM->STS = EEPROM_STS_UNRECOVERR_MASK | EEPROM_STS_RECOVERR_MASK | EEPROM_STS_CMD_FAIL_MASK | EEPROM_STS_ACCERR_MASK; EEPROM->CTRL |= EEPROM_CTRL_RECOVERRIE_MASK | EEPROM_CTRL_UNRECOVERRIE_MASK; (void)Platform_SetIrq(EEPROM_IRQn, TRUE); 6.2 注入与读取

源码使用偏移 0x40、长度 8 字节，先写入测试数据。单比特模式为 1，双比特模式为 2，模式 0 关闭注入；Eep_EccReadJob 通过 Eep_MainFunction 等待作业完成。

EEPROM->ERR_INJECT_CTRL = EEPROM_ERR_INJECT_CTRL_ECCERR_INJ_EN(Mode) | EEPROM_ERR_INJECT_CTRL_ECCERR_INJ_ADDR(Offset); Eep_EccInject(EEP_ECC_INJ_MULTI_BIT, EEP_ECC_TEST_ADDR); Eep_EccJobResultAfterMulti = (uint32)Eep_EccReadJob( EEP_ECC_TEST_ADDR, ReadBuffer, EEP_ECC_TEST_LEN); Eep_EccInject(EEP_ECC_INJ_DISABLE, 0U); Eep_EccPollMultiBit();

上述寄存器赋值为非零模式分支摘录。注入仅供测试，示例会写入并擦除 EEPROM 测试区域。

6.3 BusFault 处理

应用的 naked 异常入口根据 EXC_RETURN 位 2 选择 MSP 或 PSP，将堆栈指针传给 Eep_BusFaultHandlerC。当前实现使用 pStack[6] 作为保存的 PC，下面为对应 C 代码摘录。

FaultPc = pStack[6]; if (0U != (EEPROM->STS & EEPROM_STS_UNRECOVERR_MASK)) { if (0x1DU <= (*(volatile uint16 *)(FaultPc) >> 11U)) InsnLen = 4U; else InsnLen = 2U; pStack[6] = FaultPc + InsnLen; Eep_EccHandleBusFault(); } else if (TRUE == Fls_Lld_GetTwoBitEccErrFlag()) { pStack[6] = FaultPc + 2U; } SCB->CFSR = SCB_CFSR_BUSFAULTSR_Msk | SCB_CFSR_PRECISERR_Msk;

重要限制：跳过加载指令不会生成有效读取值，也不保证 Eep 作业失败。

6,4 错误记录与对齐擦除

Eep_EccHandleBusFault 读取错误地址与计数，更新日志，关闭注入并清状态后调用 Eep_EccEraseWord。以下摘录省略地址范围校验及状态清理。

ErrAddr = EEPROM->ECCERR_ADDR; Eep_EccLog.MultiBitErrCnt++; Eep_EccLog.LastErrAddr = ErrAddr; Eep_EccLog.LastErrCnt = EEPROM->ECCERR_CNT & EEPROM_ECCERR_CNT_ECCERR_CNT_MASK; Eep_EccLog.LastErrType = EEP_ECC_ERR_TYPE_MULTI; Eep_EccLog.NotifyCnt++; EEPROM->ERR_INJECT_CTRL = 0U; EEPROM->STS = EEPROM_STS_UNRECOVERR_MASK; Eep_EccEraseWord(ErrAddr); WordAddr = HwAddr & (uint32)(~0x3U); WordPtr = (volatile uint32 *)WordAddr; EEPROM->CTRL |= EEPROM_CTRL_WE_MASK; /* 源码在写入前后执行 ISB 和 DSB */ *WordPtr = 0x00000000U; EEPROM->CTRL &= (uint32)(~EEPROM_CTRL_WE_MASK); EEPROM->CMD_UNLOCK = EEP_ECC_CMD_UNLOCK_KEY; EEPROM->CMD = EEP_ECC_ERASE_SECTOR_CMD; /* 轮询 DONE 或等待超时，然后清状态 */

擦除会破坏整个对齐字的数据。当前代码未向上层报告擦除超时或命令失败，且在异常上下文直接操作 EEPROM，可能与正在进行的 Eep 作业竞争；产品化前须核对芯片手册并验证失败处理和数据恢复，不能仅凭日志认定擦除成功。

6.5 EEPROM ECC 中断

EEPROM_IRQHandler 根据 STS 处理：单比特分支记录 RECOVERR 并清标志；双比特分支临时关闭 UNRECOVERRIE，记录并调用 Eep_EccEraseWord，最后清状态并重开。双比特读取可能先进入 BusFault。
6b63415c-6681-4394-8366-8aae3e5fef6d-ME15_ECC_EccErrorHandling_Demo.zip

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

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

113d88b482fcde05ce846b6edf73eece.png 815e55048d39ae6cb51a1ff9845273c8.png df95a6c06a90374515f95cbca02aa174.png f4681cf4fd63df666eaaf1a4c28b25cd.jpg aa50ad943f7c763898324324a8516794.jpg

4eadc0e8-9f86-4799-a734-47c988635326-image.png
打开Debug文件，识别不到device。改怎么解决

硬件V12
软件V7.82
烧录提示如下：
cc79a74fa41cd20f38029df05ac05883.jpg
烧录原理图部分如下
04b40674-20e1-48fd-9c5b-44a51e8afbd8-image.png
Jflash连接成功
6bfcd1dce9eaa741d516d2f55f08d5cc.png

md24的使用外部24MHz晶振，对精度，负载电容等参数有什么要求？

initData.pluginData.data is not iterable怎么解决

请问下我们有基于CANone或者ZCANpro的ME的UDS例程吗？

HA芯片
https://forum.ytmicro.com/topic/753/ytm32b1ha01-mcal-a-b-swap-demo及操作流程演示?=1757835311890
ME芯片
https://forum.ytmicro.com/topic/1367/ytm32b1me05-mcal-a-b-swap-demo及操作流程演示?=1757835311896
MD芯片
https://forum.ytmicro.com/topic/1402/ytm32b1md14-mcal-a-b-swap-demo及操作流程演示?_=1758161515875

MC03芯片的PTC5引脚初始化配置输出低电平，在上电后出现一段高电平是怎么回事？

背景

软件版本：HA0 MCAL 2_3_0
硬件：YTM32B1HA01 EVB

问题描述

I2C master I2C_STANDARD_MODE模式通信，如果主机未收到应答信号，SCL会持续保持低电平状态，直到下次开始通信。

问题原因

在从机返回NACK时，驱动中会调用I2C_Lld_MasterEndTransfer复位TX和RX FIFO，若通信速率较低，那么可能会出现硬件还没完成收尾动作软件便清FIFO结束传输的情况。

解决方案

I2C_Lld_MasterNACKDetEventHdl函数中在调用I2C_Lld_MasterEndTransfer清除FIFO之前预留超时时间，如下图：
7b336797-86f8-4894-bb2d-2923a6e5b7f1-image.png
[CddI2c_Master_Slave_Demo_YTM32B1HA0.7z](无效文件格式，允许的格式有：.png, .jpg, .bmp, .txt, .webp, .webm, .mp4, .gif, .hex, .bin, .s19, .elf, .zip, .patch, .pdf, .yct, .jpeg) CddI2c_Master_Slave_Demo_YTM32B1HA0 (2).zip

3.0.0 版本 mcal 的 core_cm33.h 文件中 __ghs__ 下的 __FPU_USED 和 __DSP_USED 没有考虑编译器选项，如下图
eadbc127-e4ca-44ea-8445-3038349ddfab-image.png

2.3.0 版本有做相关保护，如下图
1eaac383-21a8-49da-bfcf-5a8db7a4449e-image.png

影响：
编译器产生如下报错
6a5a0b49-775b-461d-8a5e-307a7d0e157b-image.png

影响点如下图，ytm_ccarm.h 中 __FPU_USED = 1 时使用的 __VMSR 函数和 __VFP_FPSCR 符号在编译器使用 -fnone 参数时不存在
13f2dc13-e468-4374-a8e5-fc2dff40b5a9-image.png

HA0 MCAL 2_3_0版本的ICU MPWM输入捕获不进中断bug

替换如下Icu_Lld_Mpwm.c中127行的for循环即可
code replacement.txt

bd60fd0b-14d9-45f8-a9a6-6534beaa827d-image.png 打开该模块之后出现编报错

96c19e26-b53c-48d6-b455-a98e41e77560-image.png 帮忙看下是为啥project.yct