Archive for August, 2010

Blog problems

Sunday, August 29th, 2010

yesterday I had the unpleasant experience of a dead hard-drive. Fortunately nothing important was lost, but when I tried to get a Makefile example from my blog I noticed that the code section on the blog actually erases sections like the import filenames, replaces some of the code from 0x to 0* and other problems.

Loading code onto target msp and debugging

Monday, August 16th, 2010

In the last post I finally compiled the blinked led example and created a makefile. Now we want to load program onto the target and let it run.

First you need to connect your EZ430 to your computer. It will start running the whatever was loaded last.

Then connect mspdebug to your ez430 with ‘mspdebug -d /dev/ttyUSB0‘. If this gives you an error you will need to find the correct device. You can see if the device is recognized by your system by watching your /var/log/message file when you connect the EX430 and via the lsusb command. Below is the output I get on my system for both commands.

$ lsusb
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 005: ID 0451:f430 Texas Instruments, Inc. MSP-FET430UIF JTAG Tool
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ tail -f /var/log/messages
Aug 15 22:26:56 linux-desktop kernel: [21806.152048] usb 4-1: new full speed USB device using ohci_hcd and address 4
Aug 15 22:26:56 linux-desktop kernel: [21806.337313] usb 4-1: configuration #1 chosen from 1 choice
Aug 15 22:26:56 linux-desktop kernel: [21806.341196] ti_usb_3410_5052 4-1:1.0: TI USB 3410 1 port adapter converter detected
Aug 15 22:26:56 linux-desktop kernel: [21806.341216] usb 4-1: firmware: requesting ti_usb-v0451-pf430.fw
Aug 15 22:26:56 linux-desktop kernel: [21806.345078] usb 4-1: firmware: requesting ti_3410.fw
Aug 15 22:26:56 linux-desktop kernel: [21807.028065] usb 4-1: reset full speed USB device using ohci_hcd and address 4
Aug 15 22:26:57 linux-desktop kernel: [21807.193080] usb 4-1: device firmware changed
Aug 15 22:26:57 linux-desktop kernel: [21807.193140] ti_usb_3410_5052: probe of 4-1:1.0 failed with error -5
Aug 15 22:26:57 linux-desktop kernel: [21807.193231] usb 4-1: USB disconnect, address 4
Aug 15 22:26:57 linux-desktop kernel: [21807.332049] usb 4-1: new full speed USB device using ohci_hcd and address 5
Aug 15 22:26:57 linux-desktop kernel: [21807.549300] usb 4-1: configuration #1 chosen from 2 choices
Aug 15 22:26:57 linux-desktop kernel: [21807.552564] ti_usb_3410_5052 4-1:1.0: TI USB 3410 1 port adapter converter detected
Aug 15 22:26:57 linux-desktop kernel: [21807.552604] ti_usb_3410_5052: probe of 4-1:1.0 failed with error -5
Aug 15 22:26:57 linux-desktop kernel: [21807.557526] ti_usb_3410_5052 4-1:2.0: TI USB 3410 1 port adapter converter detected
Aug 15 22:26:57 linux-desktop kernel: [21807.557729] usb 4-1: TI USB 3410 1 port adapter converter now attached to ttyUSB0
^C

If your system connects correctly you can load the code via ‘prog led.hex’ and use mspdebug as a gdb proxy via the ‘gdb’ command.

$ mspdebug -d /dev/ttyUSB0 uif
MSPDebug version 0.10 - debugging tool for MSP430 MCUs
Copyright (C) 2009, 2010 Daniel Beer
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open UIF on /dev/ttyUSB0…
Initializing FET…
FET protocol version is 10002000
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
Device: MSP430F20x3
Code memory starts at 0xf800
Number of breakpoints: 2

Available commands:
= dis hexout opt reset step
break erase isearch prog run sym
cgraph gdb md read set
delbreak help mw regs setbreak

Available options:
color gdb_loop

Type “help ” for more information.
Press Ctrl+D to quit.

(mspdebug) prog led.hex
Erasing…
Writing 104 bytes to f800…
Writing 32 bytes to ffe0…
(mspdebug) gdb
Bound to port 2000. Now waiting for connection…

Now you can call ddd via ‘ ddd –debugger msp430-gdb led.elf‘ which tells ddd to use the msp430-gdb debugger and we are debugging led.elf. To connect I typed ‘target remote :2000‘ in the command window followed by a ‘continue‘ and then pressing the interrupt command but. I also found out that it is best to remove all breakpoints in ddd before connecting the target and always first issue the continue command otherwise the connection would be lost. Now you can single step the code, visualize your data and iron out the last bugs.

Finally to stop the ddd session use the ‘disconnect‘ command.

DDD session screenshot

Compiling the first program

Thursday, August 12th, 2010

So now that we have mspgcc compiler and mspdebug tool installed we finally can write our own programs.

To start we create the blinking led example.

Here is the source code for main.c

/* Blink LED example */

#include 

/** Delay function. **/
delay(unsigned int d) {
  int i;
  for (i = 0; i<d; i++) {
    nop();
  }
}

int main(void) {
  WDTCTL = WDTPW | WDTHOLD;
  P1DIR = 0xFF;
  P1OUT = 0x01;

  for (;;) {
    P1OUT = ~P1OUT;
    delay(0x4fff);
  }
}

Now you can compile the program via:

msp430-gcc -Os -mmcu=msp430x2013 -o led.elf main.c

msp430-objdump -DS led.elf > led.lst

msp430-objcopy -o ihex led.elf > led.hex

The first command while compile the c source code into an executable in elf format. The second command will generate an assembler listing of your program. The third command will give a hexdump of the opcodes in Intel Hex Format. You can actually look at the led.lst and led.hex files they are human readable.

Now it would be cumbersome to actually do this every time manually. The better way is to create a make file and let make take of this.

Here is a example for the makefile:

# makefile configuration

NAME = led
OBJECTS = main.o
CPU = msp430x2013
CFLAGS = -mmcu=${CPU} -Os -Wall -g

#switch the compiler (for the internal make rules)
CC = msp430-gcc
.PHONY: all FORCE clean download dist

#all should be the first target. it's built when make is run without args
all: ${NAME}.elf ${NAME}.hex ${NAME}.lst

#additional rules for files
${NAME}.elf: ${OBJECTS}
  ${CC} -mmcu=${CPU} -o $@ ${OBJECTS}

${NAME}.hex: ${NAME}.elf
  msp430-objcopy -O ihex $^ $@

${NAME}.lst: ${NAME}.elf
  msp430-objdump -dSt $^ >$@

clean:
  rm -f ${NAME}.elf ${NAME}.hex ${NAME}.lst ${OBJECTS}

#backup archive
dist:
  tar czf dist.tgz *.c *.h *.txt makefile

#dummy target as dependecy if something has to be build everytime
FORCE:

#project dependencies
main.o: main.c

If you are coping the file make replace the indention spaces with a <tab> otherwise the file will not be correct ( sorry I could not figure out how blogilo would not convert them). As you can see this actually does a few more things than 3 commands before. First how to use this makefile:

You can build all via ‘make‘ or ‘make all‘ since ‘all’ is the first rule defined it will be the default.

The first lines NAME defines the common part of all the files to create (here led.*). The OBJECT variable lists all object files. The CPU sets the target cpu type and CFLAGS sets all the compiler options. CC tells make what compile it should use. All the following lines starting at position 0 define a build rule (e.g. all/clean). The names listed after the ‘:’ define the dependencies for the rule which also need to be called. If the build rule has some idented lines (need to start with a <tab>) it defines the command this rule executes, e.g. the clean rule executes the rm command.

Next step is to load the program on the target and debug the code.