NXP project - debug is set to optimise

[aaronlawrence]

Just a minor note - in the NXP CrossWorks project, it seems the Thumb Flash Debug configuration is set to Optimize (for size). And hence single stepping etc doesn't work as expected.

This confused me for a long time. However, I find the CrossWorks configuration setup incredibly confusing, so ...

[mark]

Hi Aaron

Since the uTasker project concentrates on smaller Ethernet enabled processors (whereby the LPC23xx and LPC24xx are at the higher end) and attempts to make the most of the internal resources all configurations also use smallest memory optimisation - also debug (the idea being that one is then debugging the final code rather than something just similar to it - in some cases the optimisation enables the code to fit in the chip and without it it may no longer be possible).

However I never really noticed problems to single step (I used Crossworks tonight on an LPC2378 and this stepped nicely). But I also known that often debuggers are rather easier to control without optimisation set high. Generally the LPC23xx can be a bit tricky for some reason - I find that it is not possible to step through the PLL setup (letting it run though it is OK though).

The hardware breakpoints are quite limited too. I tend to make sure that only the one really required is activated (having too many could also cause problems with stepping, but I believe Crossworks warns of this rather than just missing a step). Sometimes it is also useful to try stepping in disassembler since this is usually easier for debuggers in some instances (eg. some branches which could go different ways) source level stepping may miss a breakpoint since it may try to set several to catch the path actually taken - an older version of Codewarrior was notorious for this and switches had to be stepped in disassembler otherwise it would never stop when trying to step).

Debugging on the LPC23xx MUST be performed with the watchdog disabled (see http://www.utasker.com/forum/index.php?topic=521.msg2223#msg2223). This can be either disabled by setting _DEBUG_CODE_ in app_hw_lpc23xx.h (at least in the latest version) or by pulling a specified port to '0' (specified also in this file - eg. P0-18 on the OLIMEX_LPC2378_STK [holding down BUT 2 at reset]. If it ran once the power must also be removed so that it actually stops again...

Regards

Mark

[aaronlawrence]

IMO this is a basic expectation of a "debug" build, that you can step through it cleanly.
On the 2366 I often had lines of code that plainly were functional that it could not break or step onto (e.g. a function call). This made it almost impossible to debug the ethernet PHY stuff.

Well of course it's your product but this is one customer at least who didn't expect that the debug build would be set to optimise.

I know about the watchdog and have already disabled it. Thanks.

[mark]

Hi Aaron

I checked with the experts who explained "quote"

In general, he's right; -Os does some nastiness in the debug records.  You will see things jump around for sure with -O1 and with -O2 and -O3 debug is non-existent unless you know what you're doing.  You can compile some things with optimization on and some off, in order to debug the things you need to debug...  The trouble is, without any -O settings, GCC produces totally crap code.

Possibly I have just become immune to the problems since I always debug with full optimisation and have learned to live with any restrictions.

However I accept the point that the debug build would be best configured with optimisation off. This change has been noted ready for the next release package. If the code size no longer fits the user will however need to either enable it again or selectively optimise accordingly.

Regards

Mark