MCUXpresso 10.1.1 and MIMXRT1050-EVK debug

[dimaios]

Dear Sirs,

                 I'm trying to debug a very simple application using MCUXpresso 10.1.1 and the evaluation board MIMXRT1050-EVK ( i.MX RT 1050 evaluation board ).

1) I've tested the project under Windows 7 32bit and Windows 10 x64 ( same result )

2) The SDK_2.3.0_EVK-MIMXRT1050 was built selecting all the available options

The attached project is a simple GNU C++ 11 autogenerated by the IDE.

int main(void) {

       /* Init board hardware. */
    BOARD_InitBootPins();
    BOARD_InitBootClocks();
    BOARD_InitBootPeripherals();
       /* Init FSL debug console. */
    BOARD_InitDebugConsole();

    printf("Hello World\n");

    /* Force the counter to be placed into memory. */
    volatile static int i = 0 ;
    /* Enter an infinite loop, just incrementing a counter. */
    while(1) {
        i++ ;
    }
    return 0 ;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[A] Test A - Using the onboard debug interface ( USB cable )

1)  Start debugging

2)  Press F6 until the debug cursor is over the i++ instruction.

3) Now press F6 several times until the green line ( debugging cursor ) disappears.

WHY THE DEBUGGER DOESN'T STOP ON THIS INSTRUCTION ?

4) Look at the debugging led on the evaluation board .... it's blinking ...endlessy!

5) The disassembly window shows that the i++ instruction hasn't been optimized everything should work properly!!!

If you force a breakpoint in the while loop the cursor reappears and the debugging is restored!

WHY THE DEBBUGGER DOESN'T STOP ON THIS INSTRUCTION AND SEEMS TO FREELY RUN ?

[B] Test B - Using the Segger J-Link Base version 9.3 drivers 6.30b ( last available version )

Unpredictable behaviour.

Sometimes the F6 key is not mapped on the right function, sometimes the debugger jumps in the hardware_handler routine.

[C] Test C - Using the J-Link 2 

Same behaviour as explained in [A].

Best regards

[lpcxpresso_supp · Accepted solution]

Single stepping a very tight source loop like this can sometimes "confuse" GDB as you are effectively setting a breakpoint on the source line that you are already on, where you are already at a breakpoint from the previous step (depending on compiler and debugger versions, as well as options being used).

Typically if this happens, just press the "Suspend" button to pause again.

Alternatively, if you click on the i-> button in the Debug View to turn on "instruction stepping mode" you will then step at the instruction level rather than the source level, which will avoid the issue.

You could also avoid the issue by adding a __NOP(); operation after the i++ statement inside the loop.

Regards,

MCUXpresso IDE Support

[dimaios]

Ok thanks for your kind support, now it's clear why it happens.

Any idea why SEGGER debugger doesn't work properly ?

In the same loop ( i++ ) jumps into hardware_handler.

Thanks.