在使用 MIMXRT1021DAF5A 的
PCB 设计中，观察到我们的固件运行但崩溃到引导 ROM，执行似乎“卡在”地址 0x00209C66。发生这种情况时，看门狗处于活动状态，因此可以预期任何触发这种情况的问题都会对 MCU 进行简单的重置，而不是陷入引导 ROM 中。
正在运行的固件被编程到 QSPI 闪存芯片中，但代码在启动时由引导加载程序加载到 RAM 中，从那里执行。该设计包括一个显示屏，其接口数据保留在 QSPI 闪存中，在固件执行期间根据需要使用 FlexSPI 接口从那里加载。
值得注意的是，观察到的崩溃最常发生在设备上的一个或多个 LPUART 接口处于活动状态时，尤其是 LPUART2。项目中使用了其中的 3 个接口，通过 RS485 链路读取/写入串行数据。如果与这些 LPUART 关联的软件任务在固件中被禁用，则不会发生崩溃。
随附一张显示 CPU 寄存器的屏幕截图，给出了崩溃发生后引导 ROM 中的执行位置。这是从 CrossStudio 调试器环境获得的，Segger J-Link 连接到运行固件的 PCB。不幸的是，由于引导 ROM 中“崩溃”的性质，无法在崩溃发生之前立即确定固件状态，或者可能导致崩溃的原因。
谁能就此问题的进一步调查提供一些指导？是否已在此 MCU 或其他 MCU 上报告过类似问题，可能与已记录（或未记录）的勘误表有关？特别有趣的是，崩溃似乎与 LPUART 使用有关。
