Debugger lockout when displaying peripheral registers (RT1062, IAR EWB ARM 9.10.1)

[Mysterion]

In our current project on a i.MX1062 platform (for now a MIMXRT1060-EVK, later a custom board) using the IAR EWB ARM 9.10.1 IDE, we often experience lockouts when stepping through the code.

The debugger log says something like:
- CPU status FAILED
- CPU is unpowered
- Unable to execute: driver error. After the error occurred, the program counter (PC) was
- Failed to clear breakpoint: Driver error; Debug mode got disabled
- cannot re-enable debug mode
- Cannot access ROM table

The only way out is either to hard reset the target, or to unplug and replug the I-Jet debugger (which assumedly leads to a hard reset to). Same issue when using the onboard CMSIS-DAP.

As turned out after a while, the issue only, but reproducibly occurs, if any uninitialised peripheral registers are displayed in the IDE (e.g. FlexSPI, LPSPI, SPDIF). As soon, the corresponding peripheral is clocked, everything is working fine. The issue also doesn't occur, if I just step through the code, without displaying the registers.

This is very annoying during driver development - when just these init routines are the point of interest.

The IAR support isn't aware of any issues like that (and also doesn't seem to know the platform very well). I'm not sure, if this is an IDE problem, or a limitation of the MCU, as the reference manual states for some peripherals, no access is allowed while uninitialised.

Is there anything I missed in order to resolve that problem?

[Mysterion]

The MCUXPresso IDE showas a similar behaviour, when displaying non-clocked peripherals. When running a PWM example from the SDK, and trying to display, for example, the SPDIF peripheral, an error is reported immediately:

15: Target error from Read Memory
15: Target error from Read Memory
Debug port inaccessible after access at location 0x40380000
Debug port inaccessible after access at location 0x40380004
Debug port inaccessible after access at location 0x40380008
Debug port inaccessible after access at location 0x4038000C
Debugging context: evkmimxrt1060_pwm LinkServer Debug

After that, no further debuggin is possible, as the target won't be detected anymore:

0 available SWD Devices detected.
Connect a device and try again.

The only way to get debug access again, is to unplug and replug the debugger connection (in this case the DAPLink).

The only workaround I found so far is to clock any peripheral right from the start which could be displayed accidentally, with its window maybe just having not been closed before doing a reset, running into the same lockup after hitting any breakpoint.

[kerryzhou · Accepted solution]

Hi Mysterion,

  After internal checking, I find these information which will be useful to you about this issues:

the RT module has two clock source: bus interface clocks and functional clocks.
You could get related info from RT1050 reference manual: chapter 13.3.3.1 Interface and functional clock
It is an expected behavior, when the module bus clock disabled and when debugger access related module register will trigger bus fault, then debugger connection will abort debug session and report fault.
While, you also see some modules still be accessed registers when CCM disable related clock. In fact, those module bus clock source still be available. The CCM only close the function clock.

So, when you do the peripheral debugging, you can put some breakpoint in the peripheral initialization code, when it is entered, then you can open the peripheral register to check the details.

In fact, I also do this operation when I debug the code and check the register information.

Wish it helps you!

Best Regards,

kerry

[kerryzhou]

Hi Mysterion,

  Do you use the MCUXPresso IDE and test with the same process, whether you can reproduce the issues or not?

  Please help to check it at first, as I know, IAR seems really have register access issues when the peripheral register is not clocked.

  Please check the NXP MCUXPress IDE, and test whether you can reproduce the issues or not?

https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-i...

Any updated information, please kindly let me know.

Best Regards,

Kerry