MCUXpresso 10.1.1 and MIMXRT1050-EVK debug

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUXpresso 10.1.1 and MIMXRT1050-EVK debug

Jump to solution
968 Views
dimaios
Contributor II

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.

[01] F6 from start to variable increment.jpg

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

[02] Lost debugging cursor.jpg

WHY THE DEBUGGER DOESN'T STOP ON THIS INSTRUCTION ?

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

[03] Debugger Led blinking.jpg

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!

[04] Disassembly window.jpg

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].

IMG_20180209_165716.jpg

Best regards

1 Solution
748 Views
lpcxpresso_supp
NXP Employee
NXP Employee

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

View solution in original post

2 Replies
749 Views
lpcxpresso_supp
NXP Employee
NXP Employee

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

748 Views
dimaios
Contributor II

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.

0 Kudos