Re: [Mspgcc-users] "Poisoning" of -mmcu targets

[Peter B. <bi...@ac...>]

Please try the windows release described in:
http://www.mail-archive.com/msp...@li.../msg09920.html

mspgcc4 isn't supported anymore, and I can't tell whether the version you're
using has the TI headers, which may have some significance (I assume you
are, since I can't imagine any USB-oriented code would work without TI
headers).

With current releases, please use -mmcu=msp430f5529 and not the "x"
variants.

I'm not sure what problem you're describing.  I don't generally use gdb for
source debugging on the MSP430, but it may simply be saying that when you
load the program, the program counter is positioned at the reset_vector, for
which source is not available on your system.

I have never used msp430-gdbproxy, and as far as I know it's not supported
by anybody.  mspdebug is the replacement solution.

Peter

On Wed, Jun 29, 2011 at 11:29 PM, Crazy Casta <cra...@gm...> wrote:

> I apologize in advance, I have no idea how to explain this except as I
> put it in the subject. My friend and I are using mspgcc4-20110312.zip
> build for windows. We compiled a very simple LED blink program for the
> msp430f5529 (using -mmcu=msp430x5529) and it worked perfectly. We then
> ported the MSP430F5529 USB HID example 1 from IAR kickstart code to
> mspgcc4, also using -mmcu=msp430x5529. When trying to load the code
> using gdb, the same was as for the LED blinker program we got the
> following error:
>
> _reset_vector__ () at
>
> /home/user/mspgcc4-20110312/build/gcc-4.4.5-build/../gcc-4.4.5/libgcc/../gcc/c
> onfig/msp430/libgcc.S:615
> 615
> /home/user/mspgcc4-20110312/build/gcc-4.4.5-build/../gcc-4.4.5/libgcc/../gcc/config/msp430/l
> ibgcc.S: No such file or directory.
>        in
> /home/user/mspgcc4-20110312/build/gcc-4.4.5-build/../gcc-4.4.5/libgcc/../gcc/config/msp43
> 0/libgcc.S
>
> After scratching our heads a bit we went back to try the blinker. It
> gave the same error message. After which we decided maybe we had
> messed up one of the mspgcc files. We moved out the
> msp430-gdbproxy.exe file and deleted all the files in the directory we
> had extracted to. We then re-extracted the files and moved gdbproxy
> back. We copied the msp430.dll and hil.dll from IAR (as we had the
> first time). We then tried to program the blinker again. We restarted
> the computer, deleted temp files from %USERPROFILE%\Local
> Settings\Temp and scratched heads some more. We replaced gdbproxy with
> a fresh download. We then, for the heck of it, compiled without the
> -mmcu flag, gdb did not give an error, though obviously the LED did
> not blink. We then tried msp5, which also (unsurprisingly) had the
> wrong memory map. We then tried -mmcu=msp430x5528. This worked like it
> had the first time on msp430x5529. We then compiled our "poison" code
> for msp430x5528 and tried to use gdb again. It again failed with the
> same exact error message. We then went back and tried gdb (without
> recompiling) with the blinker code (which when we last compiled it,
> before the poison code, had been compiled for msp430x5528) and got the
> same error message.
>
> We have no idea what is going on. We understand that this file has
> something to do with the build process and is not itself included in
> the install files, so this error message is very perplexing. Any
> suggestions on what files or settings to reset/delete would be
> welcome.
>
> Thanks in advance.
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Mspgcc-users mailing list
> Msp...@li...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>