Issues with LPCExpresso 7.0.0_92

[lpcware]

Content originally posted in LPCWare by robekras on Tue Mar 04 03:11:24 MST 2014
Two issues with LPCExpresso 7.0.0_92:

1)  I have a debug configuration for just connect to a running bootware (our own)  and another one for connecting to a running firmware. Running LPCExpresso 7.0.0_92 I can only sometimes connect to the running bootware. Very often I get the following in console window:

-----------------------------------------------------------------------------
The target endianness is set automatically (currently little endian)
/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names.suffix != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names.suffix != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
-----------------------------------------------------------------------------

This seems to happen if i have compiled with -O2
I compiled with -Og, and that seemed to work.


2) As I do some investigation in lwip issues I have compiled it with statistic on.
Which means I want to see the variables in lwip_stats. But I can't see everything.
When I do the same in LPCExpresso 6.1.4_194 everything is ok (the binary is the same. I did not recompile!).
Please see the attached screenshots.

I'm running Win7 64-bit.

Robert

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Oct 14 01:40:37 MST 2014
Please be explicit. Which problem?  Try to detail *your* symptoms and what you have tried to resolve them.

[lpcware]

Content originally posted in LPCWare by monnoliv on Tue Oct 14 01:01:09 MST 2014
Hello,
Have you find a solution for this problem?
Regards,
Olivier

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Aug 28 00:43:48 MST 2014
Thanks for this. We have now been able to reproduce the crash and will investigate.

[lpcware]

Content originally posted in LPCWare by nidalpres on Wed Aug 27 22:12:40 MST 2014
This happens when I try to set breakpoint at the line of code that is not complied/linked into firmware.

How to reproduce:
Function A that calls function B is not compiled into firmware because it is surrounded by #ifdef statements and I can't set breakpoint in function A.
Function B (called by A) is not surrounded by #ifdef statements but linker has not linked it into output, since it is only called by function A.
Since function B is not surrounded by #ifdef statement, IDE allows me to set breakpoint anywhere in that function. If debugging session is running or I try to start one, GDB crashes.

i.e.

// somewhere
#undef ENABLE_SOMETHING

// somewhere else
#ifdef ENABLE_SOMETHING
void functionA()
{
  functionB(7);
}
#endif

// setting breakpoint within this function will crash GDB
// if the only one that calls this is functionA()
int functionB(int param)
{
   int val;
   val = param + 9;
   return val;
}

Removing these kind of breakpoints (or any breakpoints unrelated to project) fixes this problem.

[lpcware]

Content originally posted in LPCWare by Fklein23 on Fri Jul 18 09:04:50 MST 2014
Thank you Thank you Thank you!!!!!
I have version 7.2.0 and had the same problem. Removing all breakpoints did the trick.
WHEW!!

[lpcware]

Content originally posted in LPCWare by mubes on Thu Jul 10 10:32:22 MST 2014
If it helps, I have seen similar symptoms if you set a breakpoint on code that is subsequently removed from the image. The classic case is when you've got code in an ifdef or when the optimiser removes code that's not referenced.  In all cases I've been able to get out of the mess by deleting all breakpoints from the debug perspective and (on occasion) re-starting lpcxpresso....note that deleting the breakpoints using the breakpoint icon in the margin doesn't seem to have done the biz for me.

DAVE

[lpcware]

Content originally posted in LPCWare by b00lean on Tue Jul 08 14:48:48 MST 2014
I'm sorry, I didn't expect support to actually work on this issue. Copying gdb was ofcourse just workaround.

I will create the test package tomorrow for you so you can reproduce the issue.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 08 07:24:17 MST 2014
At the risk of sounding like a broken record, we still have not been told how to reproduce this issue and therefore cannot investigate the cause.

Also, copying GDB from LPCXpresso v6 to v7 is definitely NOT recommended. The debug table format has been upgraded between these to releases and so the older version of GDB will not support some of the newer features introduced in v7. i.e. you may well encounter strange debug issues.

[lpcware]

Content originally posted in LPCWare by b00lean on Tue Jul 08 06:10:19 MST 2014
Replacing /usr/local/lpcxpresso_7.2.0_153/lpcxpresso/tools/bin/arm-none-eabi-gdb with arm-none-eabi-gdb from gcc-arm-none-eabi-4_6-2012q4-20121016.tar.bz2 (google the archive download) fixes the issue on my linux setup.

