嵌入式开发之串口校验（HC32L110）

背景

        前几年芯片供货紧张以及当前宣扬的主流文化，逐步开始使用国产芯片替代ST的芯片搞一些产品开发。开始产品开发使用的是TI的MSP430的芯片，工艺都是十多年前的，功耗可以控制住，整机静态功耗做到100uA以内，测试中有一些问题，到现在也无法真切确认问题根源，当板子工作正常时，功耗降下来后，周围有人员走动都会影响板子的功耗变化。大概率是硬件设计的问题，当时TI原厂的工程师也过来看了看，最终也没给出来分析的结果。后来逐步将公司产品的主控芯片都换成了ST的芯片，主要是两个系，低功耗的使用STM32L0和高性能的使用STM32F429，性能表现都比较理想。

        但是STM32L0的芯片虽然功耗参数比较理想，但是在一个场景下也是让我耗费了很长时间，处于静态低功耗时串口不能丢数，以往常规的逻辑是先发送个无效字节进行唤醒，然后再发送有效字节进行交互。为了解决这个问题，就得浪费一些功耗，当时处理的方法时将单片机处于低功耗运行状态，将主频降到两百多KHz，功耗还可以接收，串口波特率在9600以下时就不会丢数了。产品量产了上万套，在现场使用也没反馈有问题。

       后来由于工作变动，以及当时的芯片行情，不想再在ST的芯片上折腾了，偶然的机会拆了一块超声波水表，看到了小华半导体的芯片，然后就发现了新大陆，小华的芯片论性能来说中规中矩，在特定场景下性能还算出彩，现在还有一些人不太相信国产芯片，我的感觉是大部分国产芯片在特定场景下使用问题不大，但如果所有场景都想让它表现优异，这个有点难，恐怕所有的芯片都不能实现。

        使用HC32L110的芯片开发了低功耗LoRa DTU，这个芯片可以实现在低功耗深度休眠时串口不丢数，波特率不超过9600即可，芯片内部提供了一个38400的晶振，开始还纳闷弄这么个频率的晶振搞什么用，现在想想这个频率正好是9600的四倍，所以才能保证串口在休眠时不丢数的根源。

问题

        产品开发完后，各种测试都没问题，串口参数可配置，LoRa参数可以配置，配置完后参数都可以生效。主机和从机通讯最要命的参数是时间窗口的配置，得保证主机发送的前导码能够唤醒从机，从机要在前导码的周期内打开前导码接收一次，接收时间不能太长，加长一点都会增加很多的功耗。

        产品测试完后，生产了几百套发货给甲方，甲方收到后怎么测试都不行，远程查看也差不多来问题。后来怀疑是在设计外壳时有一个电容跟外壳有点干扰导致晶振不起振，然后重新调整程序将晶振弃用，使用内部的晶振，这个产品当时为了节省成本选了一个低配的MCU，内部flash只有32KB，无法放入我们的bootloader，烧写程序只能使用仿真器，在这种情况下只能安排工程师到现场去更新程序。更新后发现推测是错误的，问题跟不在这个晶振上。

        有点焦急了，然后办公室搭建环境抓紧测了一下，找了一个仪表挂上之后，发现了问题，仪表配置的是串口奇校验，当时测试时模块挂在电脑上，虽然都配置了奇校验，但是电脑的容错性强，收到的数据都是正常的，但是仪表收到的数据校验错误时把数据都丢弃了，导致怎么给仪表发送数据都没有响应，单纯连接电脑测试LoRa DTU都没有任何问题。

        找到问题的根源后开始解决，传统的串口配置方式都是将MCU的寄存器配置为校验方式接口，硬件来实现校验位的计算。可恨的是HC32L110校验方式需要软件去计算，然后根据校验后的结果过来配置寄存器发送校验位的高低电平。

        串口出现问题时一定要认真看看手册，想当然的想法会出大问题。