MSP432P401R: debug时，程序停在了driverlib.c里

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)循环的上下语句时产生的

请问是TI例程还是自己的程序？我来拿开发板看一下

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外设）

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"

林畅 说：

不理解"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的问题了