Mspdebug: "prog" programs vectors, not program code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Mspdebug: "prog" programs vectors, not program code

MarkoC
Hello,

I am new to the list. Bought an MSP-FET many years ago, but only got to use it now.

I have encountered a strange problem: when I try to flash my chip (MSP430F149), only the interrupt vectors get programmed at 0xFFE0,  the code area at 0x1100 remains blank.
Are there F149 versions with less memory, so that 0x1100 is not populated?
Could there be a problem with the .elf file?

I also have an MSP-EXP430G board, there I can flash and run an almost identical program successfully.

Below is a screenshot:

mc@bpc2 ~/MSP430/MSP-FET $
mc@bpc2 ~/MSP430/MSP-FET $
mc@bpc2 ~/MSP430/MSP-FET $ make
msp430-gcc -Os -Wall -g -mmcu=msp430f149 -c main.c
msp430-gcc -Os -Wall -g -mmcu=msp430f149 -o main.elf main.o
mc@bpc2 ~/MSP430/MSP-FET $ ls -l
total 44
-rw-r--r-- 1 mc mc 1285 Aug 11 12:58 fet140_1.c
-rwxr-xr-x 1 mc mc 8629 Aug 11 12:52 fet140_1.elf
-rw-r--r-- 1 mc mc 2628 Aug 11 12:52 fet140_1.o
-rw-r--r-- 1 mc mc 3430 Aug 11 12:41 main.c
-rwxr-xr-x 1 mc mc 8942 Aug 11 13:22 main.elf
-rw-r--r-- 1 mc mc 3520 Aug 11 13:22 main.o
-rw-r--r-- 1 mc mc  182 Aug 10 14:40 Makefile
-rw-r--r-- 1 mc mc    0 Aug 11 13:21 problem.txt
mc@bpc2 ~/MSP430/MSP-FET $ mspdebug pif -j -d /dev/parport0
MSPDebug version 0.22 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2013 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.

Starting JTAG
JTAG ID: 0x89
Chip ID: F149
Chip ID data: f1 49

Available commands:
    =           erase       isearch     power       save_raw    simio      
    alias       exit        load        prog        set         step        
    break       fill        load_raw    read        setbreak    sym        
    cgraph      gdb         md          regs        setwatch    verify      
    delbreak    help        mw          reset       setwatch_r  verify_raw  
    dis         hexout      opt         run         setwatch_w  

Available options:
    color                       gdb_loop                    
    enable_bsl_access           gdbc_xfer_size              
    enable_locked_flash_access  iradix                      
    fet_block_size              quiet                      
    gdb_default_port            

Type "help <topic>" for more information.
Use the "opt" command ("help opt") to set options.
Press Ctrl+D to quit.

(mspdebug) erase
Erasing...
(mspdebug) dis 0x1100 32
0x1100:
    01100: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01104: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01108: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0110c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01110: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01114: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01118: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0111c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
(mspdebug) dis 0xffe0 32
0xffe0:
    0ffe0: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0ffe4: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0ffe8: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0ffec: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0fff0: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0fff4: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0fff8: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0fffc: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
(mspdebug) load main.elf
Writing  144 bytes at 1100 [section: .text]...
Writing   32 bytes at ffe0 [section: .vectors]...
Done, 176 bytes total
(mspdebug) prog main.elf
Erasing...
Programming...
Writing  144 bytes at 1100 [section: .text]...
Writing   32 bytes at ffe0 [section: .vectors]...
Done, 176 bytes total
(mspdebug) dis 0x1100 32
__wdt_clear_value+0xf00:
    01100: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01104: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01108: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0110c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01110: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01114: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    01118: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0111c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
(mspdebug) dis 0xffe0 32
__ivtbl_16:
    0ffe0: 70 11 70 11               RRA     #0x1170
    0ffe4: 70 11 70 11               RRA     #0x1170
    0ffe8: 70 11 70 11               RRA     #0x1170
    0ffec: 82 11                     SXT     SR
    0ffee: 70 11 70 11               RRA     #0x1170
    0fff2: 70 11 70 11               RRA     #0x1170
    0fff6: 70 11 70 11               RRA     #0x1170
    0fffa: 70 11 70 11               RRA     #0x1170
    0fffe: 00 11                     RRA     PC
(mspdebug)
Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

Ben Green
Hello MarkoC,

To rule out a problem with the ELF file (it looks like it is OK from
the prog output) use the msp430 binutils to disassemble:

msp430-objdump --disassemble main.elf

That should confirm you have some valid code in your ELF.

The flash offsets seem correct for the device you are using.
As you seem to be able to write the vectors (segment 0) perhaps you
could change your .ld file to locate the code in segment 2 (0xfa00), I
know it is not a perminant fix but it should give you more of an idea
of what is wrong.

Benjamin.

On Thu, 11 Aug 2016 04:54:18 -0700 (MST)
MarkoC <[hidden email]> wrote:

