Linux/MSP430-GCC-OPENSOURCE: GNU debugger internal error

Andrew,

This thread was sent over to us on the tools team. The guy that normally looks as the GNU related threads is out but will be back tomorrow. Reporting bugs with the GNU toolchain here on this forum is fine. We can work to reproduce and then work with Somnium if needed to resolve.

Regards,
John

Thanks, John.  

If you need a core file, I believe I can generate one for gdb.  If you have a virtual box, I  can send you my binaries;  or I can allow a SSH login to a virtual machine if that would help  the team.

If you are attempting to reproduce, and need more information, don't hesitate to ask.

The following information ought to prove useful:

I used compile instructions for gcc 5, from:  www.simplyembedded.org/.../compile-install-msp430-gcc  to build my binaries.  Note:  follow link to "updated instructions"

My install directory is the only thing that differs, for I install to /opt/msp430/.local  and keep all source files in /opt/msp430/gcc2017

I  also downloaded and compiled mspdebug-0.23.tar.gz with no special configuration options except my install  directory being /opt/msp430/.local

To set up the debugger, I made a .gdbinit file and a msp430-gdbproxy.rc script, and a 69-ti-launchpad.rules for udev.

I added myself to the dialout group on unix: as root: eg:    usermod -a -G dialout andrew3

I then installed a udev rule (as root), called 69-ti-launchpad.rules to make the ti-launchpad USB driver allow dialout users to access the device.  The rule follows:

 

ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE="0660", GROUP="dialout"

Then I logged back in as andrew3 and I  plugged in  my ti launchpad, and executed "newgroup dialout"

At this point, mspdebug rf2500 became completely operational.

To make a script that can put mspdebug into proxy mode, I made the following  script:

#!/bin/sh   
# A script to put mspdebug into gdb proxy mode.
# Alternately will download and flash a program, if program name is parameter
if ps ax | grep -qe "mspdebug[^[]" ; then
	echo "mspdebug already running gdb proxy mode."
else
	echo "Starting msp debug"
	if [ -z "$1" ]; then
		mspdebug rf2500 gdb 2>&1 > /dev/null &
		disown
		sleep 2
	else
		echo "prog $1" | mspdebug rf2500
	fi

fi

And I made a gdb startup script, .gdbinit

shell msp430-gdbproxy.rc
set remoteaddresssize 64
set remotetimeout 999999
target remote localhost:2000
enable tui
layout src
layout reg

I apologize for the delay.  The MSP430 GCC experts have been notified.

Thanks and regards,

-George

Hi Andrew,

I haven't been able to reproduce this issue on Ubuntu 16.04 LTS.

-bash $ sudo ./mspdebug rf2500 gdb
MSPDebug version 0.23 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2015 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

Trying to open interface 1 on 027
Initializing FET...
FET protocol version is 30394216
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
Device ID: 0x2553
  Code start address: 0xc000
  Code size         : 16384 byte = 16 kb
  RAM  start address: 0x200
  RAM  end   address: 0x3ff
  RAM  size         : 512 byte = 0 kb
Device: MSP430G2xx3
Number of breakpoints: 2
fet: FET returned NAK
warning: device does not support power profiling
Chip ID data: 25 53
Bound to port 2000. Now waiting for connection...
Client connected from 127.0.0.1:56886
Clearing all breakpoints...
Running
Target halted

Running GDB with

target remote :2000
load
continue

does not cause the error you experience, the target continues and GDB stays connected as expected.

The program being debugged is a simple empty main program. What is the program you are trying to debug?

> Older tool-chains didn't crash on me.

Do you mean older versions of msp430-elf-gdb, or that you don't see this error when building your project with older versions of GCC?

> So, I'm unsure if the source code already includes all the patches in  the source patches file, or not. 

The source-patches archive is essentially the diff between the msp430-gcc released version of gcc/newlib/binutils/gdb, and the upstream release of the given component number. e.g. if you clone the the upstream GCC repository, checkout to the tag corresponding to the release specified in the name of the diff file, and then apply the source-patches, the source code should be the same as that in the source-full package.

>  If you have a virtual box, I  can send you my binaries

If you could attach the binary that you are loading onto the target, that would be helpful. I can then see if I can reproduce. What is the specific msp430 device you are connecting to?

> I used compile instructions for gcc 5, from:  www.simplyembedded.org/.../compile-install-msp430-gcc  to build my binaries.  Note:  follow link to "updated instructions"

