STM32F412 串口接收不到数据的问题

原本我写上位机的,最近工作需要写了一下下位机的代码。

使用的是STM32F412RETx的芯片,板子是电子工程师做的

使用STM32CubeMX V5.2.1、Keil uVision5做开发,使用HAL库

使用过程中多次出现串口接收的问题,最后都解决了,这里记录一下

串口的HAL有3类API

// 同步堵塞收发
HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout);
// 异步中断传输
HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);
// 异步DMA传输(Direct Memory Access,DMA),不经过CPU,外设直接读写内存
HAL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_UART_Receive_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);

我使用的是异步中断HAL_UART_Receive_IT的进行串口数据接收,这个需要用到

接收完成中断回调
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart);

在中断回调中只进行数据的解析,不做过多其他处理,避免中断时间过长,中断中也不要使用延时函数,尽量不在中断中进行IO输出操作。

第一种串口接收问题:现象为开机后串口可以接收数据,一会儿后就一直没有数据了。

查看错误为:HAL_UART_Receive_IT返回HAL_BUSY

先说一下我的使用方法:使用HAL_UART_Receive_IT接收数据,需要在每次接收完成后,再次调用HAL_UART_Receive_IT函数,一般是在HAL_UART_RxCpltCallback函数的末尾再次HAL_UART_Receive_IT。

HAL_UART_Receive_IT有个状态返回值,可以自己看一下这个函数的实现,代码也就几十行

HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)
{
  /* Check that a Rx process is not already ongoing */
  if (huart->RxState == HAL_UART_STATE_READY)
  {
    if ((pData == NULL) || (Size == 0U))
    {
      return HAL_ERROR;
    }

    /* Process Locked */
    __HAL_LOCK(huart);

    huart->pRxBuffPtr = pData;
    huart->RxXferSize = Size;
    huart->RxXferCount = Size;

    huart->ErrorCode = HAL_UART_ERROR_NONE;
    huart->RxState = HAL_UART_STATE_BUSY_RX;

    /* Process Unlocked */
    __HAL_UNLOCK(huart);

    /* Enable the UART Parity Error Interrupt */
    __HAL_UART_ENABLE_IT(huart, UART_IT_PE);

    /* Enable the UART Error Interrupt: (Frame error, noise error, overrun error) */
    __HAL_UART_ENABLE_IT(huart, UART_IT_ERR);

    /* Enable the UART Data Register not empty Interrupt */
    __HAL_UART_ENABLE_IT(huart, UART_IT_RXNE);

    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}

一般这个函数失败都是返回HAL_BUSY居多,这里有两种情况会返回HAL_BUSY

  1. huart->RxState != HAL_UART_STATE_READY,串口没准备好或者串口正在接收数据中,如果时正在接收数据,意味着其他地方已经调用过HAL_UART_Receive_IT,直接忽略等待接收完成就好,而我知道只有在HAL_UART_RxCpltCallback有再次调用,所以其他地方调用不存在,而且失败时查看过状态huart->RxState 是等于 HAL_UART_STATE_READY

  2. __HAL_LOCK(huart);加锁失败,锁被占用。

看一下__HAL_LOCK(HANDLE)的定义

#define __HAL_LOCK(__HANDLE__)                                           \
                                do{                                        \
                                    if((__HANDLE__)->Lock == HAL_LOCKED)   \
                                    {                                      \
                                       return HAL_BUSY;                    \
                                    }                                      \
                                    else                                   \
                                    {                                      \
                                       (__HANDLE__)->Lock = HAL_LOCKED;    \
                                    }                                      \
                                  }while (0U)

这里就判断了一次,如果锁被占用,直接返回,从我这边测试可以看到,一般都是因为锁被暂用然后返回了HAL_BUSY,那么就要看一下哪里占用了锁。

接收数据使用的是异步中断的函数HAL_UART_Receive_IT(),然而发送数据我使用的是同步堵塞的函数HAL_UART_Transmit(),可以自己看一下HAL_UART_Transmit()的实现,这里不列代码了,HAL_UART_Transmit()函数内从开始发送开始加锁,等待全部数据发送完成后才解锁,所以占用锁的时间是比较长的。而数据发送也比较多,所以基本判定是发送造成的加锁。

有两种方法可以解决发送造成的加锁问题:

1. 使用异步函数发送,这样占用锁时间就短,不过也有概率锁占用,可以选择重试几次可能就可以了

  1. huart->RxState=HAL_UART_STATE_READY,且保证不存在多处代码同时发送,那么可以选择暴力解锁,我使用这种方案

下面确认一下被加锁的代码

加锁一般是因为要操作一下公用的数据。

下面我们分析一下串口UART_HandleTypeDef结构体

typedef struct __UART_HandleTypeDef
{
  USART_TypeDef                 *Instance;        /*!< UART registers base address        */

  UART_InitTypeDef              Init;             /*!< UART communication parameters      */

  uint8_t                       *pTxBuffPtr;      /*!< Pointer to UART Tx transfer Buffer */

  uint16_t                      TxXferSize;       /*!< UART Tx Transfer size              */

  __IO uint16_t                 TxXferCount;      /*!< UART Tx Transfer Counter           */

  uint8_t                       *pRxBuffPtr;      /*!< Pointer to UART Rx transfer Buffer */

  uint16_t                      RxXferSize;       /*!< UART Rx Transfer size              */

  __IO uint16_t                 RxXferCount;      /*!< UART Rx Transfer Counter           */

  DMA_HandleTypeDef             *hdmatx;          /*!< UART Tx DMA Handle parameters      */

  DMA_HandleTypeDef             *hdmarx;          /*!< UART Rx DMA Handle parameters      */

  HAL_LockTypeDef               Lock;             /*!< Locking object                     */

  __IO HAL_UART_StateTypeDef    gState;           /*!< UART state information related to global Handle management
                                                       and also related to Tx operations.
                                                       This parameter can be a value of @ref HAL_UART_StateTypeDef */

  __IO HAL_UART_StateTypeDef    RxState;          /*!< UART state information related to Rx operations.
                                                       This parameter can be a value of @ref HAL_UART_StateTypeDef */

  __IO uint32_t                 ErrorCode;        /*!< UART Error code                    */

} UART_HandleTypeDef;

结合HAL_UART_Receive_IT()、HAL_UART_Transmit()两个函数,发现其实收发数据时使用的成员变量基本是分开的,

发送使用pTxBuffPtr、TxXferSize、TxXferCount、hdmatx、gState

接收使用pRxBuffPtr、RxXferSize、RxXferCount、hdmarx、RxState

共用部分:ErrorCode

gState也可能是公用的,不过暂时在函数HAL_UART_Receive_IT中没发现有使用gState

检查自己的代码,发现确实是HAL_UART_Transmit()造成的锁,既然基本上主要成员没有共用,那就暴力解锁

在判断接收状态为HAL_UART_STATE_READY时,且被加锁,直接暴力解锁
if(HAL_UART_STATE_READY == huart->RxState && HAL_LOCKED == huart->Lock)
{ 
      __HAL_UNLOCK(huart);      // 暴力解锁
}

至此由于加锁问题而造成的串口突然接收不到数据的问题暂时解决了,很暴力的方式


第一种串口接收问题:同样是上电后串口可以接收数据,接收一段时间后没数据了,

而且HAL_UART_Receive_IT()函数返回的是HAL_OK

检查了HAL_UART_GetError(),获取到错误HAL_UART_ERROR_ORE,应该是串口溢出的意思。

只是为什么溢出后就直接停止接收了?就算是丢包也不要给我直接停止工作了呀!!!删库后跑路了???

解决方法如下

既然知道报错,那就考虑清楚错误标志,特地也看了一下函数HAL_UART_IRQHandler(UART_HandleTypeDef *huart);内,的确是有错误标志的时候,不会调用接收完成回调

看了多篇文章,试了几种方法后终于找到一个清除错误标志有效的

使用__HAL_UART_CLEAR_OREFLAG(HANDLE)可以清空错误标志

使用__HAL_UART_CLEAR_FLAG(HANDLE, FLAG)是没用的

最终完整版的修改如下:

HAL_StatusTypeDef K_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)
{
    HAL_StatusTypeDef status = HAL_OK;
    for(int32_t i = 1; i < 1000; ++i)
    {
#if 1
        // 清除错误
        uint32_t isrflags   = READ_REG(huart->Instance->SR);
        if((__HAL_UART_GET_FLAG(huart, UART_FLAG_PE))!=RESET)
        {
            __HAL_UART_CLEAR_PEFLAG(huart);
        }
        if((__HAL_UART_GET_FLAG(huart, UART_FLAG_FE))!=RESET)
        {
            __HAL_UART_CLEAR_FEFLAG(huart);
        }
        if((__HAL_UART_GET_FLAG(huart, UART_FLAG_NE))!=RESET)
        {
            __HAL_UART_CLEAR_NEFLAG(huart);
        }
        if((__HAL_UART_GET_FLAG(huart, UART_FLAG_ORE))!=RESET)
        {
            //READ_REG(huart->Instance->CR1);//ORE清标志,第二步读CR
            //__HAL_UART_CLEAR_FLAG(huart, UART_FLAG_ORE);
            __HAL_UART_CLEAR_OREFLAG(huart);
        }
        if(HAL_UART_ERROR_NONE != huart->ErrorCode)
        {
            huart->ErrorCode = HAL_UART_ERROR_NONE;
        }
#endif
        // 请求接收
        status = HAL_UART_Receive_IT(huart, pData, Size);
        if(HAL_OK == status)
        {   // 成功
            return status;
        }
        else if(HAL_BUSY == status)
        {
            //printf("HAL_UART_Receive_IT failed. status:%d, RxState:0X%x, Lock:%d\r\n", status, huart->RxState, huart->Lock);
            if(HAL_UART_STATE_READY == huart->RxState && HAL_LOCKED == huart->Lock && i % 500 == 0)
            {   // 接收是已经ready的,只是修改数据的锁被lock了,应该是堵塞发送那边一直在lock中, 稍微重试多次后(即等待一下解锁)就直接暴力解锁
                __HAL_UNLOCK(huart);
                continue;
            }
        }
        else if(HAL_ERROR == status)
        {   // 直接返回错误
            //printf("HAL_UART_Receive_IT HAL_ERROR\r\n");
            return status;
        }
        else if(HAL_TIMEOUT == status)
        {   // HAL_UART_Receive_IT 不存在timeout返回
            //printf("HAL_UART_Receive_IT HAL_TIMEOUT\r\n");
        }
    }
    if(HAL_OK != status)
    {
        //printf("HAL_UART_Receive_IT Err status:%d\r\n", status);
    }
    // 重试了N次
    return status;
}

