stm32 USART DMA

在工程中串口的应用广泛，同时出现的问题也最多，下面是在开发过程中遇到的串口DMA问题。

在大量数据发送的过程中出现很多奇怪的现象，但是之前的DMA也是这么使用的，没有出现问题，接下来根据特殊现象进行解决

 

1.在DMA 实现大量数据导出时（文件导出操作），出现单步调试和全速情况下不一样的情况。最后发现在keil调试的时候DMA确实是和调试不同步的，在之前的DMA接收长度的时候也同样出现了同样的情况，之后在调试DMA的时候注意一下。

2.DMA在发送的时候总是丢失最后两个字节，通过网络查找，确实有有很多类似现象

http://www.openedv.com/posts/list/64252.htm

https://wenku.baidu.com/view/7c4a13d1f605cc1755270722192e453610665b98.html

有很多文章，大致说的意思就是DMA还没发送完成，485就置为接收了，经测试确实是这么回事，所以在DMA完成中断中485何时置为接收很重要，负责的话可以覆盖性的进行各种完成标志的判断，还有就是适当的增加延时也能解决。

 

通过增加前两条语句，还丢失一个字节，然后，增加了1s延时数据就正常了。

 

网上说，485芯片再发送完成后，需要1ms左右再转为接收，要不然就会出现丢字节的情况，以前设备出现丢数据的情况应该和这个也可能有一定关系。但是程序设计的严谨性还是很重要的，该判断的标志位就要判断全面，不然就会出现隐形的bug.

3.在文件导出实验中，DMA发送完之后，在填充在发，数据出现乱码，推测应该也是上一数据没发送完，下一帧数据覆盖掉 了导致，增加延时后，问题去除，但是时间设置为多少合适还需要研究。

4.在去除置位接收，每次断电瞬间，串口都会发送出数据，应该也是用的错误，485是半双工的，使用时要严谨。

5.本次调试中就感觉到DMA完成中断中，接收何时置位很重要，太早置为接收，导致自己丢失，太晚置位，导致数据接收过多，DMA因为是自己干活，如何监控如何把控显得至关重要。

 

 

发现去掉延时，改为判断usart_FLAG_TC标志位更好用

通过这种标志位的判断就不用加上面的延时了，既提高了效率，也保证了质量。

 

6.在目前的项目中使用比较多的接收方法就是，不加DMA,开启的RXEN中断，一个字节一个字节接收放到缓冲区，通过定时器计时超时检测机制来实现。

7.另一种方法就是使用串口空闲中断加DMA的方式，当串口空闲中断触发后，DMA同时自动将数据搬运到数组中，供后方解析。

8.485芯片带方向，半双工也导致在配合使用中出现问题

9.下面是项目中发现的问题

（1）设备在无线传输过程中，由于数据量大导致的串口死住问题，在使能RXEN中断的过程中USART_FLAG_ORE错误标志也会使能，当进入该错误后，程序没有进行处理导致的死机现象。USART_ClearFlag(USART1,USART_FLAG_ORE);//接收到错误字符，读取后扔掉，可避免，同时CRC的校验方式也存在隐患。

（2）在文件导出中，DMA需要发送大量数据，但是会导致丢包或者丢最后字节的现象

原因是，DMA搬运完成到串口中触发DMA完成中断，然后将485置为了接收，但此时只是DMA完成工作了，但是串口还没完成工作。

增加串口发送位的检测，可以避免丢字节问题。

（3）在DMA+空闲中断的过程中，出现频繁丢包现象，原因为串口发送指令过于频繁，在触发空闲中断的时候，不能及时的关闭DMA，导致DMA将多包数据当成了一包，导致长度判断出现问题，CRC校验也就出现了问题。

在进入空闲中断后，马上关闭DMA通道，避免接收多包数据，并且减慢DMA的搬运速度，将DMA发送完成的