Forums

7043.msp430.tar.gz

Thanks, this was very helpful.  For my Fedora 16 64-bit machine, I made a couple changes in addition to applying your patch:

* Eliminate the reference to a local boost installation; the stock RPM version works fine

* Eliminate the static references to libboost files; the dynamic ones work (while the RPM static ones did not)

* Change libboost_thread to libboost_thread-mt

* Add -Wl,-rpath,/usr/local/lib/mspdebug in mspdebug's Makefile so I could put libmsp430.so there and not have to mess with LD_LIBRARY_PATH.

mspdebug seems to work fine with this, and is much much faster at programming a CC430F5137 through JTAG than the old mspdebug uif with firmware 2.4.5.3 was.

The command 'mspdebug tilib -d /dev/ttyACM0' doesn't start my - on the MSP-EXP430F5438 Experimenter Board - loaded program. Why? Is there something wrong about my vector table or associated code? Below you find my source code. Before mspdebug I have used these two Linux commands on my Ubuntu (1204) PC :

1. ~/workspace_book$ msp430-as -o led_091612.o -mmsp430x5438 led_091612.asm.

2. 2.msp430-ld -o led_091612.elf -T lnk_msp430f5438a.cmd led_091612.o.

This is the Assembly code content for the the source file 'led_091612.asm':

#include <msp430.h>

#include "msp430x54x.h"

.global _main

; Constants/registers

.set WDTCTL, 0x015C ; watchdog control port

.set WDTPW, 0x5A00 ; ?watchdog power

.set WDTHOLD, 0x0080 ; ?watchdog hold

.set P1DIR, 0x0204 ; Base Address+Offset:0x200+0x004, direction of data bits on port P1

.set P1SEL, 0x020A ; Base Address+Offset:0x200+0x0A

.set P1OUT, 0x0202 ; Base Address+Offset:0x200+0x002

.set P1REN, 0x0206 ; Base Address+Offset:0x200+0x006

.set P1IN, 0x0200

.set P2DIR, 0x0205 ; Base Address+Offset:0x200+0x0x005, direction of data bits on port P2

.set P2SEL, 0x020B ; Base Address+Offset:0x200+0x00B

.set P2OUT, 0x0203 ; Base Address+Offset:0x200+0x003

.set P2REN, 0x0207 ; Base Address+Offset:0x200+0x007

.set P2IN, 0x0201 ; Base Address+Offset:0x200+0x001

.set BIT0, 0b00000001 ; LED1 P1.0

.set BIT1, 0b00000010 ; LED2 P1.1

.set SW1, 0b01000000 ; SWITCH1 P2.6

.set SW2, 0b10000000 ; SWITCH2 P2.7

.set SW12, 0b11000000 ; SWITCH P2.6+P2.7

.set TA0CCR1, 0x0354 ; Base Address+Offset:0x0340+0x014

.set TA0CCR0, 0x0352 ; Base Address+Offset:0x0340+0x012

;Addresses not yet checked.

;.set TACTL, 0x0160 ; Timer A is 0x0160 to 0x017F

;.set TACCTL1, 0x0164 ; Capture/compare control register

;.set DCOCTL, 0x056 ; DCO control register

;.set BCSCTL1, 0x058 ; Oscillator control registITer #2

; Settings for Basic Clock Module

;.set RSEL0, 0x01 ; These bits select the frequency

;.set RSEL1, 0x02 ; range of the DCO

;.set RSEL2, 0x04

;.set DCO0, 0x20 ; These bits set the fundamental frequency

;.set DCO1, 0x40 ; of the DCO, within the range defined by the

;.set DCO2, 0x80 ; RSEL bits above.

.section .text

RESET: mov.w #0x5c00,R1 ;(0x05bff) Initialize stackpointer - End of RAM

StopWDT: mov.w #WDTPW+WDTHOLD,&WDTCTL ; Stop WDT

SetupP1: bis.b #BIT0,&P1DIR ; P1.0 output

;

Mainloop: xor.b #BIT0,&P1OUT ; Toggle P1.0

; Wait ~1s - 1000000 cycles

Wait: mov.w #050000,R15 ; Delay to R15

L1: mov.w #20, R14

L2: dec.w R14

jnz L2

dec.w R15 ; Decrement R15

jnz L1 ; Delay over?

jmp Mainloop ; Again

no_int: reti

;Interrupt vector

.sect "reset";MSP430 RESET Vector

.short RESET

