开发过程中遇到的问题 自用

1、MCU休眠唤醒功能中，关于唤醒源相关tips

---

问题1 原因分析：

休眠策略通过CPU初始化后IO上下翻转以此体现是否成功reset.
但是在休眠的时候会使能使能PADKEEP功能，保证IO在休眠过程中保持原来的电平状态，因此在复位后如果没有设置normal_mode，IO仍然hold。

解决措施：
①在IO初始化前调用Disable_KeepHold接口
②MCU初始化后设置正常工作模式

问题2 原因分析：

现象
休眠后若复位源为RTC 定时唤醒，需要使能RTC的时钟在standby模式下的时钟功能，否则在待机模式下RTC无法工作

因为RTC/RTI的时钟源只有SIRC(Slow Internal RC Oscillator），在低功耗模式下只有SIRC和FIRS可以被正常使能工作。

解决措施：
①在时钟配置代码中打开SIRC_STANDBY_CLK，

---

2、MCU的Flsh模块问题总结

问题1 HardFault

问题描述：
今天在排查S32k118的boot在擦写过flash后造成的hardfault、且该hardfault在擦写操作完之后并不会产生，需要restart之后才会报错。

排查过程：
1、现象
makefile生成的text大小为47300字节（boot大小），加上flashconfig配置文件48.5k字节大小，boot的相关信息从第49k开始记录擦写，理论上并没有问题且空间足够不会影响前面。flash的擦写单元每次2k ，可以保证擦除的是49k和50k内容的地址，不会向前影响，那为什么会产生hardfault呢？
在复位后我发现产生hardfault部分的函数所在的ram地址值为0，显然被擦除了。复位前运行超过擦写操作前可以确认ram地址值存在，但是复位后变成了0xffffff。
2、排查结果
在48.5k字节后面仍存在着一部分数据，且该数据就是flash的擦写（因为与ram段函数值数据相等），当从49k开始擦除时，该部分flash的值被擦掉了，但是ram部分的值没有被擦，于是依旧可以正常擦写，重新复位后ram部分的值掉电清0，原本flash段的值不存在了无法拷贝至ram段，于是当cpu访问该段函数时为空自然产生了hardfault。
3、遗存问题
为什么在48.5k后面仍然存在着一部分flash数据，且离正常使用的flash段远远隔了很多字节，一般不会超过那么多字节去看下面数据，所以很难发现！