前言
最近好像和BUG杠上了,一直在忙着找bug,上个礼拜修了一个礼拜的电路板,前天又开始找程序的BUG,直到今天才结束。在本次找程序BUG中自己学会了数据对齐和串口通信注意的地方。本次主要记录找BUG和解决BUG的过程。不喜勿喷。
背景
本次刚来公司几个月,接收了别人之前做过的产品,那我就负责产品维护,另外就是研发新产品。本次的BUG就是stm32下位机存储在DGUS屏中的数据,不能正常被上位机所读出(上位机是老大用C#写的)。
BUG one:
记录头不能正常显示,而是显示为 已用:1000,剩余:20301,总量85。正常上位机会显示为已用:50, 剩余:950, 总量1000。
就开始在下位机上找BUG,找啊找,发现另外一个串口能够读出数据,并用printf发到SecureCRT,那就是发送上位机的程序问题。然后去找问题。如图
然后单独用这个函数发送数据。没有问题。慢慢发现,记录头的结构体的第一个参数出了问题,他是16位的整形数据,而上位机是32位整形接收。后修改为16位接收就能够正常显示记录头。
如图,结构体
BUG Two
读取下位机测试记录时,没有数据显示。
然后也是用同样的方法测试,发到表中去,结果能够显示。说明下位机的收发函数和存储数据都是没有问题。然后想到是不是浮点数发送会出错,结果还真是碰到浮点数就发现问题。老大提醒是不是数据对齐问题,然后就在数据读取结构体声明就加了按四字节对齐,
__IO __align(4) LCDCOM_STRUCT LCDCOM_mcb; 结果发现还是不行。
然后就直接打印结构体第一个参数的地址和浮点数的地址,结果发现相差12,而上位机接收浮点数数据是从位10开始的。这样接收数据肯定错了,因为数据存储是按连续的物理地址存储的,又因为结构体是按四个字节对齐,那么浮点数存储数据的位是从12位开始。
所以上位机接收这个浮点数数据要从第12位开始。(开始是从第10位开始的)。故修改从第12位开始接收。这样表中的数据就能够正常显示。
总结:
从以上找BUG的过程学到,串口通信过程中数据不对,可能是数据位数的问题或者收发过程的问题,可以一个个排除;另外就是上位机接收数据时,接收的数据位一定要对,要考虑数据对齐的问题,这样就不会产生BUG了。记录就到这里。