;--------------------------------------------------------------------

; Interrupt Vectors Used

;--------------------------------------------------------------------

.section .vectors, "ax", @progbits;for ELF version

;Adresse wird einfach angegeben

.word no_int ; 0xFFE0

.word no_int ; 0xFFE2

.word no_int ; 0xFFE4

.word no_int ; 0xFFE6

.word no_int ; 0xFFE8

.word no_int ; 0xFFEa

.word no_int ; 0xFFEc

.word no_int ; 0xFFEe

.word no_int ; 0xFFF0

.word no_int ; 0xFFF2

.word no_int ; 0xFFF4

.word no_int ; 0xFFF6

.word no_int ; 0xFFF8

.word no_int ; 0xFFFA

.word no_int ; 0xFFFC

.word RESET ; 0xFFFE (Reset)

.end

;********************************************

Below follows the messages during the debugging/loading procedure:

:~/workspace_book$ mspdebug tilib -d /dev/ttyACM0

MSPDebug version 0.20 - 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: /dev/ttyACM0

Firmware version is 30204005

MSP430_VCC: 3000 mV

MSP430_OpenDevice

MSP430_GetFoundDevice

Device: MSP430F5438A (id = 0x009f)

8 breakpoints available

MSP430_EEM_Init

Chip ID data: 05 80 15

Available commands:

= erase isearch prog setbreak sym

alias exit load read setwatch verify

break fill locka regs setwatch_r

cgraph gdb md reset setwatch_w

delbreak help mw run simio

dis hexout opt set step

Available options:

color gdb_loop iradix

fet_block_size gdbc_xfer_size quiet

Type "help <topic>" for more information.

Press Ctrl+D to quit.

(mspdebug) prog led_091612.elf

Erasing...

Programming...

Writing 32 bytes at ff80 [section: .vectors]...

Writing 38 bytes at 5c00 [section: .text]...

Done, 70 bytes total

(mspdebug) run

Running. Press Ctrl+C to interrupt...

^C

( PC: 01cfe) ( R4: fffff) ( R8: fffff) (R12: 00000)

( SP: 01cfa) ( R5: 04f92) ( R9: 04f92) (R13: 00002)

( SR: 000f0) ( R6: 04f92) (R10: fffff) (R14: 00182)

( R3: 00000) ( R7: fffff) (R11: fffff) (R15: 01001)

0x1cfe:

01cfe: 00 10 RRC PC

01d00: 9f ef 7f d5 d6 fd XOR 0xd57f(R15), 0xfdd6(R15)

01d06: e7 ef ca 69 XOR.B @R15, 0x69ca(R7)

01d0a: ff 73 9e bf SUBC.B #0x00ff, 0xbf9e(R15)

(mspdebug)

MSP430_Run

MSP430_Close

msp430-objdump -DS led_091612.elf > led_091612.lst has this result:

led_091612.elf: file format elf32-msp430

Disassembly of section .vectors:

0000ff80 <.vectors>:

ff80: 24 5c add @r12, r4

ff82: 24 5c add @r12, r4

ff84: 24 5c add @r12, r4

ff86: 24 5c add @r12, r4

ff88: 24 5c add @r12, r4

ff8a: 24 5c add @r12, r4

ff8c: 24 5c add @r12, r4

ff8e: 24 5c add @r12, r4

ff90: 24 5c add @r12, r4

ff92: 24 5c add @r12, r4

ff94: 24 5c add @r12, r4

ff96: 24 5c add @r12, r4

ff98: 24 5c add @r12, r4

ff9a: 24 5c add @r12, r4

ff9c: 24 5c add @r12, r4

ff9e: 00 5c add r12, r0

Disassembly of section .text:

00005c00 <RESET>:

5c00: 31 40 00 5c mov #23552, r1 ;#0x5c00

00005c04 <StopWDT>:

5c04: b2 40 80 5a mov #23168, &0x015c ;#0x5a80

5c08: 5c 01

00005c0a <SetupP1>:

5c0a: d2 d3 04 02 bis.b #1, &0x0204 ;r3 As==01

00005c0e <Mainloop>:

5c0e: d2 e3 02 02 xor.b #1, &0x0202 ;r3 As==01

00005c12 <Wait>:

5c12: 3f 40 00 50 mov #20480, r15 ;#0x5000

00005c16 <L1>:

5c16: 3e 40 14 00 mov #20, r14 ;#0x0014

00005c1a <L2>:

