LPC43xx debugging on the M0, problems with breakpoints

[lpcware]

Content originally posted in LPCWare by sh on Fri Oct 11 03:54:21 MST 2013
I am trying to debug code running on the Cortex-M0 using the LPC4330-xplorer and the LPC-Link2 with LPCXpresso 6.04 on a Windows 8 machine.

My problem is that even without any breakpoints defined, I get error messages like this:

Target error from Set break/watch: Ep(20). Unable to set an execution break - no resource available.

This happens even when just moving execution to a new address.

The corresponding Redlink command is displayed as:

Command In: $Z0,14057138,2

As you can see, I'm trying to set an execution address in the SPIFI area.

The Cortex-M0 has two hardware breakpoints available, doesn't it? Why is there no resource available anymore, then? And why is an execution break attempted when I just want to move to another address, without restarting execution yet? Would it not suffice for the debugger to just change the content of the PC register?

More generally, how does one best cope with the limitations of hardware debug support of the M0 core when executing from flash (internal or external)? Any tips?

[lpcware]

Content originally posted in LPCWare by sh on Fri Oct 11 06:54:27 MST 2013
I have seen the FAQs, thanks. The board is an older one and has an LPC4330; the SPIFI-flash is a Spansion S25FL032P1F.

I don't actually use the multicore app wizardry. I have two independent projects which can be loaded independently, because I currently work on the M0 application, and don't see a point in reloading the M4 code every time. The M0 application is almost 200 kByte in size and posting it in toto would probably be somewhat excessive. The map file for the M0 application is 700 kByte already. Tell me if I should post it nevertheless.

I should add that I have the M4 reprogram the clocking setup, and the SPIFI, to get best performance. The cores are clocked at 204 MHz, and the SPIFI is clocked at 80 MHz divided down from the USB PLL using IDIVA and IDIVB in cascade. I do that using code executing from RAM before starting the M0. This seems to work, since the M0 code does start up properly, I just can't usefully debug it due to the symptoms I described.

There are more debug problems, by the way. The machinery gets into a non-working state quite frequently, so that I have to manually kill the redlink server, and disconnect/reconnect target and LPC-Link2, otherwise it tells me that the core I'm trying to debug is already busy. It seems that the various parts of the debugging infrastructure get out of sync somehow.

And one more question: Is it possible to set up debugging in such a way that I can start the slave (M0) application and hit a breakpoint on main() in a similar way as on the M4? Currently I help myself with an endless loop in the M0 application at a point where I would otherwise have a breakpoint, but you can see why that's inconvenient.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Oct 11 06:29:53 MST 2013
I assume that you have already looked at:
http://www.lpcware.com/content/faq/lpcxpresso/lpc18-lpc43-support
http://www.lpcware.com/content/faq/lpcxpresso/lpc43xx-multicore-apps
[and the xref'ed links they contain].

Can you confirm exactly what part is on your board? Is it really an LPC4330 (no internal flash), or is it actually an LPC4337 (with internal flash)? All recent boards actually seem to be fitted with LPC4337 - and this can cause issues if you have the tools set up to expect an LPC4330.

Thus make sure the tools are configured to match the actual hardware. If you have internal flash, we would generally recommend using it - executing from internal flash will generally give a noticeable performance improvement.

If you are still having problems, then please confirm the actual details of your MCU, and export and post your project, or if this is not possible, at least provide the map file and axf generated by the linker.

http://support.code-red-tech.com/CodeRedWiki/ImportExport

Regards
LPCXpresso Support