VisualGDB comes with outdated compilers for MSP430. It is clearly focused on newer hardware platforms. I myself contributed to the msp430-gdbproxy++, since there are not so many customer using this platform.

Fact is that versions after the community version were not able to optimize code in the level that the 4.6 version did. Since version 9 the Mitto System version is quite wonderful and should not be missed.

My attempt to contact the technical support was not fulfilled by SysProgs, so I did myself a pack with files to enable support for the latest TI MSP430-GCC.

In this text I will cover the steps needed to perform this.

TODO

In a standard installation of the Mitto System MSP430 compiler the path is where the gdb_agent_console is stored is:

C:\ti\msp430-gcc\bin\gdb_agent_console.exe

For this tool we require a board file, that is provided in the following path:

C:\ti\msp430-gcc\msp430.dat

Later in this text we explain options to customize the board file. Please make sure you preserve the original board file and make copies when customizing it. Then you will need to adjust this parameter accordingly.

VisualGDB's default port number is 2000, and the command line is quite simple:

cd /d C:\ti\msp430-gcc\bin
gdb_agent_console.exe -p 2000 ..\msp430.dat

You can create a .bat file on your desktop and add these lines to it and just double click it to launch the gdb_agent_console.

Note that a complete description of the gdb_agent_console can be found on chapter 4.7 of the slau646f - MSP430 GCC Toolchain - Users Guide

TODO

TODO

TODO

Note that msp430-gdbproxy++ is a very good GDB remote agent, provided with the standard installation of VisualGDB, but the gdb_agent_console is the official software used by the TI CCS IDE.

I am still comparing both products to see what is the best option.

The following table summarizes the current findings:

This is the usage help for the gdb_agent_console tool:

Usage: xds_gdb_agent [-p <port>] [-f <flash>] <board-data-file>

<port> is the server port number, default value is 55000

<board-data-file> is the CCS format board data file that describes the debug
probe connection and target device

<flash> is <family[:option,option,option...]> where family is the type of 
flash algorithm to use, and the option list may be a combination of flash 
options.
The only supported value for family is MSP432. The supported options are:
  ResetBefore -- reset the target before writing to flash
  NoResetBefore -- do not reset the target before writing to flash
  ResetAfter -- reset the target after writing to flash
  NoResetAfter -- do not reset the target after writing to flash
  ResetSoft -- use a soft reset
  ResetHard -- use a hard reset
  EraseMain -- erase the main flash memory before flashing (mass erase)
  EraseMainAndInfo -- erase main flash and information memory before flashing
  FactoryReset -- do complete erase (factory reset) before flashing
  EraseBySegment -- erase only the necessary segments before flashing
  NoErase -- do not erase flash before flashing (not recommended)
  BSLErase -- allow BSL information memory erase
  NoBSLErase -- do not allow BSL information memory erase
When options are not defined, flashing defaults to the following:
ResetBefore,ResetAfter,ResetHard,EraseMain,NoBSLErase

Note that for the MSP430, flash support is automatically enabled with 
default options;
the -f switch can be used to override the defaults, but is otherwise not needed.

And for the msp430-gdbproxy++:

Usage: msp430-gdbproxy [options]
All options are optional:
  --noeem - Disable EEM mode (required for advanced breakpoints)
  --keepbp - Keep software breakpoints in FLASH (reduces erase cycles)
  --bp_insn=0xNNNN - Override software breakpoint instruction (default 0x4343)
  --bpmode=<mode> - Specifies how to create breakpoints with "break" command:
    soft - always create software breakpoints (run "hbreak" to override)
    hard - always create hardware breakpoints, fail when out of them
    auto - create hardware breakpoints while available, then software
  --progport=<port> - Specify port for TI FET (default is "USB")
  --voltage=<nnnn> - Specify Vcc voltage in mV (default = 3333)
  --tcpport=<n> - Listen on TCP port n (default 2000)
  --keepalive - Keep running after GDB disconnects, wait for next connection
  --autoerase - Erase FLASH when debugging is started
  --eraseinfo - Erase FLASH also includes information memory
  --nohint - Do not show the 'how to start debugging' message
  --verbose - Enable verbose diagnostic output
  --iface=jtag/sbw/sbwjtag/auto - Specify connection interface
  --ifacespeed=slow/medium/fast - Specify interface speed
  --32bitregs - Emulate 32-bit registers (required by GDB 7.7+)

