32B1H代码移植之古怪现象

[yxydoctor]

之前在官方开发板上已经走完了主要流程，并进行了多次内测。
1 - 软件结构：二级BOOT+APP, 串口烧录
2 - MCU供电：5V
3 - MCU封装：LQFP176

现在工程样机已经焊好了，需要逐步把开发板上的代码移植到工程样机并加以完善。
1 - 软件结构：同官方开发板
2 - MCU供电：3.3V
3 - MCU封装：LQFP144

移植了两天，发现几个与官方开发板不一样的地方，无法继续推进。

现象1：时钟问题。MCU时钟的开启是在二级BOOT完成的，包括简单的CMU时钟检测，APP不做重复开启。这在之前的官方评估板上测试是合乎设计的，正常用片外晶振，CMU检测异常后复位，转为片内FIRC作为时钟源。
移植到工程样机后，二级BOOT的时钟检测是正常的，短接片外晶振后，复位并启用片内96M也是正常的。但在二级BOOT跳转到APP后，原本正常的片外时钟会变成片内的96M，且在IAR仿真环境下的软件复位后的复位次数会+2。这可以理解为第一次复位使用的是片外晶振，之后触发了CMU复位，切换到了片内96M时钟，造成两次复位。
工程样机跟开发板唯一区别是：工程样机用的是16M晶振，PLL到200M，开发板是24M晶振，另外就是一个5V，一个3.3V。
如果关闭CMU和时钟切换，BOOT跳转到APP后会死机，说明时钟应该切换；但不如BOOT不跳转，BOOT代码又是很正常的，说明片外晶振也没问题。
为什么跳转会把片外时钟整没了？评估板不存在这种现象。

现象2：CAN通讯频繁出现busoff现象，导致丢包严重。开发板之前测试的CAN通讯很正常。
开发板用的是CAN0，邮箱容量为128，工程样机用的CAN2，邮箱容量为64。接收报文为32条，后32条报文空间全部留给了发送，以简化发送判断。

很郁闷！

[yxydoctor]

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

[yxydoctor]

问题1的原因找到了。APP中需要主动设置XTAL引脚，大意了。
但PTB6，PTB7默认就应该是做XTAL用的，BOOT不需要设置这组引脚。

[yxydoctor]

意思是先设置PORT，再开启时钟么？好像不对头。因为PORT也是需要时钟的，怪哉

[yxydoctor]

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