Cannot debug in Embedded GDB mode

[Kaare]

@daav

Did you see the post I sent just before?
The logs indicate that the breakpoint is successfully set; isn’t it stopping the execution now?

You Sir, are my hero today

Now it all works perfectly. You we’re right, it did work even with the above message.

Finally i am able to debug again.

[daav]

@Kaare

Finally i am able to debug again.

Good to hear that.
Actually you were just unlucky enough to fall in the badly covered “non-generated.c” use case…
Anyway, thanks to have highlighted it for us: we’ll “protect” this with the adequate warnings in the next release.
Hoping you’ll enjoy the embedded debugger. From our experience, it is far more stable and reliable than RTE or JTAG have ever been…

[quimisur]

Hi!

I got this same problem, I try to debug my project and I’m always receiving timeouts from port. I’ve revised all project configuration to set everything as debug configuration, and I’ve a seems to be working generated.c. Could you highlight where do I need to look for to solve this issue?

Thank you!

[daav]

@quimisur

Could you highlight where do I need to look for to solve this issue?

Did you had a look to this post? → Cannot debug in Embedded GDB mode
And please note we’ve a bug with configured port persistence in the debug configuration: if you want to use something else that the default port (I mean the first one in the ports lists), you’ll have to reconfigure it every time in the debug config dialog.

[quimisur]

Yes, but I wasn’t talking about that. The only question I could do about the post you highlight is about the persistent mode, which I don’t know how to set.

The post I was talking about is:

viewtopic.php?f=108&t=5601&start=15#p24332

When it says you have to put ADL compilation mode to debug I don’t know where to set it.

Thanks for your answer.

[daav]

@quimisur

The only question I could do about the post you highlight is about the persistent mode, which I don’t know how to set.

Development mode is set by default by DS, so if you haven’t modified the configuration, it should be OK
(you just have to check the target is still in development mode after a reset; e.g. just by taking a look to the status view)

When it says you have to put ADL compilation mode to debug I don’t know where to set it.

If you have not disabled the application settings editor, you just need to use a “Debug” build configuration

[quimisur]

Thank you for the explanation, but I’m afraid is not enough for my environment and it’ still not stopping on breakpoints. I’ve revised all posts here so many times and have no clue about what’s happening, do you have something in mind about what should be happening?

Thank you

[daav]

Is your breakpoint set “early” in the application lifecycle?
As said above in this thread, there is some synchronization latency between the application start point and the point where the debugger is able to handle breakpoints. And also, starting a debug session doesn’t reset the application if not explicitly specified in the launch configuration.
The best way to be sure that breakpoints are working is putting one in an handle waked-up by an event you’re sure to control (e.g. an AT command).

Anyway, if you still can’t stop on breakpoints, please can you attach here the logs of the various GDB consoles when the configuration is running?
Even better, as you may have seen, a user posted a video record of what he’s really doing; if you could take the time to make a small one, this would be greatly helpful to understand what’s going wrong.

[quimisur]

It’s not the case, because it start with an initialization function in the main task, then jumps to the secondary task, starts the execution of my test and nearly in the middle(functions take almost a hundred of lines) I set the first breakpoint. The second is at the end of the function. I think it’s more than enough. Let me know how to send you the video and let see if you notice something wrong.

Thank you daav

[daav]

If the breakpoint still stands in a task initialization function, there should be an issue anyway. The latency I told you about is a matter of several seconds…
Can you give a try and delay your test function thanks to a timer?
And also, please be sure to configure the launch configuration for asking application reset, otherwise the debugger will just “catch” the application execution where it is currently running.

[quimisur]