Command line usage on msp430-gdbproxy++ is more complex than on the gdb_agent_console, which requires a more advanced knowledge of the options and effects, while the TI option works in general automatic.

For the general case, TI option seems the way to go, as long as automatic settings perform well. On specific situations as lengthy cables, or some other peculiarity chances are that msp430-gdbproxy++ will have an option to circumvent the issue.

An interesting improvement on the GDB protocol is the use of RLE to compress output data for repetitive byte sequences.

This depends severely on the memory contents to be significant, but certainly a desired feature.

Preliminary tests using our unit test suite could confirm this advantage for a large flash memory read operation:
49,2 kB/s vs. 53.6 kB/s. msp430-gdbproxy++ is clearly faster here, but it is important that the --ifacespeed=fast command line option is used. Tests were performed using the MSP-FET and the latest MSP430.dll.

The gdb_agent_console has a complete customizable way for the erase and for details check the user's guide.

Basically you have two events called msp430_connectaction and msp430_loadaction, indicating start of a connection and program load started. One can associate values such as unlockbsl, unlockprotected, resetbefore, resetafter, erasefactory, erasemain, erasemainandinfo, eraseuser and erasesegment to configure the actions that can be done when the event occur.

Newer gdb version supports the vFlashErase command as part of the standard, but for this to operate, gdb needs to be compiled with XML support and the emulator needs to inform the memory layout. Msp430-gdbproxy++ supports this feature, gdb_agent_console in the other way, not. Regardless, the use of this feature returns an error, caused by the lack of XML support. A fault from the distro.

Another question regarding erase flash is how the info memory is handled. In msp430-gdbproxy++ this is a command line option, while gdb_agent_console has a command that includes it.

Regarding unlocking of the INFOA segment: there is no support on the msp430-gdbproxy++ to unlock the INFOA on devices that features the LOCKA bit in the FCTL3 register (slau144, slau208, slau272, slau335, slau367, slau445 and maybe others).
The gdb_agent_console has a unlockprotected option that covers this option.

Here is an example:

# config version=3.5
$ msp430
  msp430_drvr=msp430.dll
  msp430_port=TIUSB
  msp430_vcc=3.3
  msp430_connectaction=unlockprotected
  msp430_loadaction=erasemainandinfo
$ /

It is not recommended to edit the original board file, supplied with the compiler. Make a copy of msp430.dat and customize the copy.

Most of the times, MSP430 hardware project considers the use of a lower power supply voltage, to reduce overall power consumption, specially when using lower clocks. With the exception of the parallel port emulator used on the early beginnings, debug emulators have ways to program lower target voltages.

In the case of msp430-gdbproxy++ this is achieved with a command line option. If for example, a target using 3V power supply the command line option would be:

--voltage=3000

On the gdb_agent_console things get more complicated here. If you look at the msp430.dat board file contents you will see:

# config version=3.5
$ msp430
  msp430_drvr=msp430.dll
  msp430_port=TIUSB
  msp430_vcc=3.3
$ /

Aside the counter intuitive delimiters, which reveals very creative developers (Q: Why not just clone the .ini file syntax supported by Win, Unix, Python, etc? A: Reinvent the wheel), the file syntax is still quite simple.

To adjust other target voltage I cannot recommend to edit the default file, so we start duplicating it, for example:

C:\ti\msp430-gcc> copy msp430.dat msp430-3V0.dat

and edit the contents of the duplicated file, so that the voltage line looks like this:

  msp430_vcc=3.0

One interesting feature of the MSP430 is the implementation of up to 8 hardware breakpoints. The maximal number of hardware breakpoint registers vary according to the model of your MSP430 device. Larger parts have more breakpoint registers, while lower can reduce this up to two instances.
To understand what this means, think of a set of hardware embedded registers that are able to compare at the instance of a new instruction fetch, the current loaded address and stop the CPU execution when a match happen.

