1.问题描述
笔者在进行开发时，发现：开发板谁用RS485与一个设备通信。当该设备收到开发板发来的数据帧时，会向开发板反馈数据帧。调试中，发现，开发板没有收到该设备的反馈。因为，该设备是成熟产品。所以主要怀疑在开发板端。debug调试发现，开发板RS485串口中断处理程序无法进入。
1.首先，确保往开发板发送数据帧。于是，使用RS485转USB线，连接开发板和电脑。电脑端使用串口助手周期性向开发板发送数据帧。
在此基础上，进行问题的定位。
该问题从总括来说，有两大怀疑点：软件方面和硬件方面
软件方面：
1.RS485通信基本配置是否正常，比如所使用到的RX,TX,RE引脚是否配置正确；对应的串口和GPIO引脚时钟是否使能；引脚的复用是否配置正确；引脚GPIO的模式是否配置正确；
2.串口中断优先级是否配置正确；串口接收中断是否使能；处理器引脚是否配置为接收模式。
3.中断号和中断处理程序是否正确；中断号和中断处理程序必须和中断向量表中的名称完全一致，否则即使有数据接收，但由于中断号不正确或者中断处理程序不正确，导致无法进入正确的中断处理程序中，进行处理。
硬件方面：
1.RS485芯片的A,B不要接反了。
2.处理器芯片Rx引脚是否有信号。需要用逻辑仪或者示波器量取。为了方面，可以让串口助手周期性发送0x55. 用示波器量取，正常信号应当是高低电平交替出现，且有周期性。如果RX引脚一直为高或者低，就要想一下是不是硬件上，外围电路一直把RX引脚拉低或拉高了。
3.处理器芯片RS485使能引脚信号是否正常。当RS485处于接收模式时，使能引脚信号应该为低电平。当使能引脚信号不对时，硬件上，是不是有外围电路把引脚拉低或拉高了。软件上，是否正常配置使能引脚的值为低电平。
上面列举了，遇到该类问题的排查方向。针对具体问题，读者要结合自身的实际情况，梳理出具体的排查方面和优先级，进行排查。
2.分析过程
结合具体情况，笔者首先排查了软件问题，初步排查由于疏忽大意未发现问题。于是，使用示波器量取信号，来具体定位到明确的问题点。
a.示波器量取RE引脚信号，理应为低电平。量取时，发现，一直为高电平。进一步查看程序配置发现，理应配置PD7引脚，结果配置成PA7了。修改后，在接收模式下，RE引脚量取为低电平，且RX引脚量取为高低点电平交替。从硬件上看，都正确了。
b.RE引脚和RX引脚信号都正确，仍无法进入中断处理程序。排查.s中断向量表中的中断号和中断处理程序和代码中实际使用的中断号和中断处理程序是否一致。结果发现，代码中使用的中断处理程序和该中断号对应的中断向量表中的中断处理程序名称不一致。
最终，定位到问题原因。
这种情况，编译器是不会报错的。原因是：
1.假如是一个函数xxx未被声明，在其它文件中，有调用，则编译器在编译器时，在跟定的寻找空间中，找不到函数xxx的定义，会提示：符号未被定义：Error:
L6218E: Undefined symbol xxx (referred from fileyy.o).
2.但是，当这个符号是一个中断处理函数时，就变得比较特殊了，因为中断处理函数在整个项目代码中，一般不会被调用，也就是除了这个函数被定义的地方，没有其它引用。自然在程序编译时，不会出现该符号未被定义的错误提示。当某个触发中断的事件发生时，处理器会从中断向量表中找到该中断事件对应的中断处理程序的入口地址，从而转到中断处理流程中。一旦，程序中实际定义的中断处理程序名称和中断向量表中的中断处理名称不一样，就不能正确进入程序中定义的中断处理程序中。因此，要特别注意程序中实际定义的中断处理程序一定要和中断向量表中的中断处理处理程序名称完全一致。