Whoops, I misunderstood what you were saying. I thought the error was a fatal error, but you are right, we can just ignore the error and move on.
Thanks, Alex On Fri, Jul 1, 2011 at 10:44 AM, Peter Bigot <big...@acm.org> wrote: > As I think I mentioned, that "error" is not surprising if you don't have the > source to the C runtime system on your machine, but it also doesn't mean > that debugging won't work. If you set a breakpoint on your main routine > and say "run", does it do something useful? > > Peter > > On Fri, Jul 1, 2011 at 12:23 PM, Crazy Casta <crazyca...@gmail.com> wrote: >> >> This doesn't seem to have been making the list (gmail's fault), so I >> figured I'd copy it to the list. To summarize, I don't know what to >> use other than gdbproxy on windows. >> >> On Fri, Jul 1, 2011 at 10:19 AM, Crazy Casta <crazyca...@gmail.com> wrote: >> > I'm using that build now. The error that I get is: >> > _reset_vector__ () at ../../../gcc-4.5.2/gcc/config/msp430/crt0.S:118 >> > 118 ../../../gcc-4.5.2/gcc/config/msp430/crt0.S: No such file or >> > directory. >> > in ../../../gcc-4.5.2/gcc/config/msp430/crt0.S >> > >> > I know you said no one supports gdbproxy. What is the alternative for >> > windows? >> > >> > On Thu, Jun 30, 2011 at 3:13 PM, Crazy Casta <crazyca...@gmail.com> >> > wrote: >> >> Nevermind about the link, it works now. >> >> >> >> On Thu, Jun 30, 2011 at 2:26 PM, Crazy Casta <crazyca...@gmail.com> >> >> wrote: >> >>> That link doesn't seem to work. Does mspdebug work on Windows? As I >> >>> understood it, it uses libusb which as I understand doesn't have any >> >>> equivalent on Windows. >> >>> >> >>> On Thu, Jun 30, 2011 at 3:27 AM, Peter Bigot <big...@acm.org> wrote: >> >>>> Please try the windows release described in: >> >>>> >> >>>> http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/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 <crazyca...@gmail.com> >> >>>> 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 >> >>>>> Mspgcc-users@lists.sourceforge.net >> >>>>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >>>> >> >>>> >> >>> >> >> >> > >> >> >> ------------------------------------------------------------------------------ >> 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 >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > ------------------------------------------------------------------------------ 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