A software breakpoint works in a very similar way, reserving one of these hardware registers to implement the software breakpoint feature. In this mode, an invalid instruction code is written to the desired flash memory where a breakpoint should hit and the hardware register is programmed a bit different, so that the instruction fetch contents is compared, instead of the address. When a match occurs the CPU is stopped at the hit. In the case the user continues the code, the invalid instruction code is replaced by the correct instruction by the emulator on the fly, so that program logic is not affected.
To implement this, flash sectors containing breakpoints, are erased and rewritten on every added/removed breakpoint, which reduces the flash memory endurance.

So if you enable this option, you are limited to the number of hardware breakpoint registers, it is better to constantly add/remove breakpoints from the limited set, than degrade your flash memory.

Both emulator offers a way to configure this behavior. On the msp430-gdbproxy++ this is configured by one of the following command line options:

• --bpmode=hard
• --bpmode=soft
• --bpmode=auto

On the gdb_agent_console you have only two options, which should be adjusted on the board file:

• msp430_default_breakpoint=software
• msp430_default_breakpoint=hardware

File contents example:

# config version=3.5
$ msp430
  msp430_drvr=msp430.dll
  msp430_port=TIUSB
  msp430_default_breakpoint=hardware
$ /

It is not recommended to edit the original board file, supplied with the compiler. Make a copy of msp430.dat and customize the copy.

Sometimes configuring a JTAG emulator can be time consuming, specially if you are experimenting a new IDE. This feature can be of great help when you are having trouble.

The msp430-gdbproxy++ has an improved log contents with this option set.

Some MSP430 parts are able to use either JTAG interface or SBW. On the automatic mode JTAG has precedence over the SBW, since it is a significantly faster interface. Though, this happens at the cost of the use of more hardware pins. In the case these are shared with other hardware, it is better to force SBW instead of letting the interface try to use JTAG instead. Besides this, connection attempts should be faster when not specifying the automatic mode, which is only possible if you used the msp430-gdbproxy.

Another point of concern is the interface speed. The older MSP-FET430UIF and the Olimex have no support for this option, but the new MSP-FET speed can drastically improve using this option.

On the gdb_agent_console the fast option is automatically activated, but for the msp430-gdbproxy you will have to use the --ifacespeed=fast option to activate it.

The single point here is that interface speed decreases as a function of cable lengths and supply voltage. For example, on the chapter 5.30 of the SLAS272H – MSP430F149 datasheet you can read that the TCK input frequency is limited to 10 MHz if the power supply is 3V or above, but it will reduce to 5 MHz for a supply voltage of 2.2V.

It is not clear to me if the gdb_agent_console is able to compensate this setting depending on the supply voltage and there are no way provided on the JTAG interface to verify error rate. So this should be considered a point of concern if constraints apply to your setup.

for msp430-gdbproxy-- you have three different options to control speed:

• --ifacespeed=fast,
• --ifacespeed=medium or
• --ifacespeed=slow.

Currently, a serious problem happened with gdb_agent_console and Spy-bi-Wire connections: Running the UnitTest.exe with the test number 2 causes a hang. The link simply stops responding. The same does not happen when using JTAG mode or the msp430-gdbproxy++ agent.
The problem is consistent with MSP-FET and the FET drivers from the Launchpads.

This single point is a good reason to never use gdb_console_agent if you are using the SBW interface. What is really thoughtful here is that MSP430.dll, which is the same driver for all situations described here, serves to abstract the connection, regardless if it is JTAG, SBW, gdb_agent_console or msp430-gdbproxy++.

Another drawback of the gdb_agent_console that it is not compatible with the Olimex series of debug emulators, which is an extremely fast, low cost option.

Recently I saw on the Olimex website that this item is out of stock and also chip support never updated, which is a pity, since it has been always very reliable and fast.

The last point of this analysis is not so important, since mspgcc is really obsolete. In this environment GDB is only able to operate 16-bit registers and it will reject the GDB internal g command when register contents are reported using 32-bits, which is default for newer GDBs.

msp430-gdbproxy++ has an option to circumvent this issue.