Daniel Beer Atom | RSS | About

Frequently asked questions

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:

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:

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:

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:

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: