记首次硬件Bringup经历

背景

最近有一次机会可以去给一版新硬件做Bringup调试工作。之前一直在应用层和基础功能层，MCAL相关的工作做的很少。新硬件都是其他同事BringUp功能基本起来了我开发应用上的其他需求。

这次是给Z客户交样，硬件回板时间本来就紧，叠加两个假期，给软件的时间就更紧张了。本次新硬件变更点主要有：

1. 去掉了以太网，改为CAN通信。
2. 采用GMSL传输传感器数据。
3. 换了新型号的Flash和FPGA。

回板前做了什么准备

在回板前，电子已经释放了HSI，因此已经拉出了客户分支，按照电子给的HSI适配了HSI、Port、Flash的驱动、FPGA型号适配和参数适配等，编译可以通过。CAN通信+使用的MCU芯片，之前没有项目组合使用过，只能简单配置了一下。

BringUp Day1

坐到电子间下来，电子工程师正在量板子电压，确认板子状态是否基本正常。 后面说OK了就把板子交给我们调试。

开始准备预烧录包，这里出现了两个问题：

1. BOOT预烧录失败，提示Flash写入失败。
2. APP预烧录包加载不进去。

为什么预烧录失败：

• Flash型号换了，需要工具加载匹配的片外Flashloader。为什么我不知道？因为预烧录包制作工具没用Git管理，而是每个人根据项目配置自己整理了不同的脚本，而这款Flash的我没有，只在一个同事手上有，并且还得联系芯片FAE才知道的是谁有。

脚本工具一定要纳入Git管理。

为什么加载不进去

• 预烧录包里一个组件不匹配，但打包工具是个bat脚本，双击运行完后里面其实有报错提示，但是窗口很快就关闭了，因此没有注意到。

脚本在运行失败的时候，一定要加入停驻窗口和明显的错误提示，并且不能生成出产物。

预烧录包加载进去，让板子自己启动，观察串口日志，发现空空如也。但入口电流已显著增大，代表是有代码运行的，因此兵分两路，一个去看启动的原因，一个去看CAN的配置，通过加载ELF的方式先开始调节。

在CAN配置上，首先发现的问题是：
CAN收发器（1043）的EN和NSTB脚拉不高

为什么引脚拉不高：

• 刚开始以为是CAN的相关Port配置有问题，DIO通道配置错了，但后来检查发现Dio配置的IO正确，又去检查是不是代码里还有拉低的操作，于是改为循环拉高+回读检查，发现还是拉不高。
• 因此开始检查原理图，发现这里就是MCU的IO直连1043的IO，没有其他下拉控制了，因此电子去检查PCB连线是否有问题，软件去检查配置是否有问题。后来软件重新用万用表连电压，发现VBAT上没有电压，原来只检查了VCC这里是有供电。

软件不能听电子说电压OK，就排除这方面可能存在的问题。还是要自己多验证。

经电子重新贴了电阻之后，发现的第二问题是：
CAN上H和L有12V，远超正常电压。

为什么总线上有12V：

• 这个很好排查，因为总线上的节点就只有两个，即传感器和供电接线设备，后来发现供电接线设备为了适配其他客户要求，设置了在CAN总线上输出12V。关闭该设置就OK不再有该问题了。

要对自己带的供电接线设备有所了解！

第一天就这么结束了。

BringUp Day2

第二天开始看为什么无法正常启动的问题：

• 同时加载APP和BOOT的elf文件，发现在启动期间卡在Flash加载JEDEC ID这里，然后直到加载超时。芯片内部有个内部Flash，外部从XSPI有连外部Flash。刚开始和AI Debug的时候，首先怀疑的就是外部Flash，因此去量了外部Flash的SPI，发现没有CLK和片选信号，非常奇怪。
• 但后面增加调试变量发现，是内部Flash加载失败，屏蔽内部加载代码，加载就是正常的，如果内部Flash加载失败，不再加载外部Flash，因此总线上没有信号。
• 那么内部Flash为什么加载不起来呢，联系芯片FAE一起看，他们建议Attach上去看代码运行在哪里，发现代码运行的地址不在我们的代码里，而在Bootrom里，也就是BOOT0拉高导致的。为什么Boot会拉高呢，是因为调试板上多贴了一个电阻，导致Boot0引脚拉高。

在代码不知道在哪里的时候，应该通过Attach的方式去观察变量运行位置。也要和电子确认好各种他们提供的硬件的电阻是否空贴、Rework的情况。

BringUp Day3

第三天重新制作了新的预烧录包，APP启动现在正常了，但是又看到两个新的问题：

1. CAN通信上有很多错误帧
2. FPGA的bit加载预烧录第一次正常，后面上电加载就出现了加载错误。再预烧录后就又正常。

错误帧的问题后面一起讲。

为什么FPGA只有第一次能加载成功：

• 预烧录第一次能加载成功，后面都加载失败，感觉就是存放在外部flash的bit被破坏了。
• 什么功能会在每次上电后，在没有外部操作的时候会去写Flash呢，很容易想到的就是各种日志。立刻去检查Log模块的Flash划分，发现还是原来8M的划分，而不是当前使用的新的FLash 16M的划分。修改完后重复多次上电，Bit都正常加载了。

此时项目节点到了，软件的BringUp变成了项目的卡点。其他工序都在等软件的预烧录完成。而预烧录最重要的功能就依赖于CAN通信能让软件OTA上去。

BringUp Day4-5

这两天都在集中看CAN的问题。主要难点在于：这条路上的链路太长，从MCU的CAN控制器，到1043的收发器，再到总线上串接的CANoe和接线设备。

单独测试的时候，感觉每一个都有点小问题，但又不是那么重要，尝试过测量TXD和RXD的延迟，130ns是比较正常的。测量过TXD和RXD的电平，偏小（480ns对500ns)，尝试换CAN波特率参数，检查CAN总线上的波形也基本比较正常。

问题的表现在于，总能在总线上通过CANoe接收到错误帧和发现错误信号，包括Stuff error，crc error，或者明明发送了64字节，但是读取DLC发现是32字节的，因此解析也变成了32字节。这非常奇怪，就像是发出的信号被自己就解析错了。

偶尔换到一组好的参数上面，但是只要采样率偏移5%，就会发生错误帧，容差非常低，如果在真实总线上很容易出现问题。

问题最终定位在，由于接线设备的软件的采样点和MCU配置的采样点不一致，导致接线设备偶发的发现采样错误，因此发送主动错误，干扰总线读取。而之前一直判断是MCU发出的错误帧。

这里做了大量的对比实验，比如将CAN Trcv替换到其他的型号上，也出现了这个问题。这里就不表了…

问题的解决办法包括：

1. 增大MCU的port驱动强度
2. 更换波特率配置，精细化调整了seg1 seg2等参数
3. 确认使用正确的监控参数采取电平
4. 暂时去掉接线设备的CAN，之后更改内部软件和MCU的采样点配置成一样的。

排查的时候，要按照先按能不飞线改硬件的方案，最小改动一波一波验证。这次犯了个错误是，电子飞线回来后，上电就有大电流灌入调试器，排线巨烫，导致硬件也无法使用，大大干扰了排查进展。。。

最后还有一个发现，两个调试器（JLINK），里面的供电引脚配置的不一样，有的配置成JLINK不供电，有的配置成JLINK供电，而JLINK供电的时候，外部又在供电，这就很容易导致其他硬件问题。

欸，很抓马的一次BringUp，想说的还有很多，但是不想继续写了，后面对CAN的理解有加深了在补充点吧。总之就是“何晨光的武器不能捡起来就用”哈哈哈哈。