Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 -- View this message in context: http://msp430-gcc-users.1086195.n5.nabble.com/Mspdebug-prog-programs-vectors-not-program-code-tp7409p7449.html Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 -- View this message in context: http://msp430-gcc-users.1086195.n5.nabble.com/Mspdebug-prog-programs-vectors-not-program-code-tp7409p7447.html Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 -- View this message in context: http://msp430-gcc-users.1086195.n5.nabble.com/Mspdebug-prog-programs-vectors-not-program-code-tp7409p7413.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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
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 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 mc0 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
> 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 exitloadprogset
> step break fillload_rawreadsetbreak
> sym cgraph gdb md regssetwatch
> verify delbreakhelpmw 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 " 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+, 0x(R15)
> 01104: ff ff ff ff AND.B @R15+, 0x(R15)
> 01108: ff ff ff ff AND.B @R15+, 0x(R15)
> 0110c: ff ff ff ff AND.B @R15+, 0x(R15)
> 01110: ff ff ff ff AND.B @R15+, 0x(R15)
> 01114: ff ff ff ff AND.B @R15+, 0x(R15)
> 01118: ff ff ff ff AND.B @R15+, 0x(R15)
> 0111c: ff ff ff ff AND.B @R15+, 0x(R15)
> (mspdebug) dis 0xffe0 32
> 0xffe0:
> 0ffe0: ff ff ff ff AND.B @R15+, 0x(R15)
> 0ffe4: ff ff ff ff AND.B @R15+, 0x(R15)
> 0ffe8: ff ff ff ff AND.B @R15+, 0x(R15)
> 0ffec: ff ff ff ff AND.B @R15+, 0x(R15)
> 0fff0: ff ff ff ff AND.B @R15+, 0x(R15)
> 0fff4: ff ff ff ff AND.B @R15+, 0x(R15)
> 0fff8: ff ff ff ff AND.B @R15+, 0x(R15)
> 0fffc: ff ff ff ff AND.B @R15+, 0x(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+, 0x(R15)
> 01104: ff ff ff ff AND.B @R15+, 0x(R15)
> 01108: ff ff ff ff AND.B @R15+, 0x(R15)
> 0110c: ff ff ff ff AND.B @R15+, 0x(R15)
> 01110: ff ff ff ff AND.B @R15+, 0x(R15)
> 01114: ff ff ff ff AND.B @R15+, 0x(R15)
> 01118:
