YunTu Forum

使用ICU模块过程中，同时控制电磁阀打开 ，使用示波器检测ICU输入端频率，正常输出，但是ICU采样偶发异常，可以帮忙看看吗。

请问后续是否有会有相关例程释出？

YTM32B1LE04使用LE05的CAN_UDS_Bootloader升级时，在下载Flash_Driver_LE05_0x20003000.s19会出现响应错误，是否FlashDriver出现问题5f955cbc-5f19-4294-a01d-4e252a0c86d0-image.png

使用 ME0 MCAL 2_2_0 Platform_InstallIrqHandler 注册中断函数失败
如果OldHandler填NULL_PTR就会注册失败
在PLATFORM_DEV_ERROR_DETECT开启的时候必须给OldHandler传入值，这个是规范限制吗？
bd90179f-d86b-4814-8e5e-6c640a1f80c9-image.png

有人使用过ZCANPRO上位机刷写，demo使用的是论坛的MC03的UDSfbl的吗？在使用的时候出现此问题。04fdf68b-6dfa-408a-acf8-db0d1d487392-image.png 48f2667d-dbdd-45eb-9afb-f03632c92218-image.png 下位机没有响应超时。demo是同星的上位机。

YTM32MD1系列ADC带不带自检举，或者哪个型号带？

7ce43bbc-f46a-4b55-a3c2-864498170d99-image.png 调用spiint时在如图位置执行完会进入硬件故障，怎么排查初始化失败原因呢d2845652-d201-44f6-85b4-3a14fcedaf02-image.png

VS code编译时找不到yt_linker.ld文件，路径正确13895422-b1a6-46ac-ab35-d125e50f35ee-image.png

请问YTM32B1MD1支持什么品牌和型号的刻录器，另外要如何产出对应的刻录档案?

我使用的是轮询ADC采样，配置是这样子的8f5c3e5e-0ce9-4522-94b7-5d823fcc57af-image.png ，然后初始化温度通道c998359a-b064-40b5-a79d-8059c49c5293-image.png f47dab73-6658-4dbf-b1bb-3313be5468d5-image.png ，当我去读取内部芯片温度的时候，我其他两个通道AD值会被温度这个值影响到。不初始化温度这两个就可以正常读取到正常。也能正常变化。

1. 问题背景 软件：MD14 MCAL2.3.0 CddI2c_Master_Demo 硬件：MD14 EVB 背景描述： 客户测 I2C 设备的失联恢复，及将 I2C 的 SCL 对地短路，然后恢复，检测恢复后 I2C 总线是否可以正常通讯； MCU 的 I2C0 Master Mode，I2C 收发使用同步模式 客户将 I2C 的 SCL 对地短路，恢复后 I2C 总线无法正常发送 2. 问题分析 2.1 问题复现 使用 CddI2c_Master_Demo 进行复现，使用逻辑分析仪抓取波形 原工程： #define I2C_RX_MODE (I2C_TRANS_IN_SYNCMODE) 修改后： #define I2C_RX_MODE (I2C_TRANS_IN_ASYNCMODE) 正常烧入 CddI2c_Master_Demo 到 MD14 EVB 板后，将 SCL 对地短路后进行测试。SCL 对地短路后 SCL 电平呈现常低，SDA 电平呈现常高，松开 SCL 对地短路后 SCL/SDA 电平均为常高，但 I2C 总线通讯失败

ae455856-9c93-4b7f-8810-b5a8bbd6a1c7-image.png

将 SCL 对地短路后 Debug 查看 I2C 寄存器，MSTS -> BUSY 位置 1，I2c_MasterHwStatePtr = I2C_CHN_BUSY_STATUS。

065b8965-524f-4213-b792-5e0d178ac1bb-image.png

I2C 发送 API CddI2c_SyncModeTransfer 函数里会判断 I2c 状态，此时 TempChannelStatus = I2C_CHN_ERROR_PRESENT 的情况下 API 是不会调用底层发送，所以 SCL 对地短路恢复后，I2C 总线通讯依旧无法恢复。

bd6e1fae-6a40-4279-9308-63f6c49d95c2-image.png

2.1.1 排查方向一 推测是 I2C TOCFG Register 对 SCL 和 SDA 的常低检测导致的 SCL 对地短路恢复后总线通讯失败。但 TOCFG -> SDA 位为 0 的时候只检测 SCL 低电平超时时间，TOCFG -> SCL 位为 1 的时候检测 SCL 和 SDA 低电平超时时间，因此 SCL 低电平超时检测是无法关闭的

ae41bf8d-ee9f-4927-98f3-d28b9f3928d7-image.png

在 I2C_Lld_MasterConfig 函数里将 I2C_Lld_MasterFeatureConfig 注释掉后，TOCFG -> SDA 位就不会被置 1，SDA 的低电平超时将不会被打开，此时使用逻辑分析仪抓取 I2C 设备的失联恢复的波形

60fdd1ee-8b6d-49f6-9738-b4590b8b8dba-image.png

将 SDA 对地短路后进行测试。SDA 对地短路后 SDA 电平呈现常低，SCL 电平呈现常高，松开 SDA 对地短路后 SCL/SDA 电平均为常高，但 I2C 总线通讯失败，此时 SDA 常低检测处于未打开的情况，所以可以排除低电平超时导致的 I2C 总线发送失败的推断

243b7060-38c5-4440-809b-ce9d8ea37e8e-image.png

2.1.2 排查方向二 推测是总线死锁导致的 SCL 对地短路恢复后总线通讯失败。参考 SDK 总线死锁的解决方案“https://forum.ytmicro.com/topic/603/i2c%E6%80%BB%E7%BA%BF%E6%AD%BB%E9%94%81%E9%97%AE%E9%A2%98%E4%BB%8B%E7%BB%8D”

943959a4-8371-4b4f-a1e4-d6f367d98502-image.png

按照死锁的方式处理，SCL 对地短路恢复后，MCU 将 SCL配置为 GPIO，并输出 9 个 CLK 信号。实际测试也无法回复 I2C 总线通讯。 3. 解决方案 方案一： 检测 I2C 状态为 I2C_CHN_ERROR_PRESENT 的情况下，先反初始化 I2C 后，再重新初始化 I2C 即可恢复

efd0d3dd-3ad2-43e1-bc0b-5afe70d7c8e2-image.png

方案二： CDDI2C MCAL 配置里 I2cBusIdleTimeout 配置是超时的配置，默认是 0（不开启），但当前版本测试开启后不生效。当前驱动没有检查这种情况的一个处理，后续 MCAL 版本更新后会修复

88c1d22c-5a8b-4f02-a759-380049a8adb7-image.png

1. 问题背景 软件：ME05 SDK 1.3.1 I2C 硬件：ME05 EVB（FXOSC 8M） 背景描述： I2C 做从机的情况下，主机执行主机写（不带停止位）+主机读（带停止位），理论上 I2C Slave 中断回调中的 I2C_SLAVE_EVENT_STOP Case 只会在主机读完后进入，但实际上在主机写完的时候也进入了。

3a4a6966-d46a-478d-962e-483d51af2aba-image.png

对 PTD4 的 IO 反转操作只在中断回调函 I2C_SLAVE_EVENT_STOP Case 里操作

4eecfcb4-3268-489c-b593-83364142c0e0-image.png

2. 问题分析 根据 I2C 驱动可以确认 I2C_SLAVE_EVENT_STOP 有三种条件会进入：① 重复接收起始位; ② 收到到错误 ；③ 总线上有 stop bit。也确认客户 restart 指令属于 重复接收起使位（repeat start ） 2.1 重复接收起始位 I2C_DRV_SlaveIRQHandler 函数中 repeatStartDetect 就是对 重复接收起始位 情况的判断。当 repeatStartDetect 置 1，会执行 I2C_DRV_SlaveEndTransferHandler 函数，然后通过回调函数进入 I2C_SLAVE_EVENT_STOP Case

642f4da7-2bed-45cc-a3df-70f6b6f7a83a-image.png

6baa01ba-aae4-476e-8140-7dd5b467bae0-image.png

2.2 收到到错误 I2C_DRV_SlaveIRQHandler 函数中会判断 BitError 和 FIFOError。当 I2C 从机出现错误的情况下会执行 I2C_DRV_SlaveEndTransferHandler 函数，然后通过回调函数进入 I2C_SLAVE_EVENT_STOP Case

5dbae1b4-3f09-45bf-a233-8af26c301a8e-image.png

2.3 总线上有 stop bit I2C_DRV_SlaveIRQHandler 函数中 stopDetect 就是对 总线上有 stop bit 情况的判断。当 stopDetect 置 1，会执行 I2C_DRV_SlaveEndTransferHandler 函数，然后通过回调函数进入 I2C_SLAVE_EVENT_STOP Case

0ed833cd-cca7-45c8-94b8-2cc167162aaa-image.png

3. 解决方案 3.1 Plan A 如果不需要使用 重复接收起始位 进 I2C_SLAVE_EVENT_STOP，并且 I2C 不是使用 DMA，并且使能了监听的情况下，可以直接把 I2C_DRV_SlaveIRQHandler 函数里 repeatStartDetect 的 I2C_DRV_SlaveEndTransferHandler 函数直接注释即可

66ffd82f-a1b2-460c-bc53-86a759950397-image.png

关于 I2C 产生 error 也进入 I2C_SLAVE_EVENT_STOP，可以在回调函数 I2C_SLAVE_EVENT_STOP Case 里调用 I2C_DRV_SlaveGetTransferStatus 函数获取 i2c 状态，如果产生 error 函数的返回值是 STATUS_ERROR，因此可以通过返回值去判断是否发产生 error

6f2c71f9-2cfa-41cc-903b-9b3e83494c2c-image.png

注意事项： 此方案对 SDK I2C 驱动修改程度最小 此方案会导致主机发送主机写并且不发停止位情况下，无法获取主机写命令什么时候接收完成 3.2 Plan B 在 I2C_DRV_SlaveIRQHandler 函数里调用 I2C_DRV_SlaveEndTransferHandler 函数的位置加 log

92ea1753-181c-4b3c-bf95-8fc343c93fef-image.png

然后在回调函数 I2C_SLAVE_EVENT_STOP case 里去判断对应的 log，然后做相应的处理

0784d907-3432-4663-952b-19180284adff-image.png

注意事项： 此方案对 SDK I2C 驱动修改程度较大

1. 问题背景 软件：ME0 SDK1_3_1 I2c_Master_Demo 硬件：客户板子 or ME05 EVB 问题描述： 客户调用 I2C_DRV_MasterReceiveData 函数发送会触发 HardFault。 客户代码逻辑是当识别到芯片有报 fault 持续 1-3s 然后重新走上下电时序（处 MCU 外，其他外设芯片执行上下电逻辑），I2C 4.7K 上拉电阻的电源也会重新上下电，此时 I2C 总线 SDK 和 SDA 也会同步拉低再拉高，拉低持续时间有 800ms 左右。 I2C 外设芯片上下电后，MCU 会调用 I2C_DRV_MasterReceiveData 函数，此时若使用 I2C_DRV_MasterGetTransferStatus + while，需要获取返回值为 STATUS_SUCCESS 才能跳出循环，但此时由于 SDK 和 SDA 拉低时间超过寄存器 TOCFG -> LOW 设置的最大时间，寄存器 MSTS -> TOIF 标志位会置 1，I2C_DRV_MasterIRQHandler 函数里会将 master->status = STATUS_I2C_LINE_LOW_TIMEOUT，此时会一直卡在 while 函数里出不来。 如果把调用 I2C_DRV_MasterReceiveData 函数后，I2C_DRV_MasterGetTransferStatus + while 等待接收完成去掉，则会触发 HardFault。但当 RXBUFF 数组由局部变量改为静态局部变量或全局变量后，不会触发 HardFault。 2. 问题分析 2.1.1 Line low timeout detected 超时分析 先确定 TOCFG -> LOW 设置的最大时间是多久，是否真的是拉低时间超时后，导致的 MSTS -> TOIF 标志位置 1。 在 I2C 初始化的时候，I2C_Set_MasterLineLowTimeoutPeriod 函数会将 LOW 的值设为 0xFFF。

9ee02551-35ae-4b04-9bba-81aa137f1b7a-image.png

时钟为 8M，LOW 值为 0xFFF，根据公式计算，（4096 * 256）* (1 / 8M) = 131ms，而实际拉低时间是 800ms，确实触发超时，MSTS -> TOIF 标志位置 1，理论与实践现象一致。

375c9480-42ca-4ca5-91f6-b53a79ea1109-image.png

2.2 HardFault 原因分析 使用 I2c_Master_Demo 例程，模仿客户代码调用方式对问题进行复现

1039cc8a-d408-45fd-ae82-0f45fba727b3-image.png

实际 Debug 确定可以看到，当出现 HardFault 时，I2C 未接收完成

6efa2f84-3a91-463d-b83e-072daf4ae7d9-image.png

1c1d7221-a043-49f3-b655-ac9467f5b130-image.png

当更改 RXBUFF 为静态局部变量后，就不会出现 HardFault ，其 I2C 通讯波形是完整的，有起始位和停止位。

0692b417-fdf7-40f1-b3e2-b9ee7fae7f2c-image.png

3e2712aa-bfb1-41e7-bbde-6d5e7037e0cb-image.png

出现 HardFault 后观察栈空间以及修改栈空间大小均无效果，可以推断堆栈未出现溢出。RXBUFF 数组仅修改变量存储位置，即可避免 HardFault 出现，推测跟变量的存储位置及生命周期有关系，由于局部变量在函数执行结束后就释放了，可能是 i2c_Read 函数已经执行结束了，将 RXBUFF 数组释放了，但由于 I2C 接收还未完成，但接收 BUFF 已经被释放了，但此时还在给 RXBUFF 收数据，所以触发了 HardFault 。 在 i2c_Read 函数里和函数执行完成后分别设一个标志位，当出现 HardFault 的情况时 asd[1] 已经置 1 了，此时 i2c_Read 函数执行完毕 RXBUFF 数组已经被释放了，但此时 I2C 通讯还未结束，还在给 FIFO 写数据，所以触发了 HardFault 。

614f878d-7414-44e1-9f1a-c6217d339793-image.png

3. 问题总结 使用 I2C_DRV_MasterReceiveData 函数时，必须使用 I2C_DRV_MasterGetTransferStatus 获取 I2C 状态，同时记得 I2C_DRV_MasterGetTransferStatus + while 等待的时候记得加上超时机制。

9187f2f8-2da6-43e5-ae5b-a780d563a5d0-image.png

也可以将 RXBUFF 设置为全局变量或静态变量。

1. 问题背景 软件：MD1 SDK 1_4_0 I2c_Slave_Demo
I2c_Slave_Demo.zip 硬件：MD14 EVB or 客户板子 问题表述： I2C 从机模式时，客户想在回调函数里做处理，但不清楚回调函数里 Case 的使用情况。 2. Case 说明 I2C0_SlaveRxCpltCallback 函数 /* 伪 C 语言代码，直接编译会报错 */ void I2C0_SlaveRxCpltCallback(i2c_slave_event_t event, void *userData) { /* Get the instance number from userData */ uint32_t instance = 0; (void)userData; /* Depending on the event received, set the buffers or abort the transfer */ switch (event) { case I2C_SLAVE_EVENT_RX_REQ: /* * If the bus master requests data, then set the destination RX buffer * and accepted transfer size */ I2C_DRV_SlaveSetRxBuffer(instance, slaveRxBuffer, BUFF_SIZE); break; case I2C_SLAVE_EVENT_TX_REQ: /* * If the bus master sends data, then set the source TX buffer * and accepted transfer size */ I2C_DRV_SlaveSetTxBuffer(instance, slaveTxBuffer, BUFF_SIZE); break; case I2C_SLAVE_EVENT_TX_EMPTY: /* * If the TX buffer is empty. Because the example does not handle * this case there is no action taken. */ case I2C_SLAVE_EVENT_RX_FULL: /* * If the RX buffer is full, check the slave receive buffer is correct */ break; case I2C_SLAVE_EVENT_STOP: /* * This case is used when a stop condition is on the bus. Because * the example does not handle this case there is no action taken. */ break; } }

0b7d3fa6-05ae-4356-8070-568980a9a476-image.png

3. 获取接收 Data 的个数 使用 I2C_DRV_SlaveGetTransferStatus 函数可以获取 Data 接收的个数，I2C_DRV_SlaveSetTxBuffer 函数的第三个参数是当前 rxSize 的剩余长度，接收长度（已知） - bytesRemaining 得到当前接收了多少字节
9dfa6e82-5e74-4d8f-8b15-13ddddb62ded-image.png

一、背景：
使用MCAL开发，版本为2.3.0
目前SPI配置为一个Sequence里面有一个Job,一个Job里面有两个Channel
调用顺序为先调用Spi_SetupEB再Spi_SyncTransmit

二、问题点：
①一个Job下配置了两个Channel ,在发送的时候片选信号未持续拉低
69022cf2-5c81-4eaa-8a64-28ad4ff7ee99-f86bbafeb72020994888d59a8261902d.png

②SPI channel的默认值，只有第一个字节生效（发送数据指针为空），并且Channel实际是要发送8个字节
0994ad48-a7ff-4b93-8ecb-0638ae30b9ff-4dddab3168dfc71bc9c6e20afdbdb278.png

针对上面两个问题，是YCT上哪些配置设置的不对导致的吗？该怎么修改或者有其他建议呀？ 谢谢答疑

使用MCAL_demo工程，VS可以停止，IAR不行，调试时暂停程序，mcu仍然运行

在使用Fls_Erase和Fls_Write函数后，通过查看memory窗口可以看到擦写成功了，但是执行完函数后会报错，在位置0x10000会出现这种情况，在地址0xF0000就不会有，这两块地址都不在我程序定义的地址范围内，为什么会出现这种情况f5dd5ab0-07ab-45bd-9e33-a1b274350aff-image.png

7ddee6e0-442c-42f9-9ecb-94babc7af349-image.png

想萃取出arxml文件，导入bsw层配置工具

我是新注册用户，我的权限中没有YTM32Z1，现在需要下载技术资料和开发板采购。