msp4linux Home
C++ based debug interface to MSP430, MSP-FET430UIF needed
Status: Alpha
Brought to you by:
mspforlinux
Home
Msp4Linux
This package includes a tool chain for MSP430 micro controllers. The tool chain is based on the MSP430-FET430UIF Jtag programming hardware and the TI(TM) open source driver which is needed to access the UIF on the PC side.
Beside the hardware tool chain, there is a second part which provides a virtual tool chain. The open source driver is patched and a new data channel is added, which redirects the USB output to a socket interface. The virtual tool chain itself consists of an implementation of the PC to UIF transfer protocol and a public interface for a simulated target.
Open Source driver
The version 3 open source driver replaces the former version 2 series which was only available closed source and only for the Windows(TM) operating system family. The version 3 series has official Linux support from TI(TM). The package name is slac460X.zip, where X stands for version number. The current version is slac460e.zip which points to the build number 3.2.5.4.
There is a project file for Windows(TM) and an additional Makefile for Linux. The Makefile with the typical compile and link step will create the driver file itself with the file name libmsp430.so
Additional information can be found here:
http://processors.wiki.ti.com/index.php/MSP_Debug_Stack
Section with the download link:
http://processors.wiki.ti.com/index.php/MSPDS_Open_Source_Package#Download
Frontend - virtual UIF - Backend
Msp4Linux provides an open architecture and various simulators may be connected to various debugging tools. The basic idea is to separate front and backend with the UIF in the middle. Besides the MSP430-FET430UIF hardware tool, which can still be used, there is an alternative in software. It implements the communication protocol between PC and UIF and replaces the USB/CDC layer with a socket.
There is an patch included which adds the socket channel to the v3 driver.
Installation:
Prerequisites:
- gcc/g++/make
- cmake
- boost_dev
- Editline Library (libedit)
Get the file slac460e.zip from http://processors.wiki.ti.com/index.php/MSP_Debug_Stack Copy the files slac460e.zip and msp430_add_alpha_0.7.2.tar.bz2 to the work directory and extract both archives in the same directory and change into MSP430.DLLv3_OS_Package.
Check the package version:
sh ./test_version.sh ../slac460e.zip
MSP430.DLLv3_OS_Package/DLL430_v3/version.h:#define VERSION_MAJOR 3
MSP430.DLLv3_OS_Package/DLL430_v3/version.h:#define VERSION_MINOR 2
MSP430.DLLv3_OS_Package/DLL430_v3/version.h:#define VERSION_PATCH 5
MSP430.DLLv3_OS_Package/DLL430_v3/version.h:#define VERSION_BUILD 4
Check for new versions of msp430add package if the version number differs.
Install the patch (adds string.h includes)
patch -p1 < slac460e.patch
Optonal additional patch for virtual fet mode:
patch -p1 < socket_channel_e.patch
(see virtual fet section below for details)
note: The original Makefile was changed in two aspects. The boost library include was changed from static to dynamic (.a to .so) and the library destination was changed to a local directory. The original Makefile does still exist and is not overwritten during installation. This installation adds a new Makefile with the name Makefile.dyn
Compile flags:
-DUNIX: UNIX/Linux compatible replacements for Windows(TM) specific code
-DNDEBUG: disable debug messages This flag is active by default und must be disabled if debug output is needed. Beside some messages on stdout, there is a communication trace file created: 'comm.log'
-DFET_SIM: Virtual FET mode This flag activates the virtual FET mode (see section below for details) and is disabled by default.
This are the build instructions:
enter the workdirectory (if not already there):
(install dir)/MSP430.DLLv3_OS_Package
create the libMSP430.so:
make -f Makefile.dyn
this will copy it to the subdirectory with the cli-tool:
make -f Makefile.dyn install
This is needed to create the target database. The first step is to create the tool which extracts the data and writes them to source files.
cd ./target_db/tool/
cmake .
make
The created tool must be executed to get the files needed for the library.
./dbutil
The second step is to create the library which contains the database:
cd ../lib
cmake .
make
make install
The next step is to create the library which contains
the simulator. It is needed for the disassembler:
cd ../../simulator
cmake .
make
make install
Now as all libraries are in place, the main application can be built:
cd ../mspdb_v3/
make
extend the path to start the libMSP430.so from this directory:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../lib
You can now start the debugging tool:
./mspdb_v3_ti
By default the debugging tool will start in AUTO mode and the driver will select the jtag mode automatically. If this is not working, please try one of these options:
| JTAG type | command |
|---|---|
| 5xx 4 wire jtag | ./mspdb_v3_ti -J 4AFTER2 |
| 1xx/2xx/4xx 4 wire jtag | ./mspdb_v3_ti -J 4WIRE |
| 2 wire, all types | ./mspdb_v3_ti -J SPYBIWIRE |
You will need a MSP-FET430UIF to use the package and it has to be updated to a v3 firmware version. The Windows binary installation provides tools to change the firmware version from v2 to v3 and backwards. To do this directly unter Linux, please refer to: http://mspdebug.sourceforge.net/tilib.html
The cli tool provides an internal update functionality but this works only if there is already a version 3 firmware installed. If the minor version differs the tool will ask for the update automatically. If you want to change from version 2 to version 3 or back, please refer the TI-website (again http://processors.wiki.ti.com/index.php/MSP_Debug_Stack) for details.
Virtual FET Simulation driver
The virtual debug toolchain consists of a module which implements the FET communication protocol and acts like a FET, but runs on the PC side and a msp430 simulator as the second part.
While the protocol implementation is rather stable, the simulator currently implements only a subset of the msp430 instructions and addressing modes (more to come).
The idea is to redirect the v3 Driver output from USB to a socket connection. A patch for the driver is needed to add the alternative output. The patch will not change the driver but add some code blocks which have to be activated by a compile flag (UIF_SIM). If the patch is not already installed, please do this now:
patch -p1 < socket_channel_d.patch
If already built without the patch, the ms430.so library must be rebuilt after this step.
Now the server for the virtual FET can be created It is located in the virtual_fet subfolder:
cd ../virtual_fet
make
Start a session:
./virtual_fet -P 33333 -T <target name>
Typical output of the server while simulating a MSP430F5438A target:
...MSP430.DLLv3_OS_Package/virtual_fet> ./virtual_fet -P 33333 -T MSP430F5438A
target [MSP430F5438A]
SimServer: accept connections at port 33333
MemorySection::MemorySection identification, size 100, base 1a00
MemorySection::MemorySection main, size 40000, base 5c00
MemorySection::MemorySection information, size 200, base 1800
MemorySection::MemorySection system, size 4000, base 1c00
MemorySection::MemorySection peripheral16bit, size 1000, base 0
RegisterEem::RegisterEem 0 128
The virtual FET will now wait for a connection. If no real FET is connected, the virtual FET will connect as default. If there are real FET, the virtual FET will act as the last listed FET in the list:
.../MSP430.DLLv3_OS_Package/mspdb_v3> ./mspdb_v3_ti
Using JTAG mode AUTO
Scanning USB for FET... number of connected FET: 1
No 1 simulator 0
Using FET connected to simulator
Initializing FET
FET protocol version is 30205004
LIB protocol version is 30205004
Set Vcc: 3000 mV
VCC in[mV]: 3000
VCC out[mV]: 3000
VCC out[mV]: 3000
num of devices 1
JtagID: 91
version ID (0x91): 8005
Device: MSP430F5438A
Code memory starts at 0x5c00
Number of breakpoints: 8
If this point is reached, the target is identified and ready to use.
mspdb_v3$ regs
PC: 0aaaa) ( R4: cccc4) ( R8: cccc8) (R12: ccccc)
SP: cccc1) ( R5: cccc5) ( R9: cccc9) (R13: ccccd)
SR: 00000) ( R6: cccc6) (R10: cccca) (R14: cccce)
R3: 00000) ( R7: cccc7) (R11: ccccb) (R15: ccccf)
This is the initial output of the CPU register view. The values for the register R4 to R15 are created by the simulator to avoid random initialisation. SR and R3 are set to 0 as they are in real hardware. The PC is set to the value in the vector table by the reset function.
Like most of the registers, the main memory of the msp430 is in random state after initialisation. The simulator resets it to 0xaaaa to make it visible that no image is loaded an no erase happened. As the reset vector is part of the main memory, the PC is initialized to 0xaaaa too.
mspdb_v3$ load ../test/blink.txt erase
erasing
load: ../test/blink.txt
../test/blink.txt loaded to target
In this section there is an image loaded to the main memory. On real hardware, the erase parameter is used to erase the flash (or a corresponding main memory type). If used with the simulator, the main section is filled with 0x0ffff instead of 0x0aaaa. In this example, the reset vector (0xfffe) is set to 0x05c00, so the execution starts here.
mspdb_v3$ regs
PC: 05c00) ( R4: cccc4) ( R8: cccc8) (R12: ccccc)
SP: cccc1) ( R5: cccc5) ( R9: cccc9) (R13: ccccd)
SR: 00000) ( R6: cccc6) (R10: cccca) (R14: cccce)
R3: 00000) ( R7: cccc7) (R11: ccccb) (R15: ccccf)
mspdb_v3$ step
PC: 05c04) ( R4: cccc4) ( R8: cccc8) (R12: ccccc)
SP: 05c00) ( R5: cccc5) ( R9: cccc9) (R13: ccccd)
SR: 00000) ( R6: cccc6) (R10: cccca) (R14: cccce)
R3: 00000) ( R7: cccc7) (R11: ccccb) (R15: ccccf)
CALLA #0x5cac ; 13b0 5cac 930c
mspdb_v3$
...
If mspdebug is used as front end, register output and single step will look like this:
(mspdebug) regs
( PC: 0aaaa) ( R4: cccc4) ( R8: cccc8) (R12: ccccc)
( SP: cccc1) ( R5: cccc5) ( R9: cccc9) (R13: ccccd)
( SR: 00000) ( R6: cccc6) (R10: cccca) (R14: cccce)
( R3: 00000) ( R7: cccc7) (R11: ccccb) (R15: ccccf)
0xaaaa:
0aaaa: aa aa aa aa DADD @R10, 0xaaaa(R10)
0aaae: aa aa aa aa DADD @R10, 0xaaaa(R10)
0aab2: aa aa aa aa DADD @R10, 0xaaaa(R10)
0aab6: aa aa aa aa DADD @R10, 0xaaaa(R10)
(mspdebug)prog blink.txt
Erasing...
Programming...
Writing 180 bytes to 5c00...
Writing 2 bytes to fffe...
Done, 182 bytes written
(mspdebug) step
( PC: 05c04) ( R4: cccc4) ( R8: cccc8) (R12: ccccc)
( SP: 05c00) ( R5: cccc5) ( R9: cccc9) (R13: ccccd)
( SR: 00000) ( R6: cccc6) (R10: cccca) (R14: cccce)
( R3: 00000) ( R7: cccc7) (R11: ccccb) (R15: ccccf)
0x5c04:
05c04: b0 13 ac 5c CALLA #0x5cac
05c08: 0c 93 TST R12
05c0a: 02 24 JZ 0x5c10
05c0c: b0 13 1a 5c CALLA #0x5c1a
05c10: 0c 43 CLR R12
05c12: b0 13
(mspdebug)
...
Important: The model included in this package is not fully functional. It supports the identification process of 5xx targets and read out of registers and memory. The instruction model supports a small subset of instructions, stack handling, some of the addressing modes. Just enough to demonstrate single stepping with a simple blink.txt binary (example in the test folder)
New features of this version:
- instruction model extended
- MOVA and CALLA implementation
- changed erase default of load command
Known Problems:
- Socket mode port is hardcoded to 33333
- more rework of interactive mode needed
- Simplification of build needed (use features of cmake)
This is the default page, edit it as you see fit. To add a page simply reference it within brackets, e.g.: [SamplePage].
The wiki uses Markdown syntax.
