Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12453 Discussions

connect to gdb stub for rtems rt os

Altera_Forum
Honored Contributor II
783 Views

Hi, 

 

I have been using the altera nios2-elf-gdb to debug over the usbblaster interface but this debugger knows nothing of the OS and it can be a limiting factor when working in complex programs with many threads. 

 

Therefore, I implemented a gdb stub which knows about the RTEMS RT OS that I am using. I decided that I would communicate with this gdb stub using a JTAG UART which I have added to the design. All of this mostly works and I can connect to it with "target remote | nios2-terminal --instance 1 --quiet --flush" in gdb, but unfortunately when gdb needs to break into the program it sends ascii 3, or ^C, but this causes the nios2-terminal to stop running (typically linux programs stop when they see ^C on the standard input). 

 

So..., here is the question, can one somehow connect directly to the jtag uart via the altera jtag server using TCP from gdb, or some program that I write? Is the protocol spoken by the altera jtag server documented? Is the source code for the nios2-terminal or nios2-gdb-server available so that I can make the necessary revisions (adding a signal handler for SIGINT? Does anyone know of a better way. 

 

I did also try using stty to change the interrupt character code but this hasn't been entirely successful because the nios2-terminal never stops when gdb stops and must be manually killed. I suspect that perhaps "target remote | program" in gdb is mostly intended for simulations debugging and for linux kernel debugging, and that with remote targets gdb typically expects to directly connect to the target via a serial port or to a tcp port. 

 

Any suggestions are appriciated, 

 

Thanks, 

 

Jeff
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
99 Views

FWIW, I resolved this issue using the netcat program (nc on the command line) which has a nifty feature of creating a tcp server that attaches to the stdin and stdout of nios2-terminal. Once the following Bourne shell script is running (passing command line argument --instance 1 on my system that has two jtag uarts) on the local host I can attach gdb with "target remote localhost:5107". I used the open-bsd version of netcat. 

# !/bin/sh 

 

cleanup () 

kill %nc 

rm netcatout 

rm netcatin 

exit 

 

trap cleanup int quit abrt segv bus ill pipe 

 

mkfifo netcatout 

mkfifo netcatin 

nc -l 5107 -k > netcatout < netcatin & 

while [ 1 ] 

do 

nios2-terminal $@ --quiet --flush < netcatout > netcatin 

echo restarting nios2-terminal 

done 

 

cleanup ()
Reply