I’m afraid I cannot, I did a firmware upgrade because I noticed firmware mismatches, and now my modem is not responding… Do you know how to bring it back? I’m in a hurry and I cannot find it through all posts… :’(

[daav]

Received your video: the issue was indeed a bad firmware version, since 7.43 was running on your target (Embedded GDB is supported since 7.45; note that in next DS release, we’ll add a check to help diagnose this kind of obvious “trap”).
About your FW upgrade issue, I noticed also on the video that you’re using an USB connection, which is not always pretty stable with DS. After the upgrade, did you try to use simple UART connection? Maybe the Firmware was correctly upgraded, but the USB connection simply broken…
Anyway, even if the Firmware is corrupted for any reason, you should be able to recover the bootloader on the UART1, in order to give a new try…

[quimisur]

It seems the firmware is broken, so I’m trying to recover the bootloader, but I have no luck, modem do not answer for any terminal, and M2M Studio just can open de port…

Forgot to mention I’m now using serial port, just in case USB is trying to kidding me…

[daav]

Are you still trying on USB?
Did you gave a try on UART?
Bootloader should automatically recover if FW is corrupted (connect on UART1 @115200, do an hardware reset, wait some time, try to enter AT commands…), but sometimes not…
In such cases, you have a last chance try by short-circuit RTS & CTS pins on the UART1 (+hardware reset), to force bootloader recovery. If by chance you’re using a Sierra Wireless development kit, you have a hardware switch named “XMODEM” near the UART1 on the board which does it for you.

[quimisur]

, not working at all. I got rid of USB, I’m just using serial port cable my distributor provided my with. I tried to short circuit the RTS-CTS pins(bottom right holes in the plug). No answer to any command, M2M studio claims “No target detected(no response to AT+WMSN)”…

[daav]

Afraid that you’re going to get in touch with your distributor for more support…

[quimisur]

Indeed I did it, just didn’t get I needed a special cable to use dwlwin, and recover the bootloader. The cable is on its way. I hope I needn’t so much support at the time it arrives, but I’ll get in touch in case I have any problem. Thank you daav for your patience.

[quimisur]

Finally I managed to load 7.46 firmware in my modem, but the problem isn’t going away, I set just one breakpoint at the end of my function, just to know it’s running. GDB console says this:

622,609 1-environment-cd F:/desarrollos/workspace/utils_test
622,625 1^done
622,625 (gdb)
622,625 2source F:\desarrollos\workspace\gdbcmd.ini
622,640 &“source F:\desarrollos\workspace\gdbcmd.ini\n”
622,640 2^done
622,640 (gdb)
622,640 3-file-exec-and-symbols F:/desarrollos/workspace/utils_test/[Target]_ARM_EABI_GCC_Debug/util
s_test.axf
622,656 3^done
622,656 (gdb)
622,656 4-gdb-set auto-solib-add on
622,671 4^done
622,671 (gdb)
623,046 5-environment-directory F:/desarrollos/workspace/utils_test F:/desarrollos/workspace/utils_t
est/.settings F:/desarrollos/workspace/utils_test/[Target]_ARM_EABI_GCC_Debug F:/desarrollos/workspa
ce/utils_test/[Target]_ARM_EABI_GCC_Debug/src F:/desarrollos/workspace/utils_test/inc F:/desarrollos
/workspace/utils_test/itf F:/desarrollos/workspace/utils_test/src
623,062 5^done,source-path=“F:/desarrollos/workspace/utils_test;F:/desarrollos/workspace/utils_test/
.settings;F:/desarrollos/workspace/utils_test/[Target]_ARM_EABI_GCC_Debug;F:/desarrollos/workspace/u
tils_test/[Target]_ARM_EABI_GCC_Debug/src;F:/desarrollos/workspace/utils_test/inc;F:/desarrollos/wor
kspace/utils_test/itf;F:/desarrollos/workspace/utils_test/src;$cdir;$cwd”
623,062 (gdb)
623,062 6-target-select remote localhost:10000
623,078 &“Sending packet: $qSupported#37…”
623,109 &“Ack\n”
623,109 &“Packet received: PacketSize=150\n”
623,109 &“Packet qSupported (supported-packets) is supported\n”
623,109 &“Sending packet: $?#3f…”
623,171 &“Ack\n”
623,171 &“Packet received: S07\n”
623,187 &“Sending packet: $Hc-1#09…”
623,250 &“Ack\n”
623,250 &“Packet received: \n”
623,250 &“Sending packet: $qC#b4…”
623,312 &“Ack\n”
623,312 &“Packet received: \n”
623,312 &“Sending packet: $qOffsets#4b…”
623,375 &“Ack\n”
623,375 &“Packet received: \n”
623,375 &“Sending packet: $Hg0#df…”
623,421 &“Ack\n”
623,421 &“Packet received: \n”
623,421 &“Sending packet: $g#67…”
623,484 &“Ack\n”
623,484 &“Packet received: 0000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000\n”
623,484 &“Sending packet: $m0,4#fd…”
623,546 &“Ack\n”
623,546 &“Packet received: E10\n”
623,546 &“Sending packet: $qSymbol::#5b…”
623,609 &“Ack\n”
623,609 &“Packet received: \n”
623,609 &“Packet qSymbol (symbol-lookup) is NOT supported\n”
623,609 6^connected,thread-id=“0”,frame={addr=“0x00000000”,func="??",args=[]}
623,625 (gdb)
623,640 7-break-insert test_utils.c:219
623,656 7^done,bkpt={number=“1”,type=“breakpoint”,disp=“keep”,enabled=“y”,addr=“0x00260be2”,func=“ma
in_task”,file="…\src\test_utils.c",fullname=“F:/desarrollos/workspace/utils_test/.settings/…\sr
c\test_utils.c”,line=“219”,times=“0”}
623,656 (gdb)
623,671 8-exec-continue
623,671 8^running
623,671 (gdb)
623,671 &“Sending packet: $Z0,260be2,2#a5…”
623,703 &“Ack\n”
623,703 &“Packet received: OK\n”
623,703 &“Packet Z0 (software-breakpoint) is supported\n”
623,703 &“Sending packet: $vCont?#49…”
623,765 &“Ack\n”
623,765 &“Packet received: \n”
623,765 &“Packet vCont (verbose-resume) is NOT supported\n”
623,765 &“Sending packet: $Hc0#db…”
623,828 &“Ack\n”
623,828 &“Packet received: \n”
623,828 &“Sending packet: $C07#aa…”
623,890 &“Ack\n”
623,890 &“Packet received: \n”
623,890 ~“Can’t send signals to this remote system. SIGEMT not sent.\n”
623,890 &“Sending packet: $c#63…”
623,968 &“Ack\n”

//////////////////

Sending packet: $qSupported#37…Ack
Packet received: PacketSize=150
Packet qSupported (supported-packets) is supported
Sending packet: $?#3f…Ack
Packet received: S07
Sending packet: $Hc-1#09…Ack
Packet received:
Sending packet: $qC#b4…Ack
Packet received:
Sending packet: $qOffsets#4b…Ack
Packet received:
Sending packet: $Hg0#df…Ack
Packet received:
Sending packet: $g#67…Ack
Packet received: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $m0,4#fd…Ack
Packet received: E10
Sending packet: $qSymbol::#5b…Ack
Packet received:
Packet qSymbol (symbol-lookup) is NOT supported
Sending packet: $Z0,260be2,2#a5…Ack
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $vCont?#49…Ack
Packet received:
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc0#db…Ack
Packet received:
Sending packet: $C07#aa…Ack
Packet received:
Sending packet: $c#63…Can’t send signals to this remote system. SIGEMT not sent.
Ack

Do you wonder why it should happen?

[daav]

GDB says that all is fine now!
If you haven’t changed your code yet, I guess that you still try to break in a task initialization function. Even at the end of such a function, it’s probably still too early because of the latency limitation mentioned above. Can you give a try by delaying your function processing with a timer?

[quimisur]

I’m not familiar enough with adl interfaces yet, but if this subcription is ok, it might delay the execution 30 secs, isn’t it?

tt = adl_tmrSubscribe ( FALSE,
30,
ADL_TMR_TYPE_100MS,
NULL );

I put it just before the breakpoint, and it seems it isn’t stopping either… I think it’s something…