STM32CubeMX外部中断定时器嵌套问题及实验现象

现在没有对下降沿触发这个动作进行消抖的判断，并且这么多天实验没有发现抖动现象，消抖的话我打算最后解决了嵌套问题后加上。
目前TIM2定时器的抢占优先级和响应优先级是（1，1），GPIO抢占优先级和响应优先级是（2，2）

这个部分的内容是写在HAL库的GPIO外部中断 EXTI15_10_IRQHandler10中的回调函数HAL_GPIO_EXTI_Callback中，HAL库的逻辑是执行完回调函数然后配置好了关闭中断的函数，所以一般不需要在回调函数里用完之后手动关闭。
我现在的实现过程是：

按照这个思路进行实现，实验现象是程序会进行到printf(“等待B的触发\r\n”);这一步，但是程序没有卡死，主程序中灯也会正常亮，只是中断每次都是到达这一步。图是旋转一次的实验现象

我考虑是抢占优先级问题，目前是定时器抢占优先级高，在定时器的计数周期内，外部中断的优先级不够，无法检测到外部中断发生了变化。所以每次只会超时溢出，不会检测B的外部中断。

然后我进行了测试，TIM2定时器的抢占优先级和响应优先级是（2，2），GPIO抢占优先级和响应优先级是（1，1），改变了这两个的抢占优先级，这时候的实验现象是，会卡死在printf(“等待B的触发\r\n”);这时候主程序会停止，uart串口会一直输出printf(“等待B的触发\r\n”);不停，如图所示

这里我没有想到合理的解释，应该是嵌套混乱了，低优先级抢占高优先级出问题了，程序卡死了。

这个问题怎么解决我还是没明白，就算是A下降沿触发，然后关闭A，开启定时器等待B的下降沿触发，关闭定时器，这个过程也还是要涉及到中断的嵌套啊，这里我觉着是我的理解和写法有问题，但是我不知道怎么解决。

昨天十点关电脑时候突然想起来不一定非得要用中断检测B的下降沿触发，直接检测定时器开启的时间内电平有没有变化就好了，然后就有了这个代码的改进版本，如下图所示

这个时候就可以正常检测了，但是依然有一个小问题，我试了试几个定时器等待B响应的时间，10ms时候需要快速旋转才可以检测到，然后时间范围变大后，可以检测到旋转比较慢的状态，我现在还在找最合适的这个值，目前的60ms效果不错