MIMXRT1021DAF5A: Firmware crash into boot ROM

[pconway]

In a PCB design using MIMXRT1021DAF5A, it is observed that our firmware runs but crashes into boot ROM, where execution appears to get "stuck" at address 0x00209C66. The watchdog is active when this occurs, so would expect any issue which triggers this to action a simple reset of the MCU, rather than becoming trapped in the boot ROM.

The running firmware is programmed into QSPI flash chip but code is loaded into RAM at start-up by a boot loader program, from where it is executed. The design includes a display screen, and interface data for this remains in QSPI flash, from where it is loaded during firmware execution, as required, using the FlexSPI interface.

It is notable that the observed crash most frequently occurs when one or more LPUART interfaces on the device are active, in particular LPUART2. There are 3 of these interfaces being used in the project, to read/write serial data over RS485 links. If the software tasks associated with these LPUARTs are disabled within firmware, the crash is not seen to occur.

A screenshot is attached showing the CPU registers, giving the execution location within boot ROM after the crash occurs. This is obtained from the CrossStudio debugger environment, with a Segger J-Link connected to the PCB where the firmware is running. Unfortunately, due to the the nature of the "crash" into the boot ROM, it is not possible to determine state of firmware immediately before the crash occurs, or what may be causing this.

Could anyone offer some guidance on further investigations for this issue? Have similar issues been reported on this MCU or other MCU, perhaps related to documented (or undocumented) errata? In particular, it is interesting that the crash seems to be related to LPUART usage.

Thanks for any assistance with this issue.

[Hui_Ma]

Hi,

First of all, sorry for the later reply.

From the issue description, looks like the issue has relationship with LPUART module.

Please check if there with any pin multiplexed with LPUART and another modules during the code execution.

Mike

[pconway · Accepted solution]

Hello,

Thanks for the response. We have identified a possible cause and fix for the issue as follows:

- The three LPUART ports are used as MODBUS interfaces in RTU mode.

- For RTU character timing, the PIT hardware timer module is used. 

- The PIT module as being powered down and its clocks turned off after each usage of the timers.

- In a case where there is traffic on three LPUART modules, it seems possible that a race condition arises where an access is attempted to the PIT module when it is powered down. Hence the random occurrence of the crash into the boot ROM.

- An acceptable workaround for us is to simply always keep the PIT module powered, since the power savings of turning it off are negligible anyway. And this avoids the possibility of an invalid access.

As such, this issue can be regarded as solved.