发送也稍微处理一下

HAL_StatusTypeDef K_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
    HAL_StatusTypeDef status = HAL_OK;
    for(int32_t i = 1; i < 100000; ++i)
    {
        status = HAL_UART_Transmit(huart, pData, Size, Timeout);
        if(HAL_OK == status)
        {   // 成功
            return status;
        }
        else if(HAL_BUSY == status)
        {
            //printf("HAL_UART_Transmit failed. status:%d, gState:0X%x, Lock:%d\r\n", status, huart->gState, huart->Lock);
            if(HAL_UART_STATE_READY == huart->gState && HAL_LOCKED == huart->Lock && i % 50 == 0)
            {   // 发送状态是已经ready的,只是修改数据的锁被lock了,应该是其他发送或者接收锁了, 重试几次后还是一样则暴力解锁
                __HAL_UNLOCK(huart);
                continue;
            }
        }
        else if(HAL_ERROR == status)
        {   // 直接返回错误
            return status;
        }
        else if(HAL_TIMEOUT == status)
        {   // 超时则增加时间重试
            Timeout += 200;
            continue;
        }
    }
    // 重试了N次
    return status;
}

这样处理后,接收是可以了,虽然有丢包,至少能一直接收,之后发现之所以那么不稳定,因为STM32F412RETx需要在输入电源增加一个电容进行滤波,增减滤波后就正常了,至少没发现丢包,不加清除标志也没问题

参考了很多篇文章,仅列举有用的:

https://blog.csdn.net/mickey35/article/details/78529637
http://bbs.21ic.com/icview-2514912-1-1.html?ordertype=1

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 230,791评论 6 545
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 99,795评论 3 429
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 178,943评论 0 384
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 64,057评论 1 318
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 72,773评论 6 414
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 56,106评论 1 330
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 44,082评论 3 450
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 43,282评论 0 291
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 49,793评论 1 338
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 41,507评论 3 361
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 43,741评论 1 375
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 39,220评论 5 365
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 44,929评论 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 35,325评论 0 28
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 36,661评论 1 296
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 52,482评论 3 400
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 48,702评论 2 380