---------------------------------------------------------------- Gabriel Fernandez
On Feb 19, 2010, at 8:29 PM, [email protected] wrote: > Send Mspgcc-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Mspgcc-users digest..." > > > Today's Topics: > > 1. Re: D/FW - Debug FIrmware for FET430UIF and eZ430U > (Tadashi G. Takaoka) > 2. Re: D/FW - Debug FIrmware for FET430UIF and eZ430U > (Shigenobu Kimura) > 3. eZ430-F2013 on MacOSX (Re: D/FW - Debug FIrmware for > FET430UIF and eZ430U) (Shigenobu Kimura) > 4. Using GCC for EZ430 (Milind Gupta) > 5. Re: Using GCC for EZ430 (Peter Bigot) > 6. Re: CC430 support patches available (Peter Bigot) > 7. stack variable in flash? (Carl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 9 Feb 2010 11:26:33 +0900 > From: "Tadashi G. Takaoka" <[email protected]> > Subject: Re: [Mspgcc-users] D/FW - Debug FIrmware for FET430UIF and > eZ430U > To: "GCC for MSP430 - http://mspgcc.sf.net" > <[email protected]> > Cc: Shigenobu Kimura <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-2022-JP > > Hi, Kimura-san. > > That is incredibly great! Especially for the OSX lover ;) > > According to the slau176b (eZ430-F2013 Development Tool), it looks the > USB stick is almost identical except the target connector (6 pin v.s. > 4 pin). I would like to know that your DFW will work fine on it also. > > 2010/2/8 Shigenobu Kimura <[email protected]>: >> Hello, >> >> I wrote a firmware for FET430UIF and eZ430U for my >> self training. >> >> http://homepage.mac.com/skimu/msp430/dfw/ >> >> Below is a part of README file. >> >> -- Shigenobu Kimura >> >> ;;; >> ;;; D/FW -- Debug Firmware for MSP-FET430UIF/eZ430U >> ;;; >> ;;; [email protected], February 2010 >> ;;; >> >> ----------- Introduction ---------------------------------------- >> >> This is an open source, experimental, and unofficial firmware for >> MSP-FET430UIF/eZ430U debug interface and associated host side >> control programs. >> >> ------------ Combinations known to work ------------------------- >> >> Host : MacOSX (Darwin 10.2.0) >> >> FET Device TAP Target Board >> >> FET430UIF F169 JTAG MSP-TS430PM64 >> FET430UIF F2274 JTAG MSP-TS430DA38 >> FET430UIF F2274 SBW MSP-TS430DA38 >> FET430UIF F2274 SBW RF2500T >> FET430UIF F1612 JTAG eZ430U(Rev2.0) >> eZ430U F2274 SBW RF2500T >> >> MSP430X (4xx/5xx) support code included but not tested and >> it is unlikely to work as is. >> >> ----------- Requirements ---------------------------------------- >> >> 1) FET430UIF or eZ430U (target FET), which you don't miss much if >> it get broken. (See below for notes on eZ430-F2013) >> >> 2) 4 wire JTAG programmer to write DFW into your FET. (mother FET). >> DFW has ability to upgrade itself from USB port, you only need >> mother programmer just for the first time. >> >> 3) Mac running MacOSX (host computer) >> (See libusbcom/usbcom_libusbc.c about libusb support for other >> Unix variants.) >> >> 4) MSPGCC toolchain on your host computer. See below for tips >> on MSPGCC installation on MacOSX. >> >> 5) No USB device with vendor/product ID of 0x451/0xbeef. >> These are the ones DFW is using. There are not yet easy way >> to change these IDs. See below how to change USB IDs. >> >> ------------ Known bugs (less priority To-Do's) ----------------- >> >> 1) Reconnecting target device's JTAG/SBW is unstable. >> (It is OK for the first time after power on.) >> Need unplug and re-plug USB to work around. >> >> 2) Error recovery is missing. >> >> 3) breakpoints does not work. I could not find any useful >> documentation about f16x's break-point registers, nor f2xxx's >> EEM feature... >> >> 4) backtrace does not work with GDB-6.8 (7.0 is OK). >> >> 5) cannot get local variables correctly (especially for binaries >> compiled with -O0 option). >> >> 6) Requires special USB software for host. >> -> Need to write generic communication class firmware for TUSB3410. >> >> 7) support target serial port at TUSB3410 on eZ430, for independent >> communications host<->FET and host<->target. >> (this requires software serdes on TUSB3410, I think) >> >> 8) TUSB3410's autoexec firmware does not work. (disabled by default) >> >> >> >> >> >> ------------------------------------------------------------------------------ >> The Planet: dedicated and managed hosting, cloud storage, colocation >> Stay online with enterprise data centers and the best network in the business >> Choose flexible plans and management services without long-term contracts >> Personal 24x7 support from experience hosting pros just a phone call away. >> http://p.sf.net/sfu/theplanet-com >> _______________________________________________ >> Mspgcc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > > > > -- > ?????????????? > takaoka is charging up > > > > ------------------------------ > > Message: 2 > Date: Mon, 08 Feb 2010 20:41:02 -0600 > From: Shigenobu Kimura <[email protected]> > Subject: Re: [Mspgcc-users] D/FW - Debug FIrmware for FET430UIF and > eZ430U > To: "GCC for MSP430 - http://mspgcc.sf.net" > <[email protected]> > Cc: Shigenobu Kimura <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On Feb 8, 2010, at 8:26 PM, Tadashi G. Takaoka wrote: > >> According to the slau176b (eZ430-F2013 Development Tool), it looks the >> USB stick is almost identical except the target connector (6 pin v.s. >> 4 pin). I would like to know that your DFW will work fine on it also. > > Exactly, support code for eZ430-F2013 included but not tested. > To make binary for eZ430-F2013, edit dfw-0.2/dfw/Makefile > to make -DEZ430U1P1 effective and type "make clean && make" > (not "make dist" as mentioned in README). The compiled binary > file (dfw) is the binary for eZ430-F2013. > > Please let me know whether it works or not, so that I can update > D/FW homepage. > > -- Shigenobu Kimura > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 08 Feb 2010 22:48:14 -0600 > From: Shigenobu Kimura <[email protected]> > Subject: [Mspgcc-users] eZ430-F2013 on MacOSX (Re: D/FW - Debug > FIrmware for FET430UIF and eZ430U) > To: "GCC for MSP430 - http://mspgcc.sf.net" > <[email protected]> > Cc: Shigenobu Kimura <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > I have gotten a few questions about this. > > D/FW overrides both TUSB3410's firmware and F1612's, > so the only differences between eZ430U and eZ430-2013 is > port assignment of RST_3410 signal, really. > So I think it is very likely that D/FW works on > eZ430-F2013. > > But if getting eZ430 work on MacOSX is all what you want, > I think > > http://homepages.xnet.co.nz/~dlbeer/ > > is another candidate. It worked with my FET430UIF(Rev1.3) > on MacOSX with some modifications as follows, > > 1) grab elf.h from glibc, (MacOSX does not have this header) > 2) modify rf2500.c to make use of my libusbcom (included in D/FW) > instead of libusb. > 2') I tried libusb-0.1.12 but it did not work. > 3) modify fet.c not to put rf2500 speific ``who knows what this is'' > (since I put FET430UIF support into rf2500 support code, mspdebug > tries to put this into FET430UIF which messed it up) > 4) other rather trivial changes (ex. B460800 -> 460800) > > But this modification did not work for eZ430U, the reason is > > 1) FET430UIF which has 0x451/f430 for USB vendor/product ID is > a vendor specific device and TUSB3410 does not have real > firmware for TUSB3410 and running ROM bootstrap loader at > power on. (and Windows VCP software or linux driver puts > the firmware when it get connected and my libusbcom do the > same. libusbcom uses a TUSB3410's firmware which makes > FET a vendor specific USB device with 3 bulk port) > > 2) eZ430U(rev2.0) which has 0x451/f432, has real firmware for > TUSB3410 in EEPROM which makes eZ430U a USB HID device. > MacOSX's HID service takes control of it when it get connected. > > So I had a choice, A) learn IOKit programming on MacOSX. > B) learn MSP430 programming by writing firmware for FET430UIF. > > I chose B since learning MSP430 programming is what I wanted to do > from the beginning! (although I was thinking much smaller thing > to start with) > > That's said, above modification for FET430UIF *might* work for eZ430-F2013, > since this is old design, there is a good chance TI is using same > USB configuration as FET430UIF. > > Plug eZ430-F2013 into your Mac and open USB prober in > /Developer/Applications/Utilities > and check eZ430-F2013's vendor/product ID. > > If it is 0x451/0xf430, I can give you my dirty hack as a starting point > of MacOSX support for mspdebug. > > I think, this is easier safer and more beneficial for mspgcc community > than soldering JTAG port and put an immature firmare like D/FW. > > If product ID is 0xf432, you have similar choice as mine, > A) learn IOKit programming on MacOSX and port mspdebug to MacOSX. > B) Get involved in debugging debug firmware. > > > -- Shigenobu Kimura > > > > > > > > > ------------------------------ > > Message: 4 > Date: Sun, 14 Feb 2010 22:46:50 -0800 > From: Milind Gupta <[email protected]> > Subject: [Mspgcc-users] Using GCC for EZ430 > To: mspgcc-users <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > This is my first time using MSP430GCC. Is it possible to use it > with the EZ430 development kit? Any help, suggestions, links would be > appreciated. Thanks. > > Regards, > Milind > > ------------------------------ > > Message: 5 > Date: Mon, 15 Feb 2010 07:03:58 -0700 > From: Peter Bigot <[email protected]> > Subject: Re: [Mspgcc-users] Using GCC for EZ430 > To: "GCC for MSP430 - http://mspgcc.sf.net" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Although my EZ430 is still in the box, I believe there are others who have > had success. I do use MSP430 with the TI EM430 board which uses the same > chip. You need binutils and gcc patches, which according to the logs are > being integrated into the mspgcc4 development line. A new distribution > should be coming out soon which will make this easier. > > You also need msp430-libc patches. For lack of a better location, I host > those in a git repository on sourceforge at git:// > oshan.git.sourceforge.net/gitroot/oshan/msp430-libc > > At the moment, updating the library probably requires doing an install of > mspgcc4, then getting the msp430-libc material and doing a "make > PREFIX=/opt/msp430-gcc-4.4.3 install" from there. > > So: It can be done, but isn't yet a turnkey operation. > > Peter > > On Sun, Feb 14, 2010 at 11:46 PM, Milind Gupta <[email protected]>wrote: > >> Hi, >> This is my first time using MSP430GCC. Is it possible to use it >> with the EZ430 development kit? Any help, suggestions, links would be >> appreciated. Thanks. >> >> Regards, >> Milind >> >> >> ------------------------------------------------------------------------------ >> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, >> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW >> http://p.sf.net/sfu/solaris-dev2dev >> _______________________________________________ >> Mspgcc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> > > ------------------------------ > > Message: 6 > Date: Fri, 19 Feb 2010 13:12:57 -0700 > From: Peter Bigot <[email protected]> > Subject: Re: [Mspgcc-users] CC430 support patches available > To: "GCC for MSP430 - http://mspgcc.sf.net" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > The text below is accurate except that the patches have been modified to be > more consistent with TI naming conventions (specifically the names of the > include files), and the repository has been removed and replaced by a git > repository at: > > git://oshan.git.sourceforge.net/gitroot/oshan/msp430-libc > > Baselined stable releases of the msp430-libc are hosted at > https://sourceforge.net/projects/oshan/files/ in the msp430-libc directory. > I believe this version will be an option in future mspgcc4 builds. The > binutils and gcc patches have also been integrated into mspgcc4. > > I'd like to make one last plea for fork-avoidance in the library. The > mspgcc4 project, which I've moved to entirely, uses subversion. The mspgcc > project has both Bazaar and CVS repositories, and it appears the CVS one has > recently seen activity in the msp430-libc area. I had not been tracking > those changes, but I'll start trying to do so. > > But wouldn't it be nice if there was just one version somewhere? Heck, I'll > even volunteer to maintain msp430-libc hosted from this project if somebody > adds me as a developer and I can use git. There's no reason why the > standalone library shouldn't work with mspgcc as well as mspgcc4; up to two > weeks ago that's what I was using. > > Peter > > On Wed, Jan 13, 2010 at 11:43 AM, Peter Bigot <[email protected]> wrote: > >> In support of OSHAN <http://sourceforge.net/projects/oshan/>, an open >> source home area network targeted to embedded devices, I've implemented >> CC430 support in MSPGCC. It is currently available for download from the >> OSHAN project page on SourceForge, in a Bazaar repository based on the >> MSPGCC one at http://sourceforge.net/projects/mspgcc/develop. You can get >> a copy using: >> >> bzr checkout bzr://oshan.bzr.sourceforge.net/bzrroot/mspgcc-core.cc430 >> >> For convenience of those who don't want to deal with Bazaar, I've also made >> available a tar file with the current contents, and a patch relative to the >> trunk at the time I started, at: >> >> http://sourceforge.net/projects/oshan/files/ >> >> A set of examples that work on the TI EM430 developer board are also >> available from the OSHAN project on >> SourceForge<http://sourceforge.net/projects/oshan/files/> >> . >> >> I apologize for the lack of convenience, but I'm not building releases of >> this: it's been tested on Linux (Fedora 9), and you can build it with the >> buildgcc.sh script that comes as part of the mspgcc-core branch. The >> binutils patch is for 2.19.1, and the gcc changes are for 3.2.3, but the >> bulk of the work was in msp430-libc, so supporting the port in other >> versions of gcc should be pretty easy. >> >> My hope is the current MSPGCC maintainers will have a chance to look over >> the changes and incorporate them into the mainline; I don't want yet another >> forked MSPGCC. However, I'll maintain the repository that's hosted in the >> OSHAN project until the changes are integrated somewhere more official. If >> you have problems, please mail [email protected]. >> >> Notes on the changes are below. >> >> CC430 Support in MSPGCC >> ======================= >> >> This directory contains patches to support the TI CC430 System-on-Chip >> family. These chips incorporate a MSP430-5xx microcontroller with a CC1101 >> radio. >> >> Only the gcc/gcc-3.2 compiler patches have been updated for CC430 support, >> but the bulk of the effort is in msp430-libc, so adapting this for a >> working >> version of a different compiler should be trivial. See the diffs for the >> necessary steps. >> >> Relative to the baseline MSPGCC system, the patches in this directory >> incorporate: >> >> * Updates to binutils-2.19.1.patch to handle the eight defined CC430 chips >> >> * Updates to the gcc/gcc-3.2 configuration files to handle the CC430 chips >> >> * Addition of a <cc430.h> include file for mspgcc-libc. >> >> * Additional MSP430-5xx module support from JMGross <[email protected] >>> , >> including new support for: >> - CRC16 >> - Power Management Module >> >> * Additional MSP430-5xx/CC430 module support from Peter Bigot >> <[email protected]>, including new support for: >> - Port Mapping Control >> - Special Functions >> - Advanced Encryption Standard >> - RF1A CC1101 Radio Module >> >> * Addition of mnemonic defines matching TI headers (e.g., TASSEL__TACLK >> mapping to TASSEL_0). >> >> * Assorted fixes for watchdog support on processors that do not map WDTCTL >> to 0x0120. >> >> Build and install in the normal way. >> >> > > ------------------------------ > > Message: 7 > Date: Fri, 19 Feb 2010 18:29:03 -0700 > From: Carl <[email protected]> > Subject: [Mspgcc-users] stack variable in flash? > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain > > I'm sure that I'm missing some basic here but I'm not sure what. The > first variable on the stack is in an unexpected location. I would expect > it to be located somewhere on the stack in RAM (0x30ff-0x1100) but it is > located in flash memory and it does not get set or incremented. > > > #include <io.h> > > int main() > { > int i=0; > while(1) > i++; > } > > msp430-gcc -g -O0 -mmcu=msp430x2618 -I/opt/msp430/4.4.2/include main.c > > (gdb) load a.out > Loading section .text, size 0x46 lma 0x3100 > Loading section .vectors, size 0x40 lma 0xffc0 > Start address 0x3100, load size 134 > Transfer rate: 1 KB/sec, 33 bytes/write. > (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > main () at main.c:7 > 7 i++; > (gdb) p &i > $1 = (int *) 0x3102 > > > > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > ------------------------------ > > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > End of Mspgcc-users Digest, Vol 45, Issue 4 > *******************************************