> Hello,
>
> I am new to the list. Bought an MSP-FET many years ago, but only got
> to use it now.
>
> I have encountered a strange problem: when I try to flash my chip
> (MSP430F149), only the interrupt vectors get programmed at 0xFFE0,
> the code area at 0x1100 remains blank.
> Are there F149 versions with less memory, so that 0x1100 is not
> populated? Could there be a problem with the .elf file?
>
> I also have an MSP-EXP430G board, there I can flash and run an almost
> identical program successfully.
>
> Below is a screenshot:
>
> mc@bpc2 ~/MSP430/MSP-FET $
> mc@bpc2 ~/MSP430/MSP-FET $
> mc@bpc2 ~/MSP430/MSP-FET $ make
> msp430-gcc -Os -Wall -g -mmcu=msp430f149 -c main.c
> msp430-gcc -Os -Wall -g -mmcu=msp430f149 -o main.elf main.o
> mc@bpc2 ~/MSP430/MSP-FET $ ls -l
> total 44
> -rw-r--r-- 1 mc mc 1285 Aug 11 12:58 fet140_1.c
> -rwxr-xr-x 1 mc mc 8629 Aug 11 12:52 fet140_1.elf
> -rw-r--r-- 1 mc mc 2628 Aug 11 12:52 fet140_1.o
> -rw-r--r-- 1 mc mc 3430 Aug 11 12:41 main.c
> -rwxr-xr-x 1 mc mc 8942 Aug 11 13:22 main.elf
> -rw-r--r-- 1 mc mc 3520 Aug 11 13:22 main.o
> -rw-r--r-- 1 mc mc  182 Aug 10 14:40 Makefile
> -rw-r--r-- 1 mc mc    0 Aug 11 13:21 problem.txt
> mc@bpc2 ~/MSP430/MSP-FET $ mspdebug pif -j -d /dev/parport0
> MSPDebug version 0.22 - debugging tool for MSP430 MCUs
> Copyright (C) 2009-2013 Daniel Beer <[hidden email]>
> This is free software; see the source for copying conditions.  There
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> Starting JTAG
> JTAG ID: 0x89
> Chip ID: F149
> Chip ID data: f1 49
>
> Available commands:
>     =           erase       isearch     power       save_raw
> simio alias       exit        load        prog        set
> step break       fill        load_raw    read        setbreak
> sym cgraph      gdb         md          regs        setwatch
> verify delbreak    help        mw          reset       setwatch_r
> verify_raw dis         hexout      opt         run
> setwatch_w  
>
> Available options:
>     color                       gdb_loop                    
>     enable_bsl_access           gdbc_xfer_size              
>     enable_locked_flash_access  iradix                      
>     fet_block_size              quiet                      
>     gdb_default_port            
>
> Type "help <topic>" for more information.
> Use the "opt" command ("help opt") to set options.
> Press Ctrl+D to quit.
>
> (mspdebug) erase
> Erasing...
> (mspdebug) dis 0x1100 32
> 0x1100:
>     01100: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01104: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01108: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0110c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01110: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01114: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01118: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0111c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
> (mspdebug) dis 0xffe0 32
> 0xffe0:
>     0ffe0: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0ffe4: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0ffe8: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0ffec: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0fff0: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0fff4: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0fff8: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0fffc: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
> (mspdebug) load main.elf
> Writing  144 bytes at 1100 [section: .text]...
> Writing   32 bytes at ffe0 [section: .vectors]...
> Done, 176 bytes total
> (mspdebug) prog main.elf
> Erasing...
> Programming...
> Writing  144 bytes at 1100 [section: .text]...
> Writing   32 bytes at ffe0 [section: .vectors]...
> Done, 176 bytes total
> (mspdebug) dis 0x1100 32
> __wdt_clear_value+0xf00:
>     01100: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01104: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01108: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0110c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01110: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01114: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     01118: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
>     0111c: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
> (mspdebug) dis 0xffe0 32
> __ivtbl_16:
>     0ffe0: 70 11 70 11               RRA     #0x1170
>     0ffe4: 70 11 70 11               RRA     #0x1170
>     0ffe8: 70 11 70 11               RRA     #0x1170
>     0ffec: 82 11                     SXT     SR
>     0ffee: 70 11 70 11               RRA     #0x1170
>     0fff2: 70 11 70 11               RRA     #0x1170
>     0fff6: 70 11 70 11               RRA     #0x1170
>     0fffa: 70 11 70 11               RRA     #0x1170
>     0fffe: 00 11                     RRA     PC
> (mspdebug)
>
>
>
>
> --
> View this message in context:
> http://msp430-gcc-users.1086195.n5.nabble.com/Mspdebug-prog-programs-vectors-not-program-code-tp7409.html
> Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic patterns at an interface-level. Reveals which users, apps,
> and protocols are consuming the most bandwidth. Provides multi-vendor
> support for NetFlow, J-Flow, sFlow and other flows. Make informed
> decisions using capacity planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

David W. Schultz
In reply to this post by MarkoC
It has been a while but I seem to remember having a similar problem. Too
long ago to remember details but I think it was a problem with the
section flags.

You can check the flags using msp430-elf-readelf -S XX.elf



--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

