Source level debug with mbed studio 1.3.0

Mbed Studio
1

I am trying to debug code which I took from multitech build with internal compiler with success
Thank I exported this sources for the build tree into mbed studio. I bouild debug version and setup several break point.
When I hit debug button , debugger suppose to start at main which I do not see , that I did step over and debugger stops at a a source not where bear point is set. I attached 2 scree shots showing that. Can you please give me instruction , how I can build so I can do source level debugging and examine local valuables

debug-stop-at-main- step
debug-stop-at-main- step1920×1080 347 KB
debug-stop-at-main
debug-stop-at-main1920×1080 340 KB
.

2

I’ve seen this too, I’m sure it happened when updating to 1.3.0. Some application do break into main() but debugging into a function may end up in some non-related file. Other applications just never seem to land in the correct code. For me debugging is essentially broken now. Any tips/fixes would be most welcome!

3

You can try changing the optimisation to O0

You find this under mbed-os/tools/profiles/debug.json

For the ARMC6 settings, there is an option “-O1”. Try making it “-O0”

4

Hi Nicholas, thanks for tip but I got linker error
Error: L6406E: No space in execution regions with .ANY selector matching ./libxdot-mbed5/libxDot-ARMC6.ar(SxRadio1272.o)(.text._ZN4mbed8CallbackIFvvEE13function_dtorINS2_16function_contextIPFvPKvES5_EEEEvPv).

Error: L6406E: No space in execution regions with .ANY selector matching

What are my options ,Thanks

5

Are you using a shared library? As I recall, it only works with standalone projects (sorry - I should have mentioned this). I’ve also reported this as a bug

6

Hi Nicholas:
I am not using share library for Mbedos.
My version is 5.15.1 , I was provided it with do-at-firmaware which I need to base my changes from.

I Even tried to use #pragma o0 fo main and another source file to do single source step but is did not help me. Pragma suppose to override -o1 command like option but it did not happened.
What are other options may be in my case.
This is something specific for the option in do-at-firmware. I can debug os-example-blinky and empty.
Thanks

7

Thanks Nicholas, I wondered where options could be changed!

A blank project, no libraries, created fresh in Studio 1.3.0 on Win 10, fails (but with different linker errors for me):

 [Error] @0,0: L6218E: Undefined symbol mbed::RM1000_AT_CellularStack::SOCKET_TIMEOUT (referred from BUILD/DISCO_L475VG_IOT01A/ARMC6/mbed-os/connectivity/drivers/cellular/RiotMicro/AT/RM1000_AT_CellularStack.o).
 [Error] @0,0: L6218E: Undefined symbol mbed::UBLOX_AT_CellularStack::SOCKET_TIMEOUT (referred from BUILD/DISCO_L475VG_IOT01A/ARMC6/mbed-os/connectivity/drivers/cellular/UBLOX/AT/UBLOX_AT_CellularStack.o).
 [Error] @0,0: L6218E: Undefined symbol mbed::UBLOX_N2XX_CellularStack::SOCKET_TIMEOUT (referred from BUILD/DISCO_L475VG_IOT01A/ARMC6/mbed-os/connectivity/drivers/cellular/UBLOX/N2XX/UBLOX_N2XX_CellularStack.o).

This is using Mbed OS v6.3.0 compiled with ARMC6 v6.14.

‘-O0’ seems to be not recommended for ARMC v6?

I thought I’d try a really basic app, created from fresh in Studio:

Basic Mbed app

I added 3 breakpoints and hit debug. These are the 4 lines it repeatedly breaks at:

 Thread 2 "main" hit Breakpoint 1, 0x08005e04 in main ()
 Thread 2 "main" hit Breakpoint 2, some_func (foo=42) at ./main.cpp:4
 Thread 2 "main" hit Breakpoint 4, main () at ./main.cpp:13
 Thread 2 "main" hit Breakpoint 3, main () at ./main.cpp:12

 Thread 2 "main" hit Breakpoint 1, 0x08005e04 in main ()
 Thread 2 "main" hit Breakpoint 2, some_func (foo=1) at ./main.cpp:4
  1. I didn’t stop at the start of main (as per the settings) nor at the expected first breakpoint; line 8. I’ve no idea what ‘0x08005e04’ means: the debugger didn’t show a current line.
  2. The next breakpoint was inside the some_func, as expected for the 1st call.
  3. Next is line 13, as expected for the 2nd some_func call.
  4. I’ve no idea why it stopped at line 12: no breakpoint set there.
  5. The breakpoint sequence then repeats starting with the 2nd function call.

It feels to me that optimisation could be the cause of some of the above, even though it makes debugging really hard. But for the original poster’s issue, with more complex applications things get much worse (breaking on non-code lines that have nothing to do with the application) so I can’t see it’s just optimisations.

I intend to try an older version of Studio if I can find an installer.

8

@sergeyuskach @ChrisSmith42

This is not really a solution I appreciate, but my students and I have started using (at least for now) the GCC compiler. We’ve had more success getting code to build and debug. Worth trying.

There is another post here - GNU Compiler with mbed studio? - Mbed Studio - Arm Mbed OS support forum