Debugging in eclipse - stm8-gdb stops responding after running target

[Samson Chen]

Hi -
First of all, thank you for your work. Personally, I think there's going to be a lot of interest for this sort of tool, because this year, SDCC has gotten good enough at the STM8 port that it has finally outdone the antiquated, non-free compilers for this platform. http://www.colecovision.eu/stm8/compilers.shtml. That, plus the fact that the STM8 is an extremely cost effective chip, make a good debug toolchain extremely useful for general embedded designers and hobbyists.

The only problem to me is that there has not been a great debug toolchain for the SDCC/STM8.

Anyway, this is the furthest I've seen an open source toolchain work on the STM8 in eclipse, any IDE, or maybe even in the console. First note - in Windows, it's absolutely required to have cygwin in path before launching Eclipse for stm8-gdb to work (might be obvious to some, but not to me, who's used to MinGW compiled tools in Windows).

I can get Eclipse (oxygen 2) to work up to launching the debug perspective - but for some reason break/pause does not function in the IDE, and any actions after running the target simply do not work. Any ideas? It's so close to being a full-functioning debugger!

Let me know if there is any other information needed, or if the project has simply not gone that far yet.

Thanks,
Samson

[akre]

Hi,
you are absolutely right it is a big trouble to get eclipse to co-work with gdb especially all these path troubles. I don't know if compiling gdb for mingw would make it better.

As for your specific troubles with target not responding, it could be a number of problems ranging from eclipse is wrongly configured or openocd is not responding. In any case you should try launching gdb from command line with tui or cli interface and check everything works as expected. When you have verified everything you should have a look at gdb traces console in eclipse to try see if you could get some clues.

[Valentin Felsner]

Hi there,

first of all: big thanks for this work from me too, akre! And I hope necromancing this thread is fine as it perfectly fits my situation.

-> I am currently working on achieving the same thing. Getting eclipse to debug an stm8af6288. I have based the .cfg

This is what I have noted so far:
debugging with stm8-gdb --tui works fine, with a few exceptions.
- Step over doesn't work, instead it steps into the function every time.
- Continue and then ctrl+c for pausing works fine.
- Seems like there is no way to step out (go to return of function)? ST's proprietary STVD doesn't allow doing that either though. They only have run to cursor which failed last time I tried.

In eclipse, I get the same behaviour as Samson Chen. I can place breakpoints and they are hit on continue. But I can't just hit pause when free-running. This somehow breaks the link to gdb. Something in the eclipse <-> gdb protocol gets messed up there. Same goes for step out but this might not be supported by the stm8?
Step over equals step into, which is understandable because that's what gdb does. STVD seems to have no problems stepping over btw.

Btw: I am compiling with cosmic if that's of any help.

TLDR:
Any hints at how to fix step over and pause from free running would be much appreciated!

Thanks!

additional info on trying the gdb until command:

(gdb) help until
Execute until the program reaches a source line greater than the current
or a specified location (same args as break command) within the current frame.
(gdb) until kernel.c:96
Halt timed out, wake up GDB.

Program received signal SIGINT, Interrupt.
0x0000aeb6 in InitOS () at F:/cvs-sandbox/100291_cvs/100291/aux_mcu/software/source/STM8os/kernel\kernel.c:96
(gdb) info break
No breakpoints or watchpoints.
(gdb) s
target not halted
target stm8af6288.cpu was not halted when step was requested

interestingly though thbreak kernel.c:96 and continue worked fine. Maybe there's a way to map the until command in openocd to produce thbreak and continue instead?

attached my stm8af6288.cfg, values guessed and from datasheet / STVP:

---

# script for stm8af6288 family

#
# stm8 devices support SWIM transports only.
# 64K FLASH, 6K RAM, 2K EEPROM
#

transport select stlink_swim

if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME stm8af6288
}

# Work-area is a space in RAM used for flash programming
# By default use 1kB
if { [info exists WORKAREASIZE] } {
   set _WORKAREASIZE $WORKAREASIZE
} else {
   set _WORKAREASIZE 0x400
}

if { [info exists FLASHSTART] } {
   set _FLASHSTART $FLASHSTART
} else {
   set _FLASHSTART 0x008000
}

if { [info exists FLASHEND] } {
   set _FLASHEND $FLASHEND
} else {
   set _FLASHEND 0x017FFF
}

if { [info exists EEPROMSTART] } {
   set _EEPROMSTART $EEPROMSTART
} else {
   set _EEPROMSTART 0x4000
}

if { [info exists EEPROMEND] } {
   set _EEPROMEND $EEPROMEND
} else {
   set _EEPROMEND 0x47ff
}

if { [info exists OPTIONSTART] } {
   set _OPTIONSTART $OPTIONSTART
} else {
   set _OPTIONSTART 0x4800
}

if { [info exists OPTIONEND] } {
   set _OPTIONEND $OPTIONEND
} else {
   set _OPTIONEND 0x487f
}

if { [info exists BLOCKSIZE] } {
   set _BLOCKSIZE $BLOCKSIZE
} else {
   set _BLOCKSIZE 0x80
}

hla newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME stm8 -chain-position $_CHIPNAME.cpu

$_TARGETNAME configure -work-area-phys 0x0 -work-area-size $_WORKAREASIZE -work-area-backup 1
$_TARGETNAME configure -flashstart $_FLASHSTART -flashend $_FLASHEND -eepromstart $_EEPROMSTART -eepromend $_EEPROMEND
$_TARGETNAME configure -optionstart $_OPTIONSTART -optionend $_OPTIONEND -blocksize $_BLOCKSIZE

# Uncomment this line to enable interrupts while instruction step
#$_TARGETNAME configure -enable_step_irq

# The khz rate does not apply here, only slow <0> and fast <1>
adapter_khz 1

reset_config srst_only

# uncomment this line to connect under reset
#reset_config srst_nogate connect_assert_srst

[akre]

Hi Valentin,

my personal opinion regarding eclipse it is terrible for debugging. Don't get me wrong eclipse is great in many ways but it never worked well for any micros I tried. That said, you would have to look at openocd with debug messages on to try figure out why it hangs.

Regarding your troubles with stepping over, it is probably a matter of inadequate debugging info. Gdb it self (and my port) is unable to do stack unwinding, it relies 100% on the DWARF debug info where to find the return address for the current frame.

The only compiler I have tested so far is SDCC.

[Valentin Felsner]

Hi akre,
thanks for you super fast reply.

I just found something interesting about the step over issue from gdb with debug output enabled:

(gdb) n
Sending packet: $vCont;s:0;c#c0...Packet received: T05
Sending packet: $g#67...Packet received: 0000b02e010001004f17f829
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f87c6038fa102
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<?xml version="1.0"?>\n<threads>\n</threads>\n
553 CLRW x ; X = 0
(gdb) s
Sending packet: $vCont;s:0;c#c0...Packet received: T05
Sending packet: $g#67...Packet received: 0000b02f010000004f17f82b
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f87c6038fa102
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<?xml version="1.0"?>\n<threads>\n</threads>\n
554 LD xl,a ; X = Akku
(gdb)

Seems like gdb is sending the same commands for either 'n' or 's' ? So maybe there's a bug in gdb?

Also, could you maybe shed some wisdom on the following line of the stm8af6288.cfg as postet above:

hla newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0

Because gdb and openocd often compain about failed interrupts and I also see "Register not saved" a lot in gdb. Especially after e.g. an "until xx.c:xx" command failed.

Like so:

(gdb) n
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f87c6038fa102
Sending packet: $vCont;s:0;c#c0...Packet received: T05
Sending packet: $g#67...Packet received: 0000aded020001911317ea23
Sending packet: $m0,40#2d...Packet received: 01000001000e0001020000000001000500030705000000002b00000022000101b600000000000007070405070707070402070707070000070000000000000000
Register 4 was not saved
(gdb)

Just before I did until kernel.c:(a few lines ahead) and it failed, resulting in gdb running in a loop producing this output:

5a038f8bc6038fa102
Sending packet: $z0,b03a,1#59...Packet received: OK
Sending packet: $vCont;s:0;c:0#2a...Packet received: T05
Sending packet: $g#67...Packet received: 0000ae1e000001037417e523
Sending packet: $Z0,b03a,1#39...Packet received: OK
Sending packet: $vCont;c#a8...Packet received: T05
Sending packet: $g#67...Packet received: 0000b03a020001911317e723
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f8bc6038fa102
Sending packet: $z0,b03a,1#59...Packet received: OK
Sending packet: $vCont;s:0;c:0#2a...Packet received: T05
Sending packet: $g#67...Packet received: 0000aded020001911317ea23
Sending packet: $Z0,b03a,1#39...Packet received: OK
Sending packet: $vCont;c#a8...Packet received: T05
Sending packet: $g#67...Packet received: 0000b03a000001037417e223
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f8bc6038fa102
Sending packet: $z0,b03a,1#59...Packet received: OK
Sending packet: $vCont;s:0;c:0#2a...Packet received: T05
Sending packet: $g#67...Packet received: 0000ae1e000001037417e523
Sending packet: $Z0,b03a,1#39...Packet received: OK
Sending packet: $vCont;c#a8...Packet received: T05
Sending packet: $g#67...Packet received: 0000b03a020001911317e723
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f8bc6038fa102
Sending packet: $z0,b03a,1#59...Packet received: OK
Sending packet: $vCont;s:0;c:0#2a...Packet received: T05
Sending packet: $g#67...Packet received: 0000aded020001911317ea23
Sending packet: $Z0,b03a,1#39...Packet received: OK
Sending packet: $vCont;c#a8...Packet received: T05
Sending packet: $g#67...Packet received: 0000b03a000001037417e223
Sending packet: $mb000,40#ef...Packet received: 5f97724d038327065f97724a0383ae038afe94874f87a60587a60587a60587a605874f87725d038f271088c6038f5f97d6038c888684725a038f8bc6038fa102
Sending packet: $z0,b03a,1#59...Packet received: OK
Sending packet: $vCont;s:0;c:0#2a...Packet received: T05
Sending packet: $g#67...Packet received: 0000ae1e000001037417e523
Sending packet: $Z0,b03a,1#39...Packet received: OK
Sending packet: $vCont;c#a8...remote_pass_ctrlc called
remote_interrupt called
Packet received: T02
Sending packet: $g#67...Packet received: 0000b03a020001911317e723
Sending packet: $z0,b03a,1#59...Packet received: OK
Sending packet: $z0,0,1#63...Packet received: OK
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<?xml version="1.0"?>\n<threads>\n</threads>\n

After this, the register 4 not saved line popped up and stays there until I do a complete reconnect + openocd restart.

I have a feeling it might have to do with the above line from the cfg? it configures something about interrupts, doesn't it?

about eclipse as debugger:
I agree that it seems to struggle with many micros, getting it to work can be a pita, but if it does it's just great! Because I get full code navigation and comfortable editing functionality while debugging. I simply feel blindfolded when I'm not in eclipse. Outside it's just a pain to navigate code without outline + directory tree views and highlighting etc.
But that's my opinion and yours is valid for you as well.

Anyway, I don't expect eclipse support from you, I am just hoping to get the raw gdb debugging to work in a stable & robust way. Only then can I focus on getting eclipse to talk to gdb properly, which won't be any of your problems, I promise :)

about:

Regarding your troubles with stepping over, it is probably a matter of inadequate debugging info. Gdb it self (and my port) is unable to do stack unwinding, it relies 100% on the DWARF debug info where to find the return address for the current frame.

Would that mean that compiling with sdcc might improve things as sdcc would create better dwarf debug info?

[akre]

The way "next" works in gdb is it always do single step and after each step it checks if the stack frame was changed. If it was it use the debug info to figure out where on the stack (or in what register for processors with a return register) the return address is located. Then it insert a breakpoint at the return address and issue a countinue.

I am not sure why it looks for reg 4, if it is the same reg 4 as in the stm8 port of gdb it is the stackpointer. Remember the way DWARF stack unwinding works it is like a small script that for each line in your program tells the debugger how to do the stack unwinding. So if the stack unwinding does not work, do not blame gdb, it is all about how the DWARF debug info was generated by the compiler in the first place.

[akre]

Btw, I suggest you try SDCC just to get a feel how it works the way it should. SDCC is not perfect when it comes to debugging, specifically it has some trouble tracking where the variables are at.