利用FreeModbus库做主机时，从机超时引起thread任务锁死分析

发布于 2020-03-03 14:24:58 浏览：4644 订阅该版

* 本帖最后由 FVFN_5228 于 2020-3-3 14:24 编辑 *

最近在学习rt-thread，因为工作中用到mosbus，因此在使用freemodbus库，遇到了点问题，折磨了好几天，终于找到原因，跟大家分享下心得：
软硬件环境配置
   硬件采用STM32F103，modbus采用串口3,115200，串口3的TX/RX引脚直接接入串口透传无线收发模块，经另一个无线收发模块连接电脑USB口调试；调试口采用uart4
   软件采用RT-Thread Studio，添加freemodbus库，运行sample_mb_master.c例程，从机目标地址1
问题描述
   下载程序后，在终端输入"mb_master_sample",启动modbus主机程序；
   从机采用Modbus Slave模拟，可以看到Modbus Slave可以更新一次寄存器数据，但是之后再也不更新了，并且主机也不再发送写入寄存器指令，但是闪灯程序（main函数内）运行正常；将从机关闭（不回复，只监听），重新启动程序，可以看到主机周期性发送“01 10 00 02 00 02 04 3F D7 00 02 4F 9B”写寄存器指令。
   死机后的mosbus如果用从机继续发指令返回给主机，主机可以再被唤醒，继续周期性发送“01 10 00 02 00 02 04 3F D7 00 02 4F 9B”指令

分析过程
    由于usart3采用了无线透传模块，因此从机回复时间会超时（默认100个周期）
  于是在send_thread_entry任务跟mb_master_poll任务设断点分析，当从机返回一次指令后，两个任务均不再被调度；
  mb_master_poll所需资源为 EV_MASTER_READY | EV_MASTER_FRAME_RECEIVED | EV_MASTER_EXECUTE |EV_MASTER_FRAME_SENT | EV_MASTER_ERROR_PROCESS, 五个event事件；
  send_thread_entry 所需资源为信号量 xMasterRunRes
   再查，信号量xMasterRunRes释放函数vMBMasterRunResRelease()有两个地方，都在mb_master_poll任务里（mb_m.c）,line354,line358
  因此，可以初步查出这freemodbus主机例程两个任务死锁原因在mb_master_poll任务中event没有触发，继续追查mb_master_poll中调用了xMBMasterPortEventGet( &eEvent ) 函数，代码如下：
BOOL
xMBMasterPortEventGet( eMBMasterEventType * eEvent )
{
    rt_uint32_t recvedEvent;
    /* waiting forever OS event */
    rt_event_recv(&xMasterOsEvent,
            EV_MASTER_READY | EV_MASTER_FRAME_RECEIVED | EV_MASTER_EXECUTE |
            EV_MASTER_FRAME_SENT | EV_MASTER_ERROR_PROCESS,
            RT_EVENT_FLAG_OR | RT_EVENT_FLAG_CLEAR, RT_WAITING_FOREVER,
            &recvedEvent);
    /* the enum type couldn't convert to int type */
    switch (recvedEvent)
    {
    case EV_MASTER_READY:
        *eEvent = EV_MASTER_READY;
        break;
    case EV_MASTER_FRAME_RECEIVED:
        *eEvent = EV_MASTER_FRAME_RECEIVED;
        break;
    case EV_MASTER_EXECUTE:
        *eEvent = EV_MASTER_EXECUTE;
        break;
    case EV_MASTER_FRAME_SENT:
        *eEvent = EV_MASTER_FRAME_SENT;
        break;
    case EV_MASTER_ERROR_PROCESS:
        *eEvent = EV_MASTER_ERROR_PROCESS;
        break;
    }
    return TRUE;
}

这个函数采用了switch case结构，如果只有一个事件到来，没有任何问题，如果有两个事件同时到来，函数的返回值为TRUE，但是* eEvent的返回值就是一个不确定的数。我在测试过程发现，如果从机返回数据超时，会同时触发 EV_MASTER_FRAME_RECEIVED 和 EV_MASTER_ERROR_RESPOND_TIMEOUT两个事件，变量recvedEvent值为0x12。
   在mb_master_poll函数中，由于返回值为TRUE，所以可以继续运行下去，但是eEvent已经不是一个确定的值了，导致下面的switch ( eEvent )，不会进入任何一个case语句中，只能进入default：break； 下面为eMBMasterPoll( void )部分代码
  由于不能进入case语句中，所以不能释放所需event资源及信号量xMasterRunRes，导致send_thread_entry任务跟mb_master_poll任务，均不会再运行。当从机继续返回数据时，xMBMasterPortEventGet()函数可以接收到EV_MASTER_FRAME_RECEIVED事件，这就能够解释可以把两个锁死的任务解开了。
 if( xMBMasterPortEventGet( &eEvent ) == TRUE )
    {
        switch ( eEvent )
        {
        case EV_MASTER_READY:
            eMBState = STATE_ESTABLISHED;
            break;
        case EV_MASTER_FRAME_RECEIVED:

验证过程  
    把函数xMBMasterPortEventGet( eMBMasterEventType * eEvent )中的default:break;改为如下代码，将*eEvent = EV_MASTER_FRAME_RECEIVED 返回给上一级函数
         default:
        *eEvent = EV_MASTER_FRAME_RECEIVED;
        break;
  烧写程序运行后，即便从机返回超时，主机的两个任务也不会锁死，下一个周期可以继续发送寄存器写入指令给从机。

总结
   在modbus总线中，会经常遇到从机超时或者返回数据不正确情况，因此主机要有强大的稳定性以便应付这些故障。以上我的一点测试心得，欢迎大家交流指正