TI中文支持网Part Number: MSP432P401R
程序卡在了这里，请问这一般代表了什么问题？
程序使用的是TI drivers，开启了定时器中断和I2C。
Susan Yang：
CPU_wfi的含义如下:
Wait for interrupt.
Use this function to let the System CPU wait for the next interrupt. This function is implemented as a wrapper function for the WFI instruction.
您之前是执行了什么代码后跳入该语句呢？
,
林畅：
我是直接在debug模式中 直接run之后发现卡了，暂停得出的
一般是进到while(1)循环的上下语句时产生的
,
Susan Yang：
请问是TI例程还是自己的程序？我来拿开发板看一下
,
Susan Yang：
CPUwfi的话，应该是程序跑到了某个函数，然后卡住了，函数不再返回。从调试器来看，就是设备正在等待中断 CPUwfi。
The "CPUwfi" is the expected state when the device in an idle state waiting for an interrupt
林畅 说：我是直接在debug模式中 直接run之后发现卡了
建议您程序运行到 mainThread(NULL); 之后进行单步调试或者设置断点调试，来看一下哪一个语句会引起这种情况。
就我直接拿开发板（没有mpu芯片 ）来说，运行到 res=mpu_dmp_init(); 会进入 CPUwfi
,
林畅：
好像是I2C的发送导致的。这就牵扯到一个问题——如何理解I2C发送阻塞模式的这句话：
,
林畅：
此外，每次我将launchpad的USB线拔出来在重新插上时，第一次debug就不会出现这种情况。
然而以后的每一次debug，每次到I2C传输就会出现这个问题（这种情况以前也出现过，当时没有使用I2C外设）
,
Susan Yang：
If the transferMode is set to I2C_MODE_BLOCKING, the transferCallback argument is ignored.
If transferMode is set to I2C_MODE_CALLBACK, a user-defined callback function must be supplied.
,
林畅：
我主要是作为中国人不理解"thread context"
,
Susan Yang：
林畅 说：不理解"thread context"
如图片所说：
在I2C_MODE_BLOCKING 中，调用I2C_transfer() 会阻塞，直到I2C_Transaction完成。在事务进行中调用I2C_transfer() 的其他线程也被置于阻塞状态。如果多个线程被阻塞，则优先级最高的线程将首先被解除阻塞。这意味着仲裁不会按时间顺序执行。
对于Context：程序在运行的时候，会用到CPU系统的资源，例如寄存器、栈空间等等。当前用到的这些资源，我们称之为上下文（ Context）。我找到一个中文的解释，您可以看一下
https://blog.csdn.net/weixin_40599145/article/details/88032916
另外我们的例程 simplelink_msp432p4_sdk_3_40_01_02\examples\rtos\MSP_EXP432P401R\drivers\i2cmasterexample1 就是 使用的 I2C_MODE_BLOCKING
,
林畅：
那看来进入wfi()函数的原因可能不是I2C的问题了
