Debugging stops unexpectedly

[harrievandeberg]

Debugging the project has always worked without any problems with LPCexpresso.

After some time I had to debug the project again, and used the new LPCexpresso version.
But now the debugger stops after a certain line of code.
Upgraded LPCexpresso to MCUXpresso IDE v10.0.2 (created new project).
Debugger still stops after the same line of code.
Using Red Probe + debugger, also used LPC-Link 1 and LPC-Link 2.

Using Microcontroller LPC1822

Line of code, after which the debugger stops:

#define     __IO    volatile             /*!< defines 'read / write' permissions              */
#define TFT_ADR_DAT    0x1D000040
#define _TFTwrDat( dat ) do { *(__IO u16 *) (TFT_ADR_DAT)= dat; } while(0)

_TFTwrDat(0);

The following error is given when a step over is done at the above line code:
Target reported errors

Reason:
15: Target error from Read Memory

Details:
15: Target error from Read Memory
15: Target error from Read Memory
Debug port inaccessible after access at location 0x00000000
15: Target error from Remove break/watch
Wire ACK Fault in DAP access

When te project is just "run", so no stepping, then the board does not work as expected.
When stopping debugging it gives the following error:
Failed to execute MI command:
-interpreter-exec console kill
Error message from debugger back end:
Can't kill process

Error reported by target
Target reported errors
Reason:
19: Could not stop execution from running
19: Could not stop execution from running
Cannot halt processor.

When optimization level is set to "Optimize (-O1)" the board works correctly and debugging can be paused, stepped over, etc.
But because of optimization not all lines can be debugged correctly.

Any suggestions to solve this problem?

[Daniil]

That has something to do with your clocks probably. Its not enabled or not engaged during register access. 

For instance for FLEXIO in MIMXRT: CLOCK_EnableClock(s_flexioClocks[FLEXIO_SPI_GetInstance(base)]);

[lpcxpresso_supp]

Nothing in the debug tools will be setting up your external RAM.

So if you stop at ResetISR() and don't then step through your code (until you reach main), then you haven't actually determined what your startup code may or may not be doing.

But fundamentally something in your code needs to be setting up the external memory controller and RAM. You need to determine what that code is, and whether it is being run for both a Debug and a Release build.

Regards,

MCUXpresso IDE Support

[harrievandeberg]

Debugging (when using the memory viewer) already stops before executing the startup code. 

So the startup code should not be relevant.

Also the startup code does not differ depending on debug symbols because I use one build configuration. In that build configuration I only change the "Optimize" setting. So nothing changes to the defined symbols, or other settings.

I search which lines of code must be optimized, so that a debug crash is prevented.

Now I can set for the complete project optimize off, only for one line code I have added pragma's, as below:

#pragma GCC push_options
#pragma GCC optimize ("O3")

u16 varVnr2sn( u16 vnr )
{
 return CvarShortname[ vnr ] & _word(0x7f,0x7f);
}

#pragma GCC pop_options

With the above added pragma's the debugger does not crash anymore. For me it works, but I still found it very strange. If you have any ideas, I would like to know.

Regards, 

Guus

[lpcxpresso_supp]

Is the memory at 0x1D000040 actually enabled correctly? Does it support a halfword access?

Where is the code you are executing running from?

Can you successfully view the memory using the Memory view?

Regards,

MCUXpresso IDE Support

[harrievandeberg]

The address 0x1D000040 is an address of the external memory interface.
A display is attached to this external memory interface.
Commands and data are written to 2 fixed addresses.
The address 0x1D000040 is used for writing data to.

The code executes from the internal flash bank A.

When the compiler's optimization level is set to "optimize (-O1)", and program stops on startup at main, it can read address 0x1D000040, it shows FFFFFFFF.

But when the compiler's optimization level is set to "None (-O0)", and program stops on startup at main, it cannot read address 0x1D000040, it shows ????????,
and immediately a popup error appears with the text:

Target reported errors

Reason:
15: Target error from Read Memory
15: Target error from Read Memory
Debug port inaccessible after access at location 0x1D000040
Debug port inaccessible after access at location 0x1D00027C

When I then click OK, and try to start (play button) to run the project the following error appears:
Target reported errors

Reason:
10: Could not start execution from stop  
10: Could not start execution from stop 
Wire ACK Fault in DAP access
15: Target error from Read Memory
Debug port inaccessible after access at location 0x1D000040
Debug port inaccessible after access at location 0x1D00027C 

Any ideas?

[lpcxpresso_supp]

So I would guess that there is some difference in the actions taking place in your application's startup code before you reach the default breakpoint on main().

Try changing the  default breakpoint so that you instead stop in the startup code (probably at the symbol ResetISR in the startup file). Then try stepping through both the Debug and Release builds and try to spot a difference in what your code is doing. It is possible, for instance, that you have some conditional code somewhere (based on the DEBUG / NDEBUG symbols).

Section 10.3.2, "Controlling the initial breakpoint (on main)" in the MCUXpresso IDE v10.1.0 User Guide covers how to change the default breakpoint.

Regards,

MCUXpresso IDE Support

[harrievandeberg]

I have set a breakpoint at the first line of code of the function ResetISR. 

Still the same happens as described in my previous message.

So, if no code has run, the fault will probably not be in the software code.

Also we have never had these issues before with older versions of LPCxpresso. 

Only with new versions of LPCxpresso and MCUXpresso we have this problem.

Can the optimize setting also influence the way debugging is performed?

Can it be a debug setting?