来源：公众号【鱼鹰谈单片机】
作者：鱼鹰Osprey
ID ：emOsprey
大家好，我是鱼鹰。最近鱼鹰遇到一个比较奇葩的事情，聊聊，让大家避避坑。
鱼鹰在 yocto 下编译的 STM32H7 程序升级到机器上时，SPI 通信异常，在两个同事电脑上编译的运行正常，不过没有使用 yocto 编译环境。
这让鱼鹰很纳闷，一时半会没明白为什么。
使用 git log 对比了主仓库节点、子仓库节点，都是一样的。
没道理......
于是鱼鹰想从 map 和 bin 文件入手，对比差异，发现两个 bin 和 map 差异比较大，不太好比较。
因为如果交叉编译工具链和有些文件的特性（如添加编译时间）确实会导致 map 和 bin 有些差异。
实在没办法，只能上调试工具了。
自己的坑，无论如何也要填上。
事实证明，在线调试永远是第一开发利器（不接受反驳）。除了搭建调试环境废了一点时间，定位问题只花了几分钟就搞定了。
调试发现，spi 相关的函数被我以前因为某种原因屏蔽了。另外还有几个文件都有修改，因此导致最终的 bin 文件功能不正常。
当时鱼鹰在查看节点时，只看了 git log 的信息，主仓库因为使用 vscode 可以很好的查看仓库的文件修改情况，但是子仓库却没那么容易，特别是这个子仓库和主仓库属于同一级目录。
因此如果当时查看模块时，能使用 git status 确认就不会遇到这个坑了。
其实这个坑很早就埋下了，鱼鹰在更新子仓库时，使用的是 git pull 命令， 这个命令可以拉取库上最新的提交代码，如果你没在当前分支提交任何内容，只是保持和远端提交一致的话，即使你工作空间的文件有改动，也不会有任何提示，从 git log 看就是拉取远程代码正常，节点正常。
这个特性可以在我们修改一些代码时，不需要特意暂存这些修改，方便开发，但如果像鱼鹰一样疏忽大意，只看节点（git log），不看状态（git status）的话，就会踩坑。
希望鱼鹰本次踩坑经验对大家有所帮助。下次再见。
带论文文档1万字以上，文末可获取，系统界面在最后面)
