补充二点：
咨询了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的主频不够高。

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

BJX
这里进行了压栈，因此是+8的
807de063-0c39-45e3-83d2-1eaa3d0b4424-image.png

确实可能会存在不同编译器导致编译出来和预想不一致的情况。
可以使用下面附件中的做法，这样更好想一点。
flash_ecc_fault.zip

上一个问题：
需要将EFM配置里面全局中断配置为disable，进行关全局中断处理。
因为在进行flash0 erase操作时，访问了pflash0上的代码（systick中断），这样访问读取时误触发了ecc 错误。其实是没有ecc错误的。

8bc34ebe-419c-4bd9-96c5-81f347a2ff11-image.png

major 谢谢。
追问一下，像这种热复位保持的寄存器还有哪些？RM里面有详解么？

之前使用其他家的MCAL，这块是可以这样连续发送的，可以提高传输时间。好的，这个修改方式我们验证下，感谢~

major 感谢您的回复，我调整了一下 WKU_DRV_SetPinIsolation(false); 的位置（放到打印之前），程序运行确实与预期相符了

Fee的操作跟Fls是一样的，他的操作函数都是异步函数，需要调用Fee_MainFunction来进行调度和状态管理，同时由于Fee需要调用Fls的操作才能实现数据存储与读取，因此调用Fee_MainFunction的同时，也需要调用Fls_MainFunction

在 ByPass 了 Secure Boot 后，这个启动时间应该不会太长，你可以根据你自己的配置手动量一下，从RST 释放到 SPI 初始化完成

感谢您的反馈，此问题源于配置文件的判断逻辑设置错误，会在后续版本迭代中完成修正。