求大佬帮我看看这个类似于双缝干涉实验现象的结果是怎么来的

驭剑的秘密

情况是这样的，我想看看这个函数返回的值，结果遇到了一件奇怪的事，我把关键的switch变量的值放在了窗口里，当我在这个函数的出口打上断点的时候，我去看窗口里变量的值，用这个值去推演进入的分支得到最终返回值，结果让我感觉很疑惑，因为这与我观测到的返回值不一样，明明不可能走的分支，却进去了。而当我把断点放在程序入口的处，变量的值还是跟之前在函数出口处打断点观测到的值是一样的，但这次他的结果跟我推演的结果是一样的了。程序我放在下面，然后在附上我在断点处变量值的截图。

1. switch (TransmitMailbox)
   
2.   {
   
3.     case 0x00:
   
4.       state =   CANx->TSR &  0x04000003;
   
5.       break;
   
6.     case 0x01:
   
7.       state =   CANx->TSR &  0x04000003;
   
8.       break;
   
9.     case 0x02:
   
10.       state =   CANx->TSR &  0x04000003;
    
11.       break;
    
12.     default:
    
13.       state = 0x00;
    
14.       break;
    
15.   }
    
16.   switch (state)
    
17.   {
    
18.       /* transmit pending  */
    
19.     case (0x0): state = 0x02;
    
20.       break;
    
21.       /* transmit failed  */
    
22.      case 0x04000001: state = 0x00;
    
23.       break;
    
24.      case 0x08000100: state = 0x00;
    
25.       break;
    
26.      case 0x10010000: state = 0x00;
    
27.       break;
    
28.       /* transmit succeeded  */
    
29.     case 0x04000003:state = 0x01;
    
30.       break;
    
31.     case 0x08000300:state = 0x01;
    
32.       break;
    
33.     case 0x10030000:state = 0x01;
    
34.       break;
    
35.     default: state = 0x00;
    
36.       break;
    
37.   }
    
38.   return (uint8_t) state;

复制代码

这是我在出口处打断点的时候，两个变量的值，与推演结果完全相悖。

驭剑的秘密

大概想明白了，在经过第一个switch的时候CANx->TSR寄存器的值还没被更新，所以在第一个switch结束的时候，state的值是0，也就得到了出口处下断点的时候的0x2的结果。为了验证这一点，我在这个函数被调用之前增加了1ms的延时，这时候再进入函数，寄存器的值已经被硬件更新完很久了，再次从出口处下断点，已经和推演的结果一致了。

驭剑的秘密

上面的CANx->TSR的值是0x1C000009，在函数入口处打断点和出口处打断点，这个值都是一样的，两处断点唯一不同的就是返回的state的值不一样

驭剑的秘密

我也不知道为什么用仿真器观察不出来CANx->TSR没更新的值，但我觉得大概就是这么回事