Daniel Beer Atom | RSS | About

Frequently asked questions

• My chip isn’t supported. What can I do about it?
• How do I use USB devices in Linux without running as root?
• How do I get an RF2500/Launchpad working on OS/X?
• How can I use the CDC/ACM port on OS/X?
• How do I get an Olimex MSP430-JTAG-TINY working on Linux?
• How can I upgrade the firmware on my FET430UIF?
• How do I use MSPDebug to debug from within Eclipse?
• What does “message C_IDENT3 failed” mean?
• How can I get Linux to recognise an Olimex MSP430-JTAG-ISO?
• How can I compile MSPDebug on Windows?
• How can I use the TI Launchpad with MSPDebug on Windows?
• How can I revive my FRAM experimenter’s board (“Security fuse blown”)?

My chip isn’t supported. What can I do about it?

If you’re looking for a quick-fix, you can often get an unrecognised chip working by selecting the configuration of a similar chip. Use the --fet-list option to get a list of supported chips and then pass the name of a similar one using --fet-force-id when you try to connect to the debugger. Be aware that the chip may not work 100% reliably if you do this. In particular, you should pick a configuration for a chip with less RAM that what you have, if possible (the flasher won’t work properly if it tries to use RAM which isn’t there).

If you encounter a situation like this, it would be helpful if you could send details about your chip so that it can be supported in the future. Useful information to include in your message would be:

• The name of the chip you’re using.
• The name of a similar chip configuration which works (if known).
• The identification data, which you can get by passing the command-line option --fet-force-id foo, where foo is anything which isn’t a valid chip name.

Even better would be to capture the USB packets from a session using one of the proprietary tools which does support your chip. You only need to connect to the chip and do something basic like single-stepping or running in order to capture enough information. You can use a tool like sniffusb 2.0 to capture this data.

How do I use USB devices in Linux without running as root?

If you aren’t running the program as root, you might not have permission to use the USB bus. You can fix this by adding a udev rule such as the following:

ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", MODE="0660", GROUP="plugdev"

Add yourself to the plugdev group, and you should be able to access the device without being root. Alternatively, if you are running an older kernel which still supports usbfs, you can remount it:

umount /proc/bus/usb
mount -t usbfs none /proc/bus/usb -o devmode=0664,devgid=<em>usb-gid</em>

Replace usb-gid with the GID of a group that should have permission to use the bus.

How do I get an RF2500/Launchpad working on OS/X?

Note: these instructions are quite old, and will not work with modern versions of OS/X. You should use a recent (git) version of mspdebug, which uses hidapi to communicate instead of libusb.

You may have trouble getting RF2500-like devices (such as the TI Launchpad) running under OS/X, due to interference from HID drivers. To overcome this problem, you need to install a codeless kext. The instructions that follow are from Bill Westfield (westfw):

1. Download ex430rf2500-kext.zip and unpack it.

2. Copy ez430rf2500.kext extension into /System/Library/Extensions folder:

   cd ex430rf2500-kext/build/Debug
   sudo cp -R ez430rf2500.kext /System/Library/Extensions
   sudo touch /System/Library/Extensions

   This is a “codeless” extension; all it does it contain “match” information that prevents the normal HID drivers from grabbing the ez430 dongle. The serial port on the dongle won’t work.

3. Set kext owner to root - it is kext system specification - without it, kext is not recognized by system:

   sudo chown -R root:wheel /System/Library/Extensions/ez430rf2500.kext

4. Set kext privileges to 755 - it is kext system specification - without it, kext is not recognized by system:

   sudo chmod -R 755 /System/Library/Extensions/ez430rf2500.kext

5. Rebuild internal system kext cache (on Mac OS X 10.4 only):

   kextcache -e

6. Reboot computer.

For OS/X version 10.7 (Lion), two versions of an updated kext have been provided:

• https://github.com/colossaldynamics/ez430rf2500 - Bert JW Regeer
• https://github.com/csammis/csammis-MSP430 - Chris Sammis