[lpcware]

Content originally posted in LPCWare by brownm on Wed May 07 14:31:59 MST 2014
We have rolled back to ver 6.1.x and the problem has gone away.

We'll have to wait until there is a resolution for the GDB bug before upgrading again.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed May 07 00:50:13 MST 2014
Sorry, but that is not a recipe for reproducing the problem. We use LPCXpresso like that all of the time, as do thousands of other customers.

[lpcware]

Content originally posted in LPCWare by robekras on Wed May 07 00:38:14 MST 2014
As fas as I can remember (that's some weeks/months ago), the problem is reproducable by doing the following:

Import a different project into the current used workspace.
So you have two different projects within the workspace.

Activate and work with the first project. Start a debug session. Set breakpoints for the first project. Close the first project.
Activate the second project. Start a debug session (or try to start).

Regards
Robert

[lpcware]

Content originally posted in LPCWare by brownm on Tue May 06 23:42:31 MST 2014
Further to this - I believe that this forum thread is the same as this one

http://www.lpcware.com/content/forum/gcb-error

Also - it appears that it may be a bug in GDB (or the the way that GDB is getting called by LPCXpresso) Further comments are in the link.


Regards
Marshall

[lpcware]

Content originally posted in LPCWare by brownm on Wed Apr 30 16:19:30 MST 2014
Hi, I had this same problem, on the 7.1.1_125 version

Deleting the breakpoints also solved the issue, took several PC reboots and angst to find it.....

Regards
Marshall

[lpcware]

Content originally posted in LPCWare by mubes on Sat Apr 12 15:32:09 MST 2014
Wolf,

Good catch. Deleting old breakpoints also fixed the same issue for me.  Thanks.

DAVE

[lpcware]

Content originally posted in LPCWare by wizkaz on Fri Apr 04 02:28:46 MST 2014
Hello,
I had the same problem under Linux (openSuse) with the current version (7.1.1). I was able to reslove it by removing old breakpoints.

Greetings
Wolf

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Mar 11 04:02:28 MST 2014
I'm sorry, but unless you can provide us with an example that causes the GDB crash, I am unable to do anything further. This needs to be reported to the GDB maintainers and showing the error message is not good enough. They will need to be able to reproduce the problem locally.

[lpcware]

Content originally posted in LPCWare by robekras on Tue Mar 11 00:04:46 MST 2014
Again today problems with just connect the debugger to a target program.

As I wrote in the beginning I have two 'just connect to target program' configurations. One for connecting to our bootware and one for connecting to our firmware. The difference is mainly only that the bootware is running from location 0x0 to 0x27fff, and firmware is running from location 0x28000. Settings are identical except for referencing a different program image.
Connecting to bootware is not working (see attached screenshot).
Connecting to firmware is working, but I can't really debug because bootware is running but the image is for firmware.

When I start LPCExpresso 6.1.4 connecting to bootware is working. Same running target, same program image, no recompile.

I don't know whether this is of help:
With every version of LPCExpresso I had the feeling that gdb (or anything else which is related to LPCExpresso) is a little unstable. In older version I observed some blue screens of death. Locking of the whole computer.
I had problems in reconnecting to the target (when trying to reflash the program).
I had to disconnect and reconnect the Red Probe and/or to close LPCExpresso and sometimes I did a restart of the PC to get it working again.

Robert

[lpcware]

Content originally posted in LPCWare by robekras on Fri Mar 07 01:31:58 MST 2014
That's not so easy. Our project relies on our own hardware, and will not be running on a different hardware I think.
And I don't know whether my director will allow me to give the code away.

Nevertheless, if you have a EA 1788 board, with lwip and some USB running, you will see at least the error with the watch expressions.

Here is another issue which I think is related to the same problem in watch expressions.
Just add the ohci_data structure to the watch expressions window. In contrast to the inspection of lwip_stats some error messages are shown. Please see the attached screenshot.

Robert

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Mar 04 09:15:52 MST 2014
To be able to investigate these issues, we need to be able to reproduce the problem, and we have not seen these issues with our code - it seems to be peculiar to your project. so, can you please provide a project that we can use to reproduce these issues.

Thanks