Daniel Beer-3
In reply to this post by MarkoC
On Thu, Aug 11, 2016 at 04:54:18AM -0700, MarkoC wrote:
> mc@bpc2 ~/MSP430/MSP-FET $ mspdebug pif -j -d /dev/parport0
> MSPDebug version 0.22 - debugging tool for MSP430 MCUs

>From the output, it doesn't look like there's anything wrong obviously
wrong with your ELF file, but one thing to be aware of is that the
MSP430 requires a steady clock of around 100 kHz during flash
programming. This clock needs to be supplied on a JTAG interface pin,
and the "pif" driver does this by toggling the pin in software. This
works for a lot of people, but it's not guaranteed to because it's
difficult to guarantee timing within the required range.

You might have more luck with one of the smarter MSP430-specific JTAG
adapters.

Cheers,
Daniel

--
Daniel Beer <[hidden email]> http://dlbeer.co.nz/
PGP: BA6E 0B26 1F89 246C E3F3  C910 1E58 C43A 160A 553B

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

MarkoC
In reply to this post by Ben Green
Hello,

thanks to all that have replied, I will be able to dig into this now.
I'll try to check the clock too, to see if I have to buy a new interface...
I bought this one a LONG time ago, and now had to resurrect an old laptop, to have LPT port at all!

Marko
Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

MarkoC
In reply to this post by MarkoC
Hello,

I have looked into the ELF file, and there is good code at 0x1100.
Also, using an Olimex header board, that I also bought long ago, I could see some code at 0x1100 before erasing it, so the memory is there.
Next, I checked the TCK pin witn an o'scope, and found out the follwing:
The clock, when running, has a period between 4 and 9 us.
But the clock is not continuous, it comes in bursts about 5ms long with about 5ms pauses inbetween. In the pauses, TCK is sometimes high and sometimes low. I guess this might have something to do with OS process scheduling. I ran no other user processes at the time, on an 2800MHz celeron and Linux Mint 17.3.

I guess, these clock irregularities might be the problem. Looking at the MSP430x14x datasheet (SLAS272F, July 2000, revised June 2004) page 39, the requirement for "fTCK" is 0 to 10 MHz, which is OK, but the flash timing generator should be 257...476kHz - I do not know how that relates to fTCK?

On a multicore PC, one could maybe dedicate one core to mspdebug, but multicore PCs with an LPT port are more or less nonexistent.

So, I guess I'll have to buy an USB based JTAG box.

The TI original costs $115, and there are chinese surogates on Ebay for $55 or so.
Olimex sells MSP430-JTAG-TINY-V2 for 55 euro.

I am considering the Olimex box, are there any cautions against it?

Marko

Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

Chris Liechti
Am 16.08.2016 um 08:59 schrieb MarkoC:
 > Next, I checked the TCK pin witn an o'scope, and found out the follwing:
 > The clock, when running, has a period between 4 and 9 us.

If you are referring to the parallel port JTAG; the original MSP430.dll
as well as MSP430mspgcc.dll do not supply the flash clock over TCK.
While the hardware supports that and a TI application note shows how to
use that, it not the only way to do it :-)

The DLLs download "funclets" into RAM and execute with the clock of the
MSP. There is a step where the clock is measured (counter funclet) and
separate programming funclets that work with the adjusted clock.

 > But the clock is not continuous, it comes in bursts about 5ms long with
 > about 5ms pauses inbetween. In the pauses, TCK is sometimes high and

TCK is also used for regular JTAG operation.  I guess you won't easily
decipher anything with a scope (unless it has a protocol decoder)

 > I guess, these clock irregularities might be the problem. Looking at the
 > MSP430x14x datasheet (SLAS272F, July 2000, revised June 2004) page
39, the
 > requirement for "fTCK" is 0 to 10 MHz, which is OK, but the flash timing
 > generator should be 257...476kHz - I do not know how that relates to
fTCK?

Desktop OS never supported precise timing on parallel or serial ports
(control lines), so generating the Flash clock for the MSP430 was never
an option (at least i'm not aware of successful software).

 > So, I guess I'll have to buy an USB based JTAG box.

or you can look at the BSL. the serial programmer is easier to use IHMO.
you won't be able to "debug" (breakpoints, single step etc.) but you
only need a serial port level shifter.

i think you mentioned an F149, that supports 4 wire JTAG (only) and BSL.
however, if you use more recent parts (including value line), they
mostly support spy-bi-wire, where a MSP430-Launchpad (~$10) is sufficient.

chris

------------------------------------------------------------------------------
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Mspdebug: "prog" programs vectors, not program code

MarkoC
I see, years ago, I have used a similar "funclets" method on 68HC11.
So, gaps in TCK should not be a problem.

BTW, I also noticed that the supply from the LPT FET box is on the low side for flashing (2.8V, 2.7 is the minimum required), so I connected an external 3.3V supply, but no difference.
The problem is 100% repeatable, 0xffe0 always gets written, 0x1100 never, as far as I have tried.

I have a bunch of f149's and some olimex header boards with them, so I'll just buy the Olimex box.

Thanks for the info,
Marko