Strange behavior on debugger startup

[lpcware]

Content originally posted in LPCWare by tvink on Fri Jun 05 13:59:31 MST 2015
Hi,

I have an lpc2294/01 project.  It has been commented down to a boolean initialization, a GPIO init call, and a main loop that does nothing but toggle between two states. 
I have a break point set on bBitPolarity = FALSE which is the 1st instruction in main();

When I start the debugger using the link in the "start here" panel the "current" line rests on an instruction in a procedure that should be inaccessible.  it is never called ( due to commenting ).

Pressing F5 makes the current line, the one with my breakpoint in main().  Pressing F5 again takes me back to a different line in the inaccessible code.

Pressing F5 again brings me to the 1st line in the GPIO Init code... which is where 3 F5's would normally take me.

In this case the debugger seems to work properly after these steps.



However various seeming unimportant changes to the source code have made differences in the behavior.  In some variations, the debugger never seems to synchronise with the source code.

I have tried various restarts... exit lpcxpresso, unplug debugger ( its an LPC-Link ), power cycle target, full power cycle of PC, target.

I have even tried making a new project and importing my code and header files in.

My hardware has the pull down on RTCK to enable the JTAG port.
I have weak pull ups on P2.26 and P2.27 to select "internal flash memory" at boot.
I have a pull up on P0[14] to avoid entering ISP mode.


Something is messed up but I am at a loss as to where to go next.


Please help.

[lpcware]

Content originally posted in LPCWare by Andersons on Fri Apr 22 08:05:40 MST 2016
im using node-inspector for some ES6/7 babel projects but there are some problems with breakpoints in function calls. First: Im using babel 5.5.6, node 0.12.2 and node-inspector 0.10.1. It seems that breakpoints within functions will not be triggered until I go into this function (F11) manually.Buy Lortab Online Without Prescription

[lpcware]

Content originally posted in LPCWare by alan70 on Fri Dec 18 02:39:34 MST 2015
Have you scrubbed your synthesis logs for anything like warnings or errors? The first thing I would do would figure out what's going on with that sel signal. If synthesis thinks it is not used then something is very wrong with it, you shouldn't have to override it with any special KEEP directive.
Pass4sure 300-101
For one thing I notice that you have inferred a latch on sel as you don't assign it in every state. Inferring latches is no problem for simulation, but your FPGA may not like it.

[lpcware]

Content originally posted in LPCWare by tvink on Mon Jun 08 14:15:56 MST 2015
I have a 4.8k pull down on RTCK to enable the debug port on the CPU.  It stays low for several hundred microseconds after reset terminates. 
However if I connect the LPC-Link and start the debugger RTCK is high all the time.  If I power cycle my target board RTCK is high
at the end of reset so I think the debug port may be getting disabled.

Are there any configuration settings of jumper settings for LPC-Link that I need to be aware of?

=====================

Concerning PINSEL2 above, I cut/pasted the address not the value in my post by mistake but the meaning is the same.  It is reading 0x0 which would disable the debugger. 

I have noticed that the address used by the debugger in the "peripherals" view tab for PINSEL2 is wrong.  The address of PINSEL2 is 0x0e002c014 on the LPC2294/01.
Could this indicate that there is something wrong with the MPU settings that the debugger is using?

I have gone back again and created the hello world app for this MPU and when I select "PCB" in the peripherals view tab, PINSEL2 comes up with the e002c008 address which again should be e002c014.

Thanks

[lpcware]

Content originally posted in LPCWare by tvink on Mon Jun 08 07:46:44 MST 2015
Thanks... back to -O0

I updated to the latest LPCXpresso with the same results.

An interesting thing...
When I enter debug, before I issue any run/step commands I am looking at PINSEL2.  It reads 0xe002c008 which is interesting.  This would indicate that my debug port is disabled.  But if that were the case, how would I get this far and read this register?   The only possible causes are the startup code, and my boot straps. ( I think )

I am going to re-review my boot strapping and look at these on the scope as reset ends to see if there is an explanation there. 

Tony

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Jun 08 06:35:21 MST 2015
I think you have misunderstood the FAQ. If you want a 'perfect' debug experience, you should use -O0. Any other level of optimization (and to increasing degrees) will cause code to be moved, re-ordered or removed completely.

[lpcware]

Content originally posted in LPCWare by tvink on Mon Jun 08 06:31:52 MST 2015
As usual I spoke too soon.

With the -Og option the debugger does now start with the current line highlighting the 1st curly in main()... but gets out of sync with the first press of F5. 
The debugger shows execution in a different module and the "current line" highlight changes with each press of F5.  The expressions that are available in the watch
window show values for the code in main even thought the "current line" appears to be in a different module.  Watch variables in the module where the current line
is showing are not available.

After a few depressions of F5, the debugger no longer responds to F5.  However the pause button works. 

I see that there is a new revision of LPCXpresso.  I am going to get that to see if anything improves.

Thanks,
Tony

[lpcware]

Content originally posted in LPCWare by tvink on Mon Jun 08 06:08:03 MST 2015
I am using LPCXpresso v7.7.2 [Build 379] [2015-03-31].

As noted in my 2nd reply to TheFallGuy I think it is now working with the -Og optimization setting.  I'll give it more testing today.

With the -O0 setting it did seem to work with the simple app that the new project wizard created...   (the one with the i++ counter in the main loop)
I then took my project c and h files and imported them into the wizard project and then had the problem.  But that was with -O0.

So hopefully -Og is the solution.

Thanks

[lpcware]

Content originally posted in LPCWare by tvink on Mon Jun 08 05:57:41 MST 2015
Hi TheFallGuy again...  I read your link after my hasty response.

I did not know about the Optimize for debug setting.  Changing to that (-Og) did the trick.
The debugger starts where expected with this setting.

Thanks again...

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Jun 08 05:56:50 MST 2015
Post the debug log:

http://www.lpcware.com/content/faq/lpcxpresso/debug-log

It would also be useful to know if you see the same behaviour using a simple "hello world" project created by the LPCXpresso new project wizard?

Also, what version of LPCXpresso IDE are you using?

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by tvink on Mon Jun 08 05:52:02 MST 2015
Good point about optimization... I did not think to look there.
But alas it is set to none.  C/C++ Build > Optimization > Tool Settings > None(-O0)

Thanks

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jun 05 14:08:13 MST 2015
What level of optimisation do you have set? See http://www.lpcware.com/content/faq/lpcxpresso/optimize-for-debug