当我多次调用USS_startLowPowerUltrasonicCapture函数时，程序会直接死机，调用周期为30ms
据我分析造成原因是由于软件看门狗复位，真正卡死的地方在这里
感谢您对TI产品的关注。我们正在核实您的问题，请等待我们的答复。
这个变量的值
准确来看是调用这个函数导致USS_runAlgorithms，当我屏蔽掉这个函数后，程序均能正常运行
我是替换了uss的所有库文件后，重新排查发现的此问题，当前死机的地方如下图
更新一下我最新的进展，根据我的重新测试，因为我重新更新了我都IAP程序方式见MSP430FR6047: IAP升级问题 - MSP 低功耗微控制器论坛 - MSP 低功耗微控制器 - E2E 设计支持，使用此方式我其他所有的中断和应用程序都正常，唯独存在上诉问题。当我取消IAP，即不使用RAM中断向量的地址，更改回0xff80-0xffff中执行时，上诉问题消失
您好 请问有进展了吗 我这边比较着急这个问题
您好
下面的帖子也提到了一个类似的问题，即卡在 commonWaitForconversion 函数中，请注意中断向量设置，并检查一些硬件问题。
CCS/MSP430FR5043：设备初始化期间挂起
这篇帖子并没有帮到我什么，我使能RAM中断向量时就会导致这个问题，但我明确对比了生成时存储的中断地址的数据与我拷贝到0x3b80-0x3bff这个区间是一致的
由于客户已经发现根本原因主要是 MSP430FR6047 中的中断向量重定向到 RAM，以下帖子对此进行了详细讨论，请参考该帖子以获得更深入的了解。
MSP430FR6047：MSP430FR6047：将中断向量重定向到 RAM（第二次）
我的xcl文件里是将这个区域避开了的，可还是会跑飞
LEASTACK的结束地址为3B7F，而中断向量区域为3B80-3BFF。只需担心这两个内存段是相邻的。如果发生超过3B7F的堆栈溢出，它可能会覆盖中断向量表，从而导致系统崩溃或卡住。您可以尝试增加LEA堆栈空间，并在发生卡住时监控堆栈使用情况，以查看是否存在堆栈流。
您好！
根据您的意思，如果我需要增加LEASTACK的的空间，而不占用3B80-3BFF这个范围，那么只能往前扩大？我的想法是否正确？同时将USS库中LEA的起始地址同步修改？
设计支持，使用此方式我其他所有的中断和应用程序都正常，唯独存在上诉问题。当我取消IAP，即不使用RAM中断向量的地址，更改回0xff80-0xffff中执行时，上诉问题消失
这个变量的值
我的xcl文件里是将这个区域避开了的，可还是会跑飞