How can I use the CDC/ACM port on OS/X?

Terence Ang has written a driver for this, which is available from http://www.mediafire.com/?7zurj5ncg579. Discussion relating to this driver is on the 43oh forum at http://www.43oh.com/forum/viewtopic.php?f=7&t=1591.

How do I get an Olimex MSP430-JTAG-TINY working on Linux?

MSPDebug supports using the Olimex MSP430-JTAG-TINY directly via USB. However, it’s also possible to use the device via a Linux tty driver. You need to enable support for cp210x-based serial converters, and apply this patch.

How can I upgrade the firmware on my FET430UIF?

Since version 0.11, it’s possible to use the FET430UIF bootloader to erase and reprogram the firmware.

WARNING: if you lose power, or programming fails, you might render your FET unusable. The FET can, however, be recovered if you have a second JTAG tool available (the FET itself is MSP430-based).

Assuming you have a firmware image called new_firmware.hex, you can flash your FET with a command such as:

mspdebug -d /dev/ttyUSB0 uif-bsl 'prog new_firmware.hex'

Replace /dev/ttyUSB0 with whatever TTY device is connected to the FET.

How do I use MSPDebug to debug from within Eclipse?

Updated instructions, from Andrew McLaren:

• For simplicity, Eclipse is released annually as a simultaneous release, which includes consistent versions of all the requisite components for a given application, in our case C/C++. As at late 2013, the latest simultaneous release is Kepler (4.3), which is what this is based on. Go to [http://www.eclipse.org/downloads], and look for the Eclipse IDE for C/C++ Developers.

• The pse installation is simply a matter of extracting the kit (C/CPP IDE) to a suitable location. Eclipse will also need a Java JRE to run.

• Eclipse needs specific support to integrate the GDB hardware debugger. Earlier this was provided by ZylinCDT, but now there is a native Eclipse addon for this. As at late 2013, there was no specific support for the Kepler release, but the addon from the 4.2 Juno release of Eclipse works fine. From Eclipse, select “Windows -> Preferences -> Install/Update -> Available Software Sites”, ensure site [http://download.eclipse.org/tools/cdt/releases/juno] is listed, and add if not.

• Under “Help -> Install New Software”, select this site entry. Under “CDT Optional Features”, select and install “GDB Hardware Debugging”.

• The link between the Eclipse debugger and MSPDebug is get up in the Debugger panes of the individual debug configurations (Run -> Debug Configurations). These are configured by adding a new debug configuration and following the bouncing ball. The critical bits are under the Debugger pane, specifically;

  • The GDB Command needs to point to your msp430-gdb
  • Use remote target
  • The JTAG device is Generic TCP/IP
  • Host name is where the JTAG is connected, probably localhost
  • Port number is the port MSPDebug is listening on.

• The only other requirements should be the initialization commands for the JTAG, which are defined under the Startup pane. There are a myriad of options, both for GDB itself, and to be passed through to MSPDebug. A reasonable starting point is:

  set remoteaddresssize 64
  set remotetimeout 999999
  monitor erase all
  load <target_elf_file>

• Start MSPDebug, set it listening on the allocated port, and activate the debug configuration in Eclipse. The elf file should be loaded to the target MSP and the Eclipse debugger activated.

What does “message C_IDENT3 failed” mean?

With some device/chip combinations, you’ll see the following messages during connection, before getting the MSPDebug prompt:

fet: FET returned error code 34 (Not supported by selected Interface)
fet: warning: message C_IDENT3 failed

The C_IDENT3 message contains additional chip information required by some debuggers. If you see this message, it simply means that your debugger doesn’t require the information. It’s not a fatal error.

How can I get Linux to recognise an Olimex MSP430-JTAG-ISO? MSPDebug supports the MSP430-JTAG-ISO, but only via a TTY driver (FTDI). To have the device recognized, you need to load the FTDI driver with special arguments:

sudo modprobe ftdi_sio vendor=0x15ba product=0x0008

After which, you should be able to connect to the device using:

./mspdebug -j -d /dev/ttyUSB0 olimex-iso

How can I compile MSPDebug on Windows?

MSPDebug compiles under Cygwin, and supports Win32 natively using MinGW. To get raw USB access working (required for some debug drivers), you’ll need to use libusb-win32.

More detailed instructions for MinGW, supplied by Wayne Uroda:

• Download MinGW installer
  Install to C:\mingw - install the ‘C Compiler’, ‘MSYS Basic System’ and ‘MinGW Developer Toolkit’.

• Download regex-2.7-bin.zip
  Open the archive - extract the files from the lib directory to c:\mingw\lib, extract files from include directory to c:\mingw\include.

• Download libusb-win32
  Extract lusb0_usb.h to c:\mingw\include, rename to usb.h
  Extract lib/gcc/libusb.a to c:\mingw\lib

• Download readline-5.0-1-bin.zip
  Extract the readline directory from include to c:\mingw\include\readline\
  Extract the files from the lib subdirectory to c:\mingw\lib

• Download the MSPDebug source code, open a command window, change directory to the MSPDebug sourcecode.

  set path=c:\mingw\bin;c:\MinGW\msys\1.0\bin\
  make

• You will need to gather the DLL files, found in the bin subdirectory of each of the three downloaded libraries (regex, libusb and readline), and put them in the same directory as mspdebug.exe.

How can I use the TI Launchpad with MSPDebug on Windows?

A driver has been provided by Patrick Dussud. The included README gives the following instructions:

Device Driver Installation

This driver is meant for the launchpad board. Make sure you don’t have the TI USB drivers installed. To install, refer to http://sourceforge.net/apps/trac/libusb-win32/wiki: Device Driver Installation section

Here is a simplified version of it. In case of problems, refer to the resource above:

1. Log in as a user with administrator privileges.

2. Follow the instructions in the above web page to download and extract the latest device driver binary package (libusb-win32-bin-x.x.x.x.zip). Place the .inf file in the same temporary directory Plug the Launchpad and let Windows install the drivers for it. There may be a missing driver for MSP430 Application UART but it isn’t necessary for mspdebug to work.

3. Goto to the device manager under Human Interface Devices and locate the USB Input Device which Hardware ID looks like this: USB\VID_0451&PID_F432&REV_0100&MI_01 (look at properties, details, Hardware Ids). Once you have located the device, click right and select “Update Drivers”, choose let me pick from a list of device drivers, then “have disk” and select the .inf file in bin directory of the temporary location.

4. Windows will warn that the driver is is not ‘digitally signed’. Ignore this message and continue with the installation. Since version 1.2.0.0, a valid digital signature is embedded inside libusb0.sys for AMD/Intel x86_64 version of Windows so that the users can install the driver as well under 64bit x86_64 version of Windows Vista/7/2008/2008R2. Please read more about the Microsoft Kernel Mode Code Signing (KMCS) policy for more information.

5. Open the Windows Device Manager to verify that the device is installed correctly. Run the test program (testlibusb-win.exe) from the ‘bin directory’. It should print out the descriptors of your device(s).

A reboot isn’t necessary.

How can I revive my FRAM experimenter’s board (“Security fuse blown”)?

Sometimes, an FRAM experimenter’s board may stop working via JTAG, reporting that the JTAG security fuse is blown. This is fixable by performing a mass erase via the flash BSL. You can do this via MSPDebug if you have a serial device set up to control the TEST/RST lines via the modem control signals:

mspdebug flash-bsl -d /dev/ttyUSB0

MSPDebug will perform a mass-erase on connect, so just press Ctrl+D after connecting. Alternatively, if you don’t have the necessary tools for BSL access, Don Bindner has provided a program that you can run on another MSP430 (currently targeting the MSP430G2211, but should be reasonably portable). This program uses GPIO lines and the MSP430 UART to access the BSL on the FRAM board and perform a mass erase. Don’s program, and associated documentation, is available here:

• http://dbindner.freeshell.org/msp430/fram_bsl.html