新项目在11月中的时候到汽车厂装机调试，该项目使用的LPC4357芯片，使用UI demo显示系统工作正常，能正常显示对应的内容。当接收汽车CAN数据时，发现不能显示正确的UI并且无法调节LCD亮度及combiner的角度。在平时开发过程中，使用USBCAN模拟器可以正常使用。
后经使用J-Link调试发现，程序卡在CAN的中断处理函数中出不来，一直在while里面死循环，没有调到接收数据的回调函数RX_cb();if((1<<(msg_no-1))!= LPC_C_CAN1->ND1)总是成立，认为是错误，再查看，msg_no = 1，LPC_C_CAN1->ND1 = 0x07，msg_no = 1是一个报文周期为10ms的CAN数据。开始以为是中断来的太频繁导致中断处理不及时，但是通过查找资料发现CAN是有接收缓存的，应该不会出现处理不及时的问题。LPC_C_CAN1->ND1这个是指哪个位置有新数据就会置1，那么msg_no = 1确实是有新数据的那一位，就发现这个语句的bug，当数据来的比较快的时候，CAN会缓存一部分数据，不是一个一个msg处理的，那么
LPC_C_CAN1->ND1不会只置一位，那么
判断就会不等于，后来修改为if((1<<(msg_no-1))& LPC_C_CAN1->ND1 == 0)，对应位有数据就调用RX_cb(),这么修改之后，解决了中断频繁导致的系统卡死问题。
在调试过程中发现，在收到数据中断之前，会收到一个状态中断，是一个接收成功中断，也就是说，每成功接收一个数据都会收到一个接收成功中断，那么接收一个10ms周期的报文，会收到两个中断，这样中断太频繁，为了避免增加CPU压力，在CAN初始化的时候不打开这个中断。
后经使用J-Link调试发现，程序卡在CAN的中断处理函数中出不来，一直在while里面死循环，没有调到接收数据的回调函数RX_cb();if((1<<(msg_no-1))!= LPC_C_CAN1->ND1)总是成立，认为是错误，再查看，msg_no = 1，LPC_C_CAN1->ND1 = 0x07，msg_no = 1是一个报文周期为10ms的CAN数据。开始以为是中断来的太频繁导致中断处理不及时，但是通过查找资料发现CAN是有接收缓存的，应该不会出现处理不及时的问题。LPC_C_CAN1->ND1这个是指哪个位置有新数据就会置1，那么msg_no = 1确实是有新数据的那一位，就发现这个语句的bug，当数据来的比较快的时候，CAN会缓存一部分数据，不是一个一个msg处理的，那么
LPC_C_CAN1->ND1不会只置一位，那么
判断就会不等于，后来修改为if((1<<(msg_no-1))& LPC_C_CAN1->ND1 == 0)，对应位有数据就调用RX_cb(),这么修改之后，解决了中断频繁导致的系统卡死问题。
在调试过程中发现，在收到数据中断之前，会收到一个状态中断，是一个接收成功中断，也就是说，每成功接收一个数据都会收到一个接收成功中断，那么接收一个10ms周期的报文，会收到两个中断，这样中断太频繁，为了避免增加CPU压力，在CAN初始化的时候不打开这个中断。