May I ask why you didn't build the package using the build script provided with the source-full package? Once you have the prerequisites, it's as simple as running "/bin/bash README.txt".

What is the version of GCC used on your host system?

Furthermore, is there a reason you want to build from source and aren't using the pre-built binary package provided. Does the problem reproduce with the pre-built binaries? We run the DejaGNU GDB testsuite before shipping the binaries, so we can be confident in their quality.

Have you tried running GDB without your gdbinit script, and simply executing the program as I did above? Similarly, could you try with TUI disabled.

Thanks,

Hi,

I use a slackware64  system.  The library versions I  have are often  different  from Redhat or Ubuntu.  Historically, I have always had to build TI  toolchains from   source as prebuilt binaries will often not link.  Installing redhad or ubuntu  libraries to Slackware is a pain, so I avoid it when source code  is available.  The last toolchain  I built from TI was in late 2014 /  early 2015.  I do not recall GDB ever crashing at  that time, although many of it's features did not yet work.

In  all previous versions of   the toolchain, readme.txt,  was not an  executable script and it's contents didn't  change from version to version.  When I opened   the readme.txt, I noted  that the top  of the  script says it's developed on CENTOS  7... and the dependencies  are controlled by yum.  Slackware doesn't have yum, apt get,   or rpm.  It's a purely script driven linux  system, similar to gentoo linux.   Since I am not familiar with  CENTOS, except that I thought  it was a windows clone, I didnt look at  the readme.txt further.

The website link I gave you,  did the build of  the toolchain without use of any proprietary package manager,  and had an updated method for the latest version of GCC 6.2.  Therefore, that seemed like the most sure-fire way to build a proper  toolchain,  as he already had a working script.

My hosts' GCC is version 5.3.0  

I  am presently  compiling for  an MSP430g2231.  My  project directory  is called "source" and is attached to this   post.

There  are more  than one compiler on the market, so that I have a macro library  to aid in porting from one C  compiler to the  next.  The "vector.h" file is  for C porting of the MSP430.

I myself, however, have only compiled the code on  GCC  and  other compilers are not tested.

NOTE: The TI website won't let me upload a .txz file as an attachment.  The  following discussion   is incorrect,  because I can't upload the binary.   How do I work around this issue?

I have included my assembly language programing library called setisr.S which sets  the vector for an interrupt routine from assembly language.  The capital S extension allows the  C pre-processor and macro expansions to run on an assembly file.   This allows me to write  pure assembly language  programs for  the MSP430 series chips, without having to link in a C runtime library.  In the end,  assembly allows me to maximize chip usage.  setisr.S makes  programming interrupts very easy for me from  GNU Assembler,  which is why I wrote it.

Instructions  for compiling each file, is  found in the comments of  the header.  I  have a generic "build" script which  merely  grep's the source file for  the gcc line, and executes it.  I am not including the build script in this tar archive.

Inside the project directory you will find a.out.   That is the last binary I built from test7seg.S.  It  is an elf binary. You will also find "core" which I believe  is the last core  dump from GDB.

My project is running a seven segment IO board, which is operates from  SPI bus, LS bit first, 16 bit  data.   There are two 74HCT shift and latch register chips, which take the SPI data and turn it into a scannable 7 segment display.    There are 4 digits on the  display, and so I scan  the common led line low for one of four digits,  while outputting an 8  bit character  which is seven segments plus a decimal point.  I also use the same 4 scan lines of the seven segment display, to scan input switches for a keyboard.

The program is open loop with no error checking, so  it will  run even if no seven segment display is attached.

To convert  from binary to BCD, to seven segment,  there is an assembly language function found  in bin2dec.S  that does the conversions.

My original  project,  which  is not included here,  was a complete temperature/time controller for  a hot-plate and kilns. It measured resistance of the heating element  to estimate temperature, and regulated temperature in that way.

My original project compiled on the older versions of GCC, which  predate TI's move to a new open source tool-chain maintainer.  I am rewriting  the code, and testing it fresh.

I  used gdb to download the original firmware into my TI chip.  I don't recall gdb ever crashing on me  with the error message I  presently get.

Whether  or not I  use TUI, I gdb still crashes.

I have run gdb without the init script; but I  have never run it like you did, without setting   the remote message size.    I am not able to  test that right  now, but will try it later tonight.