5c1a: 1e 83 dec r14

5c1c: fe 23 jnz $-2 ;abs 0x5c1a

5c1e: 1f 83 dec r15

5c20: fa 23 jnz $-10 ;abs 0x5c16

5c22: f5 3f jmp $-20 ;abs 0x5c0e

00005c24 <no_int>:

5c24: 00 13 reti

Disassembly of section reset:

00000000 <reset>:

0: 00 5c add r12, r0

;*****************************************************8

Need help to find out what went wrong. What can it be?

Regards Bo

Hello Bo,

sorry, I'm not a MSP430 specialist.

It doesn't look like a mspdebug issue though, erase program and run seem to work nicely.

Please try to compile & run the hello.c file I included in my posting above, if it does then the problem is the assembly program or the linker.

Regards,

Lo

The target is detected

> MSP430_Initialize: /dev/ttyACM0

> Firmware version is 30204005

> MSP430_VCC: 3000 mV

> MSP430_OpenDevice

> MSP430_GetFoundDevice

> Device: MSP430F5438A (id = 0x009f)

> (mspdebug) prog led_091612.elf

> Erasing...

> Programming...

> Writing 32 bytes at ff80 [section: .vectors]...

> Writing 38 bytes at 5c00 [section: .text]...

> Done, 70 bytes total

This seems not to be a mspdebug problem because the binary to load is not OK.

Here is at least one problem. The interrupt vector is not written and it has to be at 0xfffe

Don't know what's going wrong in your setup but you can try to set the vector manually like this:

(mspdebug) mw 0xfffe 0x00 0x5c
(mspdebug) reset
(mspdebug) regs
    ( PC: 05c00)  ( R4: 0ccc4)  ( R8: 0ccc8)  (R12: 0cccc)  
    ( SP: 0ccc1)  ( R5: 0ccc5)  ( R9: 0ccc9)  (R13: 0cccd)  
    ( SR: 00000)  ( R6: 0ccc6)  (R10: 0ccca)  (R14: 0ccce)  
    ( R3: 00000)  ( R7: 0ccc7)  (R11: 0cccb)  (R15: 0cccf)  
0x5c00:

If your binary starts at 0x5c00, it should start now.

The interrupt vector for the F5438a starts at 0xff80, and based on the output of mspdebug is probably being written correctly.  The error is that the asm code only provides 16 elements for the vector, so the pointers end up at the wrong offset.  Most/all 5xx MCUs have a 64-element vector table, and the important entries are at the end of it.

Hello to Hans and Peter

So if each element is 2 bytes wide, the code could be written like this:

.section .vectors, "a", @progbits ; Set attribs CONTENTS, ALLOC, LOAD, READONLY, DATA

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, 0x00

.word 0x00, 0x00, 0x00, main

… if the linker command file tk.map is like this:

MEMORY

{

TEXT : ORIGIN = 0x05c00, LENGTH = 0x0a380

DATA : ORIGIN = 0x1c00, LENGTH = 0x04000

VECTORS : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 bytes or 64 elements */

}

SECTIONS

{

.text : { *(.text) } > TEXT

.data : { *(.data) } > DATA

.vectors : { *(.section .vectors) } > VECTORS

.bss : { *(.bss) }

}

But if I understand it right it could actually do with this :

In the code in - tk.asm - line 18 could be :

.word 0x00, 0x00, 0x00, main

...if the tk.map command file was written like this:

MEMORY

{

TEXT : ORIGIN = 0x05c00, LENGTH = 0x0a380

DATA : ORIGIN = 0x1c00, LENGTH = 0x04000

VECTORS : ORIGIN = 0xfffc, LENGTH = 0x004 /* END=0x10000, size 8 bytes or 4 elements */

}

SECTIONS

{

.text : { *(.text) } > TEXT

.data : { *(.data) } > DATA

.vectors : { *(.section .vectors) } > VECTORS

.bss : { *(.bss) }

}

If this is right, I am not confused any more and can stop walking around in my code and blow the fuse (as the error was) on my MSP-FET430UIF, which actually happened when I, out of ignorance, wrote this in the MEMORY part of command file tk.map: VECTORS : ORIGIN = 0xffe0, LENGTH = 0x080. It turned out that I had erased the passwords for JTAG and BSL when I marched into and occupied their area.

Only two things have yet to be cleared now. The first is about priority. Has the “main” function highest or lowest priority when it is in the ending 2 bytes of the vector area like now? I believe it's highest priority. Am I right?

The second is about the tk.lst file and what and when I can expect to see the program counter's content (PC). I suppose that when the program has just finished/stopped and doesn't do what I expect, i.e. blink the red LED, the PC content is not the address for the program to start – i.e. it is not the address to the main function. On which line should the break-point be applied and which command should be fired to follow the PC content during the process when I compile with msp430-as -o tk.o -mmsp430x5438 tk.as? Will msp430-objdump -DS tk.elf > tk.lst be the only choice or is something else better? According to Daniel Beer, who has looked on the problem (and I owe him big thanks), the PC in tk.lst is now initialized to a random number.

By the way, Peter , if you read this! I have read that you have some experience, too, when it comes to “blowing fuses”. In your case it was the FR5739 experimenter board in July this year. I also read how you found a fix for that, at least temporarily. You were helped by this article “Http://dbindner.freeshell.org/msp430/fram-bsl.html. In the article I could read how you had to short some jumpers on the “Fraunchpad'' to able to make the full-erase of the “blown” MSP-FET430UIF. While I plan to use the same cure for my “blown” MSP-FET430UIF but am working on the MSP-EXP430F5438 Experimenter Board, I wonder if there are some jumpers which are necessary to be shorted there, too? Do you have any idea? I would rather not blow my whole laboratory!

Regards Bo

Hello to Lo, too

I see a mistake of me in my previous post at.

MEMORY

{

TEXT : ORIGIN = 0x05c00, LENGTH = 0x0a380

DATA : ORIGIN = 0x1c00, LENGTH = 0x04000

VECTORS : ORIGIN = 0xfffc, LENGTH = 0x004 /* END=0x10000, size 8 bytes or 4 elements */

}

I just read in 1.3.1 MSP430 Devices With Shared JTAG Pins in MSP430 Programming Via the Bootstrap Loader User's Guide that

(a)pplying an appropriate entry sequence on the RST/NMI and TEST pins forces the MSP430 to start

program execution at the BSL RESET vector instead of at the RESET vector located at address FFFEh. ” means that the above should be changed to :

.

.

VECTORS : ORIGIN = 0xfffb, LENGTH = 0x004 /* END=0x10000, size 8 bytes or 4 elements */

The reason is of course that we want to start

program execution at the RESET vector located at address FFFEh, i.e. with main

Regards Bo.

Hello Bo,

so the issue is solved now? great.

I did some testing with your old configuration and got it finally blinking. But I had to set the reset vector manually

as described in my other response.

By the way, do you know this software emulator for MSP430?

https://sourceforge.net/p/msp4linux/home/Home/

It can be used together with mspdebug and I do all the configuration and loading tests with it.

The switch between real hardware and emulation works like this (if installed): 

./mspdebug tilib -d /dev/ttyACM0 - for real hardware

and

./mspdebug tilib -d simulator - for emulation

It helped me a lot to control the output before testing it on a real device and there is no risk of overwriting something.

The bad thing: The instruction simulator itself is in a very early development stage, but it's growing fast.

Could it be helpful for you?

Regards

Hi Hans

Thanks for your proposals. Haven't found a method to cure the 'blown fuse" on FET430UIF. I'm still waiting for my new MSP-FET430UIF from TI, so I don't know if my problem is solved. Because of that it could also be interesting to know your solution to get it finally blinking i.e. how you set the vector manually. I will also try out the software emulator for MSP430 you are mentioning. Looks very interesting.Thank you for all!

Regards Bo

Hello,

for anybody who's interested. This is the MSP-EXP430F5438A user experience demo 16kb for Code Composer Studio v5 on Linux.

0825.msp_exp430f5438A_user_experience_demo_16kb.zip

Regards,

Lo

Hi everyone,

Is there gcc for Windows much like the WinAVR for Atmel? That Eclipse based IDE is terrible. I would much rather use notepad and then create a make file myself.

Thanks

Boyan Biandov

Is there gcc for Windows much like the WinAVR for Atmel?

Yes.  See available mspgcc distributions in the Installation section at https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki

For assistance with pre-built packages or building from source or anything to do with mspgcc,  email the mspgcc mailing list referenced in the wiki under the Community section.

This looks like very helpful information.  However, the msp430_dllv3_os_package.patch attachment doesn't seem to be available in this forum, and I can't locate it anywhere.  Can you tell me where I might be able to get it?

Thank you for the very helpful posting.

- Steve