MCUXpresso IDE not adding temporary breakpoint at main()

[anirudhan]

I am using v11.0.0 [Build 2516] of MCUXpresso IDE which is based on Eclipse IDE.

When I use it to debug, the IDE sets a temporary breakpoint at main(). Only upon the user clicking on start/resume, the program starts running. In ideal cases scenario the start/resume button is in a usable state as shown in the below picture. 

But after sometime, the IDE does not set up any temporary breakpoint at main(). Any breakpoints I set in the program are also overlooked while I enter the debug mode. The start/resume button is grayed out in the debug mode as shown in the picture below.

The program does not start running at main() as before, but it starts running at Thread #1 1 as shown below

I have made sure that "Skip all breakpoints" option is not selected. I have tried to clean and build, restarting the IDE, restarting the evaluation board with onboard debugger and also restarting my system. The problem still exists.

[lpcxpresso_supp]

Hi Anirudhan,

I have taken a look at this issue and cannot duplicate this problem using the example - 'evkbimxrt1050_lwip_dhcp_bm'.

I think you should step back from this and take a look at a simple example such as a LED blinky. The SDK includes an example called 'evkbimxrt1050_igpio_led_output'.

Please try and program this example and see if you arrive at Main().

If not, power cycle the board and see if the LED flashes i.e. the image in flash actually boots.

Fundamentally, there is either an issue booting any image, or an just an issue booting your particular image - once we have established this, we can move forward to solve your debugging problem.

Please report your findings.

Yours,

MCUXpresso IDE Support

[anirudhan]

Thanks for your support. I have used 'evkimxrt1050_lwip_dhcp_bm' and not 'evkbimxrt1050_lwip_dhcp_bm'. I am using the A0 silicon of iMXRT1052DVL6A on the MIMXRT1050-EVK board (SCH-R29538 REV A2).

I have tried the power cycle of the board, restarting the IDE and restarting my Windows system itself. 

As I already mentioned in my previous reply, I am able to resolve this problem through a workaround. But since it consumes a significant amount of time during debugging, I wanted to know if there is a simple way to reset the debugger configuration both on the IDE and on the board. The workaround that I currently follow is as below.

1. I mass erase a hyperflash

2. I build and debug a fresh SDK example and make sure it is working 

3. I then try to build and debug my application.

Fundamentally there is an issue booting any image. But not all images. For e.g. the FreeRTOS hello world example is working fine. But some examples like evkmimxrt1050_bubble and evkmimxrt1050_ecompass fail at the first try to launch it from hyperflash. I need to follow the workaround described above, then when I try to debug these two examples it is working fine. 

[lpcxpresso_supp]

In the first place, check https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2017/12/07/overview-of-using-the-... 

Generally this sort of issue on the i.MX RT1xxx devices is often down to incorrect boot option jumper configuration.

Regards,

MCUXpresso IDE Support

[anirudhan]

Thanks for your reply. I have followed the document to setup my board and my IDE environment. My boot option jumper configuration are exactly as the document details them out to be. I have tried the troubleshooting methods mentioned in the document, like mass erase of hyperflash and then flashing the image to the memory. The problem still persists. 

I import and debug a new freertos_hello example provided in the SDK and after that when I try to debug the application which was causing the above stated problem, the application has got a temporary breakpoint in the main().

So everytime I face a debug issue as stated above, 

1. I mass erase a hyperflash

2. I build and debug a fresh SDK example and make sure it is working 

3. I then try to build and debug my application.

Is there any other simpler way to resolve this problem?

[jorge_a_vazquez]

Hi Anirudhan Madhavan

Before seeing this behavior when you are not able to debug, what code you have loaded in the hyperflash memory? I saw that you were using the lwip_dhcp example code, did you modify this example, or you add another driver to it?

This issue could be present because the RT get loss or have a hardfault and the ROM code is not able to boot from the hyperflash anymore, so the steps that you are following load a "working" project and then the ROM code is able to take control of the RT device.

In the troubleshooting section shows the steps to erase the hyperflash by putting the device in serial downloader mode, this should work for this scenario.

Best regards

Jorge Alcala