Is ARM semihosting I/O supported with JLinkGDBServer and a J-Link OB attached to a Toshiba TMPM341 (Cortex-M3)? I've been poking around this forum for a while now, but I only turned up some very old messages, and no answers that really came out and said what was going on. The documentation (UM08005_JLinkGDBServer.pdf) makes mention of the "semihosting enable" and "semihosting ThumbSWI" remote commands, but their more detailed descriptions have a few hints that they're oriented to the older pre ARMv7 architectures.

If I try to do Cortex-M3-style semihosting (via a "bkpt 0xab" instruction), the debugger just halts, with a breakpoint trap. Here's a little gdb transcript:

(gdb) c

Program received signal SIGTRAP, Trace/breakpoint trap.
0x000003d6 in semihost_SYS_WRITE0 (s=0x20000004 "Hello, world!\n") at driver/semihosting.c:5
5 __asm ("mov r1, %[string]; \
(gdb) disas
Dump of assembler code for function semihost_SYS_WRITE0:
0x000003d0 <+0>: mov r2, r0
0x000003d2 <+2>: mov r1, r2
0x000003d4 <+4>: movs r0, #4
=> 0x000003d6 <+6>: bkpt 0x00ab
0x000003d8 <+8>: bx lr
End of assembler dump.

My GDB build should support things fine - I was using semihosting successfully with the LPCXpresso dev boards from NXP. The only major differences are the GDB server software and the specific target chip (the LPC I was using was Cortex-M0, but I don't think that should make a difference). So, presumably the LPC debug server software supports semihosting, but the Segger JLinkGDBServer does not - unless I'm doing something wrong, which is certainly quite possible.

Is there a way to get this I/O channel working? In the absence of semihosting, does JLinkGDBServer support DCC for I/O? What does it expect to see on the target side for support, if so?

Thanks for any information you can provide! Please let me know if there's any other information you'd find useful from my side.

While I'm here, one more question:

When I'm running off the PLL, executing a "wfi" instruction sometimes seems to cause the debugger to trap. It doesn't happen all the time - it seems to come and go in waves. I guess I'm setting something up wrong someplace, but any insight is welcome!

I had originally thought it had to do with running off of the internal oscillator vs the external oscillator/PLL (or vice versa), but that doesn't seem to be the case.

Semi-solved - the debugger loses its brain if the processor is idle for too long. I had the watchdog set for ~200 ms, so it looks like JLinkGDBServer just gave up the ghost. Adding an empty SysTick handler that runs every millisecond keeps things happy. Even doing 2 ms was too long - is there a way to configure the debugger to wait a bit longer before deciding disaster has struck and causing a GDB exception?

Great, thanks. When will the Mac OS X version be available? That download link shows only version 4.62a. I'll download the windows version and take a peek at the documentation in the meantime. Yeah, that's what it looks like is going on. I'm not sure if it's chip-side or debugger-side, but something definitely goes out to lunch. It seems OK if I just put an empty SysTick interrupt that runs every milliscond.

I downloaded 4.70 and ran it in a Windows VM, connected with the GDB I've been running on Mac OS X. It seemed to work OK, but the semihosting wasn't reliable. I don't know if that's related to the use of the NMI in this example program, though. I'll keep experimenting and hope for the best - any information about the 4.70 release date for Mac OS X will be appreciated!

Feature request to add: Can you deliver the semihosting I/O to GDB directly to be printed out on its console, rather than needing a separate terminal window? That would be much more convenient. It's certainly not a dealbreaker, though.

Agreed - I don't want the I/O in GDBServer, I want it in GDB itself - as if it were console I/O from a normal single-machine GDB session.

Thanks - I'll note that the LPCXpresso gdb stub does this out-of-the-box, so it's certainly possible. I'm sure you can get one and analyze the packets going back and forth to see what's up.