LPC55S69配置usb非对齐访问问题与排查经过

az158

背景：昨天调试LPC55S69的USB部分，使用MCUXpresso Config生成hello_world工程后直接配置。程序无法正常运行，而官方例程是可以的。去论坛跟NXP官网找了找，没有找到类似的问题。

现象：插到电脑USB接口不可以发现，但是应该有数据通信(手上没有usb分析仪无法进一步分析)，过一段时间后提示无法识别的USB设备。

环境：keilV5.33；
MCUXpresso Config Tools v10；
SDK_2_10_0_LPCXpresso55S69

排查过程：1.首先对比了一下官方例程与MCUXpresso Config配置出来的工程代码区别，发现虽然写法稍有不同，但是代码本身逻辑是相同的。

2.对代码进行仿真调试，没有进HardFault_Handler，程序跑到一个很奇怪的地方，但是因为之前调试某一家的芯片有部分代码未提供源码，跟这里现象是一样的，就没有再细看（这里如果多看几眼，就能省下下面很多的时间）。

3.扩大堆栈，跟例程相同，也是无果。然后使用了笨方法进行代码替换，将自己工程的文件一个个替换为例程的文件。替换完文件后，替换配置。花费近半小时终于得到了结果。在编译命令栏中追加-mno-unaligned-access命令，问题解决。

4.细细分析问题。-mno-unaligned-access是指关闭代码的不对齐访问（并不是指关闭芯片的哈）。继续实验代码不追加-mno-unaligned-access当优化为0的时候代码正常，当优化为默认配置1的时候，代码不正常。
看了一下调试信息，发现了问题（最开始就该仔细看一下）。

看看这函数的嵌套(后面进度条还很长，无限嵌套)，最后停在一个莫名其妙的位置。追寻最后一次运行位置。

如果只看C部分是什么也看不出来的。需要对汇编进行分析。

1. LDR r1,[r0,#2]

复制代码

LDR是一个32位取数据的命令。也是支持非对齐访问的命令(芯片自己会拆成两次访问进行)。
这句汇编的意思是将地址为r0+2的地方的一个32位的数读到r1寄存器，嗯，也就是0x401001C0+2这个地址，正好是非对齐访问。一般来说也没事。但是

好巧不巧的是，这一段地址，不支持四字节非对齐访问。然后就出现了上边无限嵌套的问题（我也是醉了）。
关于此问题，小恩GG发布过的一篇文章是有提及的LPC55:使用USB RAM切记要字节对齐访问。

最后闲扯一下，一般来说，编译器会尽量避免非对齐访问的问题。因为非对齐访问会影响效率，而且因为实际是两次操作，因此对于那种易变的寄存器来说还是比较危险的。

一般情况下，只有在使用指针强制类型转换的时候才会出现。而不支持非对齐访问的是ARMv6架构，也就是我们常说的M0、M0+(还有一般人不是很清楚，用于fpga的M1架构)，我们经常使用的ARMv7架构的芯片，就是M3、M4、M7它们，都是支持非对齐访问的，也就是一般不会出现上文的问题。

而且这个问题是可以代码去解决的，通过加修饰的方式，告诉编译器这里有可能出现非对齐访问（有时间我会看一下，看看具体的问题代码出现在哪里，试着解决一下，毕竟关了这个之后，代码效率是要降低的，因为对齐访问的代码也受到影响。嗯，咕咕咕）。

更有意思的在keil官网对-munaligned-access, -mno-unaligned-access的描述中，有这样一段话。

这里说Armv8‑M有这个问题。看来LPC55S69的这个问题说不定是ARMv8在某种情况下的常态，下一步会研究一下这个，如果大家有兴趣的话，我会把研究的结果与过程放出来分享。

阅读全文

zmh169

挖坑，踩坑，填坑。。。这就是Debug

eefocus_3896990

1016打卡，活动第22天打卡