Home

Msp4linux wiki

MSP430-FET430UIF CDC protocol

The communication between driver and UIF is realized by a simple telegram based protocol. The driver acts as the master and the UIF as slave. User activities like reading registers are given to the driver by the API and the driver gather the information with a small communication session.

The following telegram sequences are recorded by the FET virtualisation using a simulated MSP430F5438A target and verbose mode (-V or --verbose)

./virtual_fet -P 33333 -T MSP430F5438A -V

Here is a typical telegram which represents an acknowledge and this is the shortest telegram possible:

(03)(91)(04)(00)(f8)(6e)

The bytes of the telegram are shown in the table below:

type	range	example	description
length	0x03 - 0xff	0x03	length of following data bytes (without crc)
function	UP_INIT - TYPE_STATUS	0x91	predefined definitions
session	0x00 - 0x3f	0x04	session code
reserved	0x00	0x00	not used
crc	--	0xf8	crc 16 bit, first byte
crc	--	0x6e	crc 16 bit, second byte

Detailed description:

length: This is the length of the telegram without the crc and the byte field itself.

function: Functionality of the telegram, the predefined codes are shown in the next section but only a few of them seem to be used.

type	value	description
UP_INIT	0x51	UpInit
UP_ERASE	0x52	UpErase
UP_WRITE	0x53	UpWrite
UP_READ	0x54	UpRead
UP_CORE	0x55	UpCore
LEGACY	0x7E	CmdLegacy
SYNC	0x80	CmdSync
EXECUTE	0x81	CmdExecute
EXECUTE_LOOP	0x82	CmdExecuteLoop
LOAD	0x83	CmdLoad
LOAD_CONT	0x84	CmdLoadContinued
DATA	0x85	CmdData
KILL	0x86	CmdKill
MOVE	0x87	CmdMove
UNLOAD	0x88	CmdUnload
BYPASS	0x89	CmdBypass
EXECUTE_LOOP_CONT	0x8A	CmdExecuteLoopCont
COM_RESET	0x8B	CmdComReset
PAUSE_LOOP	0x8C	CmdPauseLoop
RESUME_LOOP	0x8D	CmdResumeLoop
TYPE_ACK	0x91	Type_Acknoledge
EXCEPTION	0x92	Type_Exception
DATA	0x93	Type_Data
DATA_REQEST	0x94	Type_DataRequest
TYPE_STATUS	0x95	Type_Status

session: The session byte is a dynamically assigned value and it is given to any telegram which belong to a communication session. A communication session could be a simple command with return and acknowledge or a more complex set of telegrams if the data to transfer exceeds the size limit of a single telegram.

Initial telegram with session number 5 from driver
in: 10 | (07)(81)(05)(00)(02)(00)(b8)(0b)(47)(75)
HalMacroSetVcc: power up target: 3000 [mV]

UIF responds with empty data telegram
out: 6 | [03][93][05][00][f9][6c]

Driver closes the session with acknowledge...
in: 6 | (03)(91)(05)(00)(f9)(6e)

...and starts a new session with session number 6
in: 8 | (05)(81)(06)(00)(03)(00)(ff)(7e)

The behaviour of master and slave is different. The driver as the master is the only instance which creates new session values. If the driver sends bigger data packages to the slave, any single package has its own session number. On the other hand, if the slave has to send in multi telegram mode, it keeps the session code which was transferred by the initial request and writes it to the telegram until the complete data is transferred.

The normal session code starts with 1 and increases the value until 0x3f is reached than it starts at 1 again. The value '0' is reserved for out of order actions like communication reset or error states.

Core and HAL

The next level of the protocol stack is the HAL layer. The HAL layer represents a common structure with a function code and a unified input or output parameter area. It depends on the function code whether a HAL section is included.

Example of a HAL telegram

(07)(81)(05)(00)(02)(00)(b8)(0b)(47)(75)

type	example	description
length	0x07	length of following data bytes (without crc)
function	0x81	CmdExecute
session	0x05	session code
reserved	0x00	not used
HAL id	0x00	HAL low byte
HAL id	0x02	HAL high byte
data	0xb8, 0x0b	parameters (voltage, 3000mV)
crc	0x47	crc 16 bit, first byte
crc	0x75	crc 16 bit, second byte

Initial sequence:

Type 0 request,
the firmware returns the identification code(firmware version number):

in:   10 | (06)(81)(01)(00)(00)(00)(00)(00)(f8)(7e)
out:  26 | [17][93][01][00][04][82][05][00][55][ff][40]...[01][07][00][00][00][fa][11]
in:    6 | (03)(91)(01)(00)(fd)(6e)

Type 1 request,
the firmware sends the table size of the HAL function table:

in:   10 | (06)(81)(02)(00)(00)(00)(01)(00)(fa)(7e)
out:   8 | [05][93][02][00][52][00][aa][6c]
in:    6 | (03)(91)(02)(00)(fe)(6e)

Type 2 request,
the firmware sends the table to the driver:

in:   12 | (08)(81)(03)(00)(00)(00)(02)(52)(00)(00)(f6)(2c)
out: 258 | [ff][93][83][01][00][00][00][00][01][00][01][00][02][00][02][00][03]...

Using Msp4linux with CCS

CCS can be used as an IDE front end for Msp4linux.

Using Msp4linux with mspdebug

Recently mspdebug was extended to support the open source driver. In order to start mspdebug with the virtual tool chain, the tilib driver must be selected. The following 'simulator' tag redirects the output to the virtual tool chain and must be used instead the /dev/tty... USB selector to invoke the simulator:

mspdebug-0.19> ./mspdebug tilib -d simulator
MSPDebug version 0.19 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 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.

MSP430_Initialize: simulator
Firmware version is 30204005
MSP430_VCC: 3000 mV
VCC  in\[mV\]: 3000
VCC out\[mV]\: 3000
VCC out\[mV\]: 3000
MSP430_OpenDevice
num of devices 1
JtagID: 91
version ID (0x91): 8005
MSP430_GetFoundDevice
Device: MSP430F5438A (id = 0x009f)
8 breakpoints available
MSP430_EEM_Init
...

Supported mspdebug commands:

• identify and initialize target (only 5xx)
• read registers
• read/write to registers (CPU)
• erase and program flash
• program the target (prog or load)
• single step

Free run, running to breakpoint or stopping the target are not implemented in the current version of the simulator.

The current simulator supports just a few addressing modes and instructions, more to come within one of the next versions.

The wiki uses Markdown syntax.