应该是使用spi模块的2先模式吧，可以参考yct工具里面spi的single wire 这个demo
377bdcff-736c-4fb9-a3a1-f0bd84c77a78-image.png

必须通过etmr的overfollow中断来实现输出脉冲数量的计数，到达计数值后停止输出

yt0069 您好，还是没有找到YTM32B1LE14H0MLFT的原理图库和封装图库，方便再提供一下吗？十分感谢
db7875f8-e9bd-4091-aa23-e5074b991b46-F5N2W`YC83SV57_GIBLTY~Q.png

最后发现是输出保护用的稳压管造成的输入电压较高时ADC测不准。
稳压管换为二极管用于输出保护后问题解决

yishui66 HVA和HVB建议上电保持一致，或者HVB晚于HVA，限制条件是HVB电源域的IO不要早于HVA的供电，后面这一条是一个主要限制。

下段是demo代码，不知道是不是哪里配置的不对。
Spi_Master_Dma_Demo.zip

Frankie
可以了。问题解决了，谢谢！
这个DEBUG模式用了有几天了，应该是增加DEBUG模式后，一直没用到ytc，所以没有第一时间发现，多谢了。

Prot.h 里面提供了函数 Port_SetPinMode()，供用户手动切换。可以自己实现一个函数更改相关的引脚功能试试

两个硬件Group只能采用这种轮换的方式。

补充二点：
咨询了RTC厂家，对方做了类似测试，SCL，SDA多次短地后，其通讯能正常恢复。所以应该还是MCU侧，SCL短地后，通讯无法恢复，除非MCU复位

只要确定 DMA 没有去修改这个变量，或者你 debugger 没有修改这个变量，应该是没有影响的。
Cache 的问题，如果要分析，最好提供下能复现的简易软件

明白了。
读数据时I2c0MasterTx.BufferSize=1，重复写时I2c0MasterTx.BufferSize需还原

run
謝謝，成功了

问题2频繁出现的CAN busoff问题,也是由问题1引起的.
如果使用片内FIRC作为时钟源,can通讯时丢包概率会增加，估计还是FIRC精度不够造成的

使用J-Link Commander读取对应断点的代码mem内容，HEX文件一致，但是出现降频确实是因为代码断点过多导致的，感谢！

可以在 startup.S 内直接用汇编写 IO 翻转
另外 HA0 是有安全启动的

补充回复一下，
HA RM 手册这个地方存在描述错误：

image.png
所以DSK 中 ADC 驱动中需要修改为

image.png；
另外增加
image.png
是因为YCT 配置工具中FXOSC 的DEEPSLEEP enable 按钮无法生成代码。

image.png。
另外，在deepsleep 模式下，为了保证ADC 在持续监测，需要使用continuous 模式,不使能采样中断（防止进入无法休眠）。

image.png

结论趋同, 综合算力相当于一颗240M的M4,但会稍微快一点。

开CACHE后，开不开TCM，无明显变化。估计是因为200M的主频不够高。

开始打样了，希望一切顺利。