感谢楼主分享，昨天也是突然遇到了这种情况，不过和楼主触发的原因稍有不同，楼主同时触发 EV_MASTER_FRAME_RECEIVED 和 EV_MASTER_ERROR_RESPOND_TIMEOUT两个事件，而我是同时触发了EV_MASTER_FRAME_RECEIVED 和 EV_MASTER_FRAME_SENT两个事件，正如楼主所说，正常情况下不可能同时出现两种事件的
分析一下发现：poll线程和send线程都包含有互相需要等待的事件，当send线程在post（post（EV_MASTER_FRAME_SENT）后等待挂起，直到poll线程释放send线程等待的事件，在这个过程中，poll线程是事件处理和调度的核心，同一时刻一旦有某个事件需要poll线程处理，其最好能够被立即唤醒并处理，我们发现例程中poll线程中有一个延时，这个延时会带来事件的堆积后果，一旦事件产生了堆积，poll线程无法处理，也就形成了死锁。
楼主的解决方法是相当于给了一个默认的事件，而不会出现不确定的事件，避免多个事件同时发生。
还有个方法就是在不修改协议栈的基础上，去掉poll线程中的延时，增大响应超时时间（MB_MASTER_TIMEOUT_MS_RESPOND），目的也就是尽可能避免事件产生堆积。

https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/issues/35
断言会触发的原因可能是这个

不是你这么理解的，首先这个tick计数器是递减的，其次假如你延时10个us对应的tick数是10，那么从现在开始，delta就是获取当前开始的tick数记录下来假如是50，由于tick是递减的，也就是减到40就退出了，40怎么来的？就是不停的判断delta-当前tick是否大于10，大了就退出，小了就循环判断。之所以不超出一个OStick是因为可能存在tick计数器递减溢出的情况

你使用超级终端或者putty测试就没有问题，串口助手发送的是连续的字符串，绝对比你手动输入字符，finsh组件一个一个捕获解析快的多，你是每隔10ms查询有没有收到字符（rt_thread_mdelay(10)），串口助手发送一串字符串很快的，所以你的finsh组件只捕获到了一个字符

这个已经添加过了但是还是不行，输入上下左右返回ABCD，还是这个错误