[Mspgcc-users] cc430 support development
I'm working to update the mspgcc-based tool chain to support the CC430F5137 and related chips on TinyOS. Since the CC430 family doesn't have more than 32KB of memory, I'm ignoring the MSP430X branch. Similarly, I'm leaving aside the mspgcc4 fork, though I plan to go back to that. However, I am having to add some of the missing MSP430 5xx peripheral modules, including (first off) the power management module. Of course, I'll make the patches available to whoever wants them as soon as I'm convinced they produce working code. For now, I had a couple questions: * On mspgcc's sourceforge page, the git repository appears to be identical to the cvs repository except for some rearrangment. I'm based on the trunk cvs repository. Is that a problem? * Has anybody done significant work on 5xx peripherals that has not been checked into the CVS repository? I notice the MSP430X branch has outdated files in msp430-libc/include (e.g., msp430/timera.h), which is one of the reasons I'm not using it. * If there's a gatekeeper or other developers active in this area who would like to coordinate efforts, please let me know. * Also, if anybody's had any luck with gdb talking to the MSP-FET430UIF with TI's firmware revision 20401004 I'd appreciate some pointers. Right now, neither mspdebug nor fetproxy seem to know the right dialect, and as I understand it msp430-gdbproxy is a non-starter for newer chips on Linux. Any other suggestions to help speed this to success, including a pointer to a pre-existing solution, would be most welcome. Peter
Re: [Mspgcc-users] mspgcc repository
I also could not find anything saying which was canonical, but I have found the Bazaar repository on SourceForge to incorporate material from the mspgcc4 fork and from the msp430x branch of CVS. I'm using it as the basis of the CC430 support. (I see I mistakenly said git in my post where I meant bazaar; sorry for the confusion.) The Bazaar version has mspgcc-core/buildgcc.sh which works fine if you comment out the hard-coded CC=gcc-3.4 at the top and select gcc 3.2.3 instead of the default (I have not had success with gcc 4.3.4) . packaging-standard/buildmspgcc.sh appears to be outdated. Users of the CVS repository should be aware that the name of the overwrite directory for GCC 3.2.3 has been corrected to be gcc-3.2 in Bazaar, from the mistaken gcc-3.3 it is in CVS. Sorry, can't help with windows; my focus at the moment is Linux. Peter On Thu, Jan 7, 2010 at 2:02 PM, Bragg, Nate nate.br...@adb-air.com wrote: Hello, In trying to learn more about the mspgcc project (because I would prefer an open alternative to the Quadravox compiler I was suggested), I stumbled across this list. On the mspgcc homepage and wiki, it suggests retrieving the source from CVS - but the bazaar repository has more recent commits, and in the mailing list archives, it's been said that the project is using git. Could someone clarify which repository I should be getting mspgcc from? (and if it is git, where it is? I couldn't seem to find it). While I'm at it, if I wanted to do MSP-430 development in windows, would I need the binary installer, or is it preferred to compile mspgcc from the source? Sorry for all of the questions, I'm just a little confused. Regards, Nate Bragg Software Engineer ADB Airfield Solutions 977 Gahanna Parkway Columbus, OH 43230 Office: 614-573-8282 Fax: 614-573-8382 E-mail: nate.br...@adb-air.commailto:nate.br...@adb-air.com Web Site: www.adb-airfieldsolutions.com http://www.adb-airfieldsolutions.com/ Notice: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, replication or distribution of it is strictly prohibited. Please inform sender immediately and destroy the original transmittal. Thank you for your cooperation. P Please consider the environmental impact before printing this e-mail -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] CC430 support patches available
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 SourceForgehttp://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 mspgcc-us...@lists.sourceforge.net. 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 msp...@grossibaer.de, including new support for: - CRC16 - Power Management Module * Additional MSP430-5xx/CC430 module support from Peter Bigot p...@peoplepowerco.com, 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.
[Mspgcc-users] Updated CC430 support
I've updated the CC430 bazaar repository hosted on the OSHANhttp://sourceforge.net/projects/oshan/project page with these enhancements below. How can I help get these merged into a single MSPGCC repository? - Define __cc430x613x, __cc430x513x, __cc430x612x per TI headers to control feature selection - Add __MSP430_HAS_foo__ defines to match TI headers - Add REF, RTC, LCD_B, ADC12plus, COMP_B modules - Add script to help generate header files from portions of TI headers - Correct problem with 20-bit declarations on MSP430X2 - Add alternative DMA include file msp430/dmax.h for module-based systems Peter
Re: [Mspgcc-users] Using GCC for EZ430
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 milind.gu...@gmail.comwrote: 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] CC430 support patches available
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 p...@peoplepowerco.com 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 SourceForgehttp://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 mspgcc-us...@lists.sourceforge.net. 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 msp...@grossibaer.de , including new support for: - CRC16 - Power Management Module * Additional MSP430-5xx/CC430 module support from Peter Bigot p...@peoplepowerco.com, 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.
Re: [Mspgcc-users] support for msp430F5437
mspgcc4 in conjunction with the updated msp430-libc that extends the peripheral support for MSP430XV2 chips should be able to handle this chip using the -mmcu=msp430x5437 MCU flag Peter On Wed, Feb 24, 2010 at 9:07 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: Hi all! I have a new project that I'm working on using the TI MSP430F5437. I am trying to determine if there is an existing generic MSP430 MCU flag that I can use or if support for any of the 54xx series has been added yet. I saw the addNewDevice page in the FAQ. If I go that route how do I submit it for inclusion in the repository? If you are interested here is a description of this series of MCU... MSP430F5418 http://focus.ti.com/docs/prod/folders/print/msp430f5418.html http://focus.ti.com/docs/prod/folders/print/msp430f5418.html MSP430F5419 http://focus.ti.com/docs/prod/folders/print/msp430f5419.html http://focus.ti.com/docs/prod/folders/print/msp430f5419.html MSP430F5435 http://focus.ti.com/docs/prod/folders/print/msp430f5435.html http://focus.ti.com/docs/prod/folders/print/msp430f5435.html MSP430F5436 http://focus.ti.com/docs/prod/folders/print/msp430f5436.html http://focus.ti.com/docs/prod/folders/print/msp430f5436.html MSP430F5437 MSP430F5438 http://focus.ti.com/docs/prod/folders/print/msp430f5438.html http://focus.ti.com/docs/prod/folders/print/msp430f5438.html Frequency(MHz) 18 18 18 18 18 18 Flash 128 KB 128 KB 192 KB 192 KB 256 KB 256 KB RAM 16 KB 16 KB 16 KB 16 KB 16 KB 16 KB GPIO67 87 67 87 67 87 Pin/Package 80LQFP 100LQFP 80LQFP 100LQFP 80LQFP 100LQFP ADC 12-bit SAR 12-bit SAR 12-bit SAR 12-bit SAR 12-bit SAR 12-bit SAR Other Integrated PeripheralsHardware Multiplier, Universal Clock System, RTC, DMA, 16ch ADC12, 4 USCI ModulesHardware Multiplier, Universal Clock System, RTC, DMA, 16ch ADC12, 4 USCI ModulesHardware Multiplier, Universal Clock System, RTC, DMA, 16ch ADC12, 2 USCI Modules Hardware Multiplier, Universal Clock System, RTC, DMA, 16ch ADC12, 4 USCI Modules Hardware Multiplier, Universal Clock System, RTC, DMA, 16ch ADC12, 4 USCI Modules Hardware Multiplier, Universal Clock System, RTC, DMA, 16ch ADC12, 4 USCI Modules End Equipment Optimized ZigBee/RF ZigBee/RF ZigBee/RF ZigBee/RF ZigBee/RF ZigBee/RF Interface 2 USCI_A (UART/LIN/IrDA/SPI),2 USCI_B (I2C/SPI) 4 USCI_A (UART/LIN/IrDA/SPI),4 USCI_B (I2C/SPI) 2 USCI_A (UART/LIN/IrDA/SPI),2 USCI_B (I2C/SPI)4 USCI (UART/IrDA/SPI/I2C)4 USCI_A (UART/LIN/IrDA/SPI),4 USCI_B (I2C/SPI) 4 USCI_A (UART/LIN/IrDA/SPI),4 USCI_B (I2C/SPI)4 USCI_A (UART/LIN/IrDA/SPI),4 USCI_B (I2C/SPI) Timers 1 16-bit (5CCR), 1 16-bit (3CCR), 1 16-bit (7CCR) 1 Watchdog, RTC 1 16-bit (5CCR), 1 16-bit (3CCR), 1 16-bit (7CCR) 1 Watchdog, RTC 1 16-bit (5CCR), 1 16-bit (3CCR), 1 16-bit (7CCR) 1 Watchdog, RTC 1 16-bit (5CCR), 1 16-bit (3CCR), 1 16-bit (7CCR) 1 Watchdog, RTC 1 16-bit (5CCR), 1 16-bit (3CCR), 1 16-bit (7CCR) 1 Watchdog, RTC 1 16-bit (5CCR), 1 16-bit (3CCR), 1 16-bit (7CCR) 1 Watchdog, RTC a* -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] support for msp430F5437
Heh. This is all happening in mspgcc CVS, mspgcc bazaar, mspgcc4 subversion, and msp430-libc git (under the OSHAN project). I'm pretty committed to a solid packaged solution, and at the moment the most receptive maintainers appear to be associated with mspgcc4. I'm working towards getting them to adopt enough pieces that they're a one-stop shop. For a quick experiment, try the 12/08 mspgcc version recommended by JMGross. If it works, you're done. It has the header fixes, but I don't think either of the other two patch sets. If it doesn't work, try checking out the latest version of mspgcc4 from subversion. I believe it has more of the CPUX and X2 instruction enhancements, and if you tell it to use the 201002* version of libc will have the header fixes. I've had little trouble building it on Fedora; a co-worker ran into some cryptic messages trying to build on Ubuntu, but I haven't found out what they were---it's probably some missing dependencies on the OS installation. A patch has been sent on to the mspgcc4 folks for integration that eliminates the need for project-specific multiply routines, and brings gcc's list of supported architectures more into line with binutils'. But it hasn't made it through the pipeline yet. Peter On Thu, Feb 25, 2010 at 2:21 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: I only have limited time for experimentation and possibly i can live with the 40KB limitation. To clarify would this limitation be 40KB*4 banks so 160KB total or actually only 40KB? Does the 02/18/2010 mspgcc4 release have all the patches you mentioned? It seems like the patches are * 430x/430x2 language extensions for increase flash size * header file fixes * 32-bit multiplication function uses wrong address for hardware multiplier Any central place I can look to understand the current limitations and workarounds? Are there multiple parallel efforts happening or is this all under the mspgcc4 (?) cvs? Switching to 5418/5419 is not an option since I already have hardware in hand a* JMGross wrote: The MSPGCC build from 12/08 already knows wo these 6 processors. I use it for some time now. This build, however, does not have support for the 430X language extension, so only the first 40K of flash are usable. There are brances of the MSPGCC wich support the 430X architecture, even based on GCC4.0 instead of 3.23, but these are still udner development and unless you want to experiment or even contribute to the compiler development, I don't really recommend them. (This might change soon as the development seems to make progress) As long as you use the 54xx devices rather for their improved hardware modules than for the additional flash, the older compiler from 12/08 does its job. Then the 5418/5419 are a really good choice and siginficantly cheaper than the 5438 type. You'l need, however, to download the vastly improved header files from the sourceforge CVS repository. Many additions have been mader after this compiler release. And, you'll need to fix the 32 bit multiplication function in gcclib, as it addresses the hardware multiplyer at the wrong address (you can fix this by including your own version in your project source code, I postet the code some weeks ago in this list) JMGross - Ursprüngliche Nachricht - Von: Anthony Asterisk An: mspgcc-users@lists.sourceforge.net Gesendet am: 25 Feb 2010 04:07:29 Betreff: [Mspgcc-users] support for msp430F5437 Hi all! I have a new project that I'm working on using the TI MSP430F5437. I am trying to determine if there is an existing generic MSP430 MCU flag that I can use or if support for any of the 54xx series has been added yet. I saw the addNewDevice page in the FAQ. If I go that route how do I submit it for inclusion in the repository? If you are interested here is a description of this series of MCU... -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net
Re: [Mspgcc-users] support for msp430F5437
That warning pre-dates my involvement, but I've assumed it was just a notice that untested code was being used (the X2 chips have more interrupts, so the address for the reset pointer changed). At this time, I consider it to be noise, and expect to remove it next time I'm working on msp430-libc. Interrupts per se do not require support for 20-bit addressing. Peter On Wed, Mar 3, 2010 at 4:47 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: I managed to build the mspgcc4 that Peter sent out. I've been working through various minor issues related to different macro names, but I'm not sure what is meant by this warning in signal.h... warning X2 ist da here is the code snippet #if defined(__MSP430X__) #define INTERRUPT_VECTOR_SLOTS 32 #define RESET_VECTOR62 #elif defined(__MSP430X2__) #warning X2 ist da #define INTERRUPT_VECTOR_SLOTS 64 #define RESET_VECTOR126 #else #define INTERRUPT_VECTOR_SLOTS 16 #define RESET_VECTOR30 #endif Does this means the interrupts will require X2 instructions and are they supported at this time? I'm using gcc 4.4.3 and binutils 2.2. I picked the 201002 version of libc. a* Gerald Lutter wrote: Am Freitag, 26. Februar 2010 schrieb kavaler: It looks like the patch is no longer available at the address in that posting so you may have to ask the poster where that patch is now. of course it is available, but at a different location: http://www.innoventis.de/downloads/mspgcc Best regards, Gerald -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] support for msp430F5437
There was some discussion about whether to include msp430/common.h; the pros are that the documentation says it should be included and people seem to expect it; the cons are that it defines certain things that aren't necessarily common, like the address of the watchdog timer (fixed) and the LPM bits that arguably belong in some other module (maybe pmm.h; I'm not convinced). I think it's safe to add it. For the 54xx chip, the correct includes are dmax.h (not dma.h) and gpio_5xxx.h (not gpio.h). Again history affects this; in both cases the architectural changes for MSP430XV2 were too great to risk breaking code that works just fine with the existing headers, so advanced chips need to include the correct version. The naming differences arise from different maintainers adding these features. See cc430_.h for what needs to be added for this family of chips. If you do both these mods, confirm that they work, and send me the patches, I'm willing to add them in the repository. I don't have a test environment for that chip, and am reluctant to make changes that haven't been verified by somebody. Peter On Mon, Mar 8, 2010 at 3:27 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: I noticed something in the msp430x54xx.h header file. It seems to be missing msp430/common.h. Also missing are dma.h and gpio.h, but perhaps those still need to be ported. Is it safe for me to add this locally until the header files are further developed? a* Hi JMGross wrote: First, the 5418/19 is 100% hardware compatible to the 5437/38. The _only_ difference is the Flash size (128 instead of 256kb). In the middle sits the 5435/36 with 192kb. Everything else is 100% identical, same hardware modules, same package, even the same silicon errata :) The only difference is the A series of these processors. The A types have some smaller differences like a separate reference voltage module which needs to be configured first before you can use the ADC12_A, or a _usable_ (fully CCCITT compatible, not bit-inverted) version of the CRC16 module. And of course lower power consumption and increased maximum clock. For a siginificantly higher price Th elimitation of the NON-X version of MSPGCC is that only the lower 64K of the address range are usable. The compiler does not know of the extended memory range commands and the existence of flash beyonf 64K. It is possible, however, to store data above 64K (the linker handles data explicitely put into FARTEXT segment) and access it with a hand-written assembly function. If you have large amounts of data but access it not too often, this might be a way to use the additional flash. Maybe even as a flash disk drive :) Also, you might place hand-written assembly functions (naked, no preample and such) in FARTEXT, calling them with your own calling macro (which uses CALLA opcode rather than CALL). But every code the compiler generates needs to be in lowe 64K (and even with the 430X instructions, at least ISRs still need to be in lower 64K as the interrupt vectors are only 16 bit) For the 32bit multiplication, it is sufficient to put a corrected function in your own project code. This will have preference over the ones in gcclib. You can even exchange the 64bit (software) multiplication function, so it uses the (way faster) 32 bit hardware multiplyer. But then there is no way to disable usage of the hardware multiplyer for 64 bit multiplication (in ISRs or globally), as the compiler always assumes it software. The inline code for 16x16 multiplication is generated correctly by the compiler. I have written some more explicit multiplication inline functions where the result is twice the size of the arguments and the MPY is used with highest effectiveness. Often you multiply two 16 bit values and need a 32 bit result. Using the standard functions (with the * operator) this is always done by promoting the 16 bit values to 32 bit and then do a 32x32 multiplication, discarding the upper 32 bit of the result (if you don't cast the 16 to 32 bit first, the multiplication is done 16x16 bit with 16 bit result and then extended to 32 bit!). Same for 32x32 to 64 bit. But the MPY already gives a 32 bit result for a 16x16 multiplication, so It is a LOT faster, but must be used with a function call rather than just using the * operator. Also, 32x32 bit is done by the compiler through a function call, while the 16x16=32 and 32x32=64 functions are inline and subject to optimisation. Another speed advantage. Note that these are partly limitations introduced by the C language spec itself (result of a single arithmetic operation is always the same size as its larger parameter). JMGross P.s.: you've alread found the central place for current limitations and workarounds. :) And, well, since I'm not a compiler programmer (I did write one once, but this was a lifetime ago), but need the 54xx processor and a working
Re: [Mspgcc-users] mspgcc4 usci.h error in definition of UCBxCTL0/1
Thanks; I'd fixed the issue for UCA, but neglected to do the same for UCB, and wasn't using that header by the time I validated UCB functionality. I'll fix usci.h in my variant msp430-libc, but you may be better off using usci_5xx.h, which gives up on trying to support everything in one file, instead trying to match the TI headers in using consistent register names across modules. There are several other headers where there's a 5xx-specific version that should be preferred. Peter On Mon, Mar 15, 2010 at 6:42 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: I found an error in the usci.h modification for the 5xxx series. The definitions for UCBxCTL0/1 are swapped. The UCAxCTL are ok. Here are the versions of the file I'm using: * 2009-11-20 - modifications by J.M.Gross msp...@grossibaer.de * - split definitions for 8/11port and 2/4 USCI CPUs * - added PMM module * * $Id: msp430x54xx.h,v 1.5 2009/06/04 21:55:18 cliechti Exp $ and * 2009-11-20 - modifications by J.M.Gross msp...@grossibaer.de * - split definitions for 8/11port and 2/4 USCI CPUs * - added PMM module * * $Id: msp430x54xx.h,v 1.5 2009/06/04 21:55:18 cliechti Exp $ Here is an example of the definitions #define UCA0CTL0_ __MSP430_USCI5_BASE_0__ + 0x01 // USCI control 0 (sic) sfrb(UCA0CTL0, UCA0CTL0_); #define UCA0CTL1_ __MSP430_USCI5_BASE_0__ + 0x00 // USCI control 1 (sic) sfrb(UCA0CTL1, UCA0CTL1_); #define UCB0CTL0_ __MSP430_USCI5_BASE_0__ + 0x20 // USCI synchronous control 0 sfrb(UCB0CTL0, UCB0CTL0_); #define UCB0CTL1_ __MSP430_USCI5_BASE_0__ + 0x21 // USCI synchronous control 1 sfrb(UCB0CTL1, UCB0CTL1_); #define UCA1CTL0_ __MSP430_USCI5_BASE_1__ + 0x01 // USCI control 0 (sic) sfrb(UCA1CTL0, UCA1CTL0_); #define UCA1CTL1_ __MSP430_USCI5_BASE_1__ + 0x00 // USCI control 1 (sic) sfrb(UCA1CTL1, UCA1CTL1_); #define UCB1CTL0_ __MSP430_USCI5_BASE_1__ + 0x20 // USCI synchronous control 0 sfrb(UCB1CTL0, UCB1CTL0_); #define UCB1CTL1_ __MSP430_USCI5_BASE_1__ + 0x21 // USCI sync Here is the complete patch: u...@instant-contiki:~/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3/msp430/include/msp430$ diff -crB usci.h.orig usci.h *** usci.h.orig2010-03-15 21:34:58.0 -0400 --- usci.h2010-03-15 21:36:32.0 -0400 *** *** 376,384 #define UCA0IV_H_ __MSP430_USCI5_BASE_0__ + 0x1F sfrb(UCA0IV_H, UCA0IV_H_); ! #define UCB0CTL0_ __MSP430_USCI5_BASE_0__ + 0x20 // USCI synchronous control 0 sfrb(UCB0CTL0, UCB0CTL0_); ! #define UCB0CTL1_ __MSP430_USCI5_BASE_0__ + 0x21 // USCI synchronous control 1 sfrb(UCB0CTL1, UCB0CTL1_); #define UCB0BR0___MSP430_USCI5_BASE_0__ + 0x26 // USCI synchronous bit rate 0 sfrb(UCB0BR0, UCB0BR0_); --- 376,384 #define UCA0IV_H_ __MSP430_USCI5_BASE_0__ + 0x1F sfrb(UCA0IV_H, UCA0IV_H_); ! #define UCB0CTL0_ __MSP430_USCI5_BASE_0__ + 0x21 // USCI synchronous control 0 sfrb(UCB0CTL0, UCB0CTL0_); ! #define UCB0CTL1_ __MSP430_USCI5_BASE_0__ + 0x20 // USCI synchronous control 1 sfrb(UCB0CTL1, UCB0CTL1_); #define UCB0BR0___MSP430_USCI5_BASE_0__ + 0x26 // USCI synchronous bit rate 0 sfrb(UCB0BR0, UCB0BR0_); *** *** 450,458 #define UCA1IV_H_ __MSP430_USCI5_BASE_1__ + 0x1F sfrb(UCA1IV_H, UCA1IV_H_); ! #define UCB1CTL0_ __MSP430_USCI5_BASE_1__ + 0x20 // USCI synchronous control 0 sfrb(UCB1CTL0, UCB1CTL0_); ! #define UCB1CTL1_ __MSP430_USCI5_BASE_1__ + 0x21 // USCI synchronous control 1 sfrb(UCB1CTL1, UCB1CTL1_); #define UCB1BR0___MSP430_USCI5_BASE_1__ + 0x26 // USCI synchronous bit rate 0 sfrb(UCB1BR0, UCB1BR0_); --- 450,458 #define UCA1IV_H_ __MSP430_USCI5_BASE_1__ + 0x1F sfrb(UCA1IV_H, UCA1IV_H_); ! #define UCB1CTL0_ __MSP430_USCI5_BASE_1__ + 0x21 // USCI synchronous control 0 sfrb(UCB1CTL0, UCB1CTL0_); ! #define UCB1CTL1_ __MSP430_USCI5_BASE_1__ + 0x20 // USCI synchronous control 1 sfrb(UCB1CTL1, UCB1CTL1_); #define UCB1BR0___MSP430_USCI5_BASE_1__ + 0x26 // USCI synchronous bit rate 0 sfrb(UCB1BR0, UCB1BR0_); *** *** 524,532 #define UCA2IV_H_ __MSP430_USCI5_BASE_2__ + 0x1F sfrb(UCA2IV_H, UCA2IV_H_); ! #define UCB2CTL0_ __MSP430_USCI5_BASE_2__ + 0x20 // USCI synchronous control 0 sfrb(UCB2CTL0, UCB2CTL0_); ! #define UCB2CTL1_ __MSP430_USCI5_BASE_2__ + 0x21 // USCI synchronous control 1 sfrb(UCB2CTL1, UCB2CTL1_); #define UCB2BR0___MSP430_USCI5_BASE_2__ + 0x26 // USCI synchronous bit rate 0 sfrb(UCB2BR0, UCB2BR0_); --- 524,532 #define UCA2IV_H_
Re: [Mspgcc-users] mspgcc4 usci.h error in definition of UCBxCTL0/1
Project GNU is not involved with maintaining any of the msp430-libc
variants. The changes have been integrated into the msp430-libc I maintain,
and should be part of the next mspgcc4 release.
I don't think what you describe is quite normal for interrupt handling. If
the function declaration has the appropriate attribute, e.g.:
__attribute__((interrupt(USCI_A0_VECTOR)))
void USCI_A0_ISR(void)
{
uint16_t iv = *(volatile uint16_t*)UCA0IV;
if (USCI_UCTXIFG == iv) {
UCA0TXBUF = *mp;
if (message_end == ++mp) {
mp = message;
}
}
}
and is in an object file that is part of the link command for the
executable, it should be linked in.
Peter
On Wed, Mar 17, 2010 at 1:08 PM, Anthony Asterisk
anthony.aster...@gmail.com wrote:
Will these patches being going into GCC cvs?
BTW, other than these minor header file issues I haven't had any major
issues with mspgcc4 on msp430F5437.
One small thing that snagged me...I had my interrupt routines in a file
by themselves. Since the interrupts were not called from any other code
that did not get linked to the final object file. Only by adding a
dummy routine that I called from main was I able to get the interrupts
to be linked in.
I'm guessing this is actually normal gcc behavior and not mspgcc4
specific, but just wanted to mention it.
a*
JMGross wrote:
Hi Anthony,
you're right. TI has messed-up the port register names (or the
positions). The first versions of the documentation listed them all in the
wrong order, later revisions corrected this for the UCAxCTLy but still had
them wrong
for the UCBxCTLy. This was when this header file was last revised. The
latest documentation is finally right and so will be usci.h after your patch
:)
I detected this myself while I was working on DMA support for SPI (and my
discovery that the DMA registers are 16 bit access only, depsite of the docs
defining _L and _H byte access subregisters, even made it into
this latest revision) and corrected my personal copy of the file, but I
didn't publish a patch yet. So credits go to you :)
JMGross
- Ursprüngliche Nachricht -
Von: Anthony Asterisk
An: mspgcc-users@lists.sourceforge.net; msp...@grossibaer.de;
p...@peoplepowerco.com
Gesendet am: 16 Mrz 2010 02:42:03
Betreff: mspgcc4 usci.h error in definition of UCBxCTL0/1
I found an error in the usci.h modification for the 5xxx series. The
definitions for UCBxCTL0/1 are swapped. The UCAxCTL are ok.
--
Download Intel#174; 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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Download Intel#174; 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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] bug in msp430 headers, involving svsctl and dcoctl
I'll merge this into my msp430-libc this weekend. I hope to get that moved onto the mspgcc4 project soon. Peter On Wed, Mar 31, 2010 at 2:13 AM, Eric Decker cire...@gmail.com wrote: We recently switched to the msp430f2618 from a msp430f1611 and on boot up I noticed that DCOCTL was getting zero'd. This occured when I set SVSCTL=0. On further investigation, I noticed that SVSCTL and DCOCTL were both being set to 0x56. I tracked this down to msp430/include/msp430x261x.h which includes msp430/svs.h but doesn't define __msp430_has_svs_at_0x55. This is an artifact of the evolution of the chips over time. Earlier chips (no DCO, FLL) had the SVS at 56. Those chips are in the x3 and x4 families. I've carefully researched this including looking at how the h/w on the 2618 works and the DCOCTL is at 56 and SVSCTL at 55. There is a typo in the User Guide (slau144e.pdf) for the MSP430x2xx Family. It says that both DCOCTL and SVSCTL are at 56. I've also looked at the data sheet for the MSP430F241x, MSP430F261x (msp430f2618.pdf) and it shows DCOCTL at 56 and SVSCTL at 55. This is also consistent with the x15xx and x161x processors which also have SVS and DCOs. A simple fix would be to add #define __msp430_has_svs_at_0x55 prior to the #include msp430/svs.h in msp430x241x.h, msp430x24x1.h, msp430x24x.h, and msp430x261x.h since these cpus all have svs and dco h/w. Who controls the upstream? How does one go about getting changes into the upstream? -- Eric B. Decker Senior (over 50 :-) Researcher
[Mspgcc-users] SRPMs for mspgcc4 available
I've posted SRPMs for the latest mspgcc4 (binutils 2.20 + gcc 4.4.3) and msp430-libc. See http://sourceforge.net/projects/mspgcc4/files/ These are based on the current Fedora RPM spec files, but have been updated for mspgcc4 support. I have not posted pre-built RPMs for any particular OS releases, so to use these today you need to have a basic familiarity with building RPMs from source release. That's as simple as: rpmbuild --rebuild msp430-binutils-2.20-1.r4.20100210.fc12.src.rpm rpmbuild --rebuild msp430-gcc-4.4.3-1.r4.20100210.fc12.src.rpm rpmbuild --rebuild msp430-libc-20100403-1.fc12.src.rpm if you have an RPM build area configured. See google, or (picking randomly) http://postfix.state-of-mind.de/patrick.koetter/smtpauth/building_RPMS_from_SRPMS.htmlfor basic instructions. These packages incorporate the 20100210 release of mspgcc4, plus a patch to support hardware multiply on more recent chips that has not yet been integrated into mspgcc4. An updated msp430-libc is also included. If somebody has already done this or something close for Debian support, and can point me to that, I'd love to be able to add those as well. In a couple weeks I'll be set up to provide pre-built rpms and debs for multiple Linux releases, though I'd prefer to have those hosted by Fedora and Ubuntu rather than put them on SourceForge. Peter
Re: [Mspgcc-users] SRPMs for mspgcc4 available
Perhaps you have some insight to this: is mspgcc (as opposed to mspgcc4) still alive? I wasn't been able to get an answer to the basic question of whether cvs or bazaar was the right repository to look at, so I've given up and am coordinating with the maintainers of the mspgcc4 project, which seems to be more current. Peter On Thu, Apr 8, 2010 at 7:55 AM, Adam Horden adamhor...@biological-hazard.net wrote: I maintain the Debian / Ubuntu builds and there are some releases on my Launchpad account. I have not had much time lately to pull out new builds, but they are based on mpsgcc4 and binutils 2.19. Some work still needs to be done and after I have finished with University this year I will tidy up the packages some more and finish up my automatic building system for building debian packages from the mspgcc version control resporatory depending on if CVS is still been used or if we are making the jump over to Bazaar. There here: https://launchpad.net/~adamhorden/+archive/msp430https://launchpad.net/%7Eadamhorden/+archive/msp430 They need respining for Ubuntu Lucid and I hope to get this done as soon as possible. Adam On 5 April 2010 18:13, Peter Bigot p...@peoplepowerco.com wrote: I've posted SRPMs for the latest mspgcc4 (binutils 2.20 + gcc 4.4.3) and msp430-libc. See http://sourceforge.net/projects/mspgcc4/files/ These are based on the current Fedora RPM spec files, but have been updated for mspgcc4 support. I have not posted pre-built RPMs for any particular OS releases, so to use these today you need to have a basic familiarity with building RPMs from source release. That's as simple as: rpmbuild --rebuild msp430-binutils-2.20-1.r4.20100210.fc12.src.rpm rpmbuild --rebuild msp430-gcc-4.4.3-1.r4.20100210.fc12.src.rpm rpmbuild --rebuild msp430-libc-20100403-1.fc12.src.rpm if you have an RPM build area configured. See google, or (picking randomly) http://postfix.state-of-mind.de/patrick.koetter/smtpauth/building_RPMS_from_SRPMS.htmlfor basic instructions. These packages incorporate the 20100210 release of mspgcc4, plus a patch to support hardware multiply on more recent chips that has not yet been integrated into mspgcc4. An updated msp430-libc is also included. If somebody has already done this or something close for Debian support, and can point me to that, I'd love to be able to add those as well. In a couple weeks I'll be set up to provide pre-built rpms and debs for multiple Linux releases, though I'd prefer to have those hosted by Fedora and Ubuntu rather than put them on SourceForge. Peter -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] sscanf for msp430-gcc
Closest useful functionality may be strtoul(3), which is present (I haven't personally tested it). Peter On Mon, Apr 19, 2010 at 6:13 AM, Balbir Thomas bal...@hvpd.co.uk wrote: Hi, I am trying to port some software to msp430-gcc. I think the code was originally written for IAR (not sure). The original author used sscanf to extract unsigned short ints (%hu) from a string buffer. Is there an equivalent libc or other function call in msp430-gcc. regards b thomas -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] sscanf for msp430-gcc
If you can duplicate that with mspgcc4 please let me know or file a ticket on that project and I'll see it gets fixed. Peter On Mon, Apr 19, 2010 at 7:09 AM, Michiel Konstapel m.konsta...@sownet.nlwrote: -Original Message- From: Peter Bigot [mailto:p...@peoplepowerco.com] Sent: maandag 19 april 2010 14:02 To: GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] sscanf for msp430-gcc Closest useful functionality may be strtoul(3), which is present (I haven't personally tested it). I have, and it works. However, I did encounter breakage with one of the newer compiler builds, apparently because it uses register variables. As a workaround, I made a copy with normal variable declarations, which works fine. Michiel -- Download Intel#174; 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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] multiply with long int variables broken on msp430f5437
The patch is too big for this mailing list. I've uploaded a copy to: http://sourceforge.net/projects/mspgcc4/files/Patches/msp430-r4.20100210-chipcat.patch It's also available within the SRPM. Peter On Tue, Apr 27, 2010 at 6:06 PM, Peter Bigot p...@peoplepowerco.com wrote: Yes, it is probably due to hardware multiply. I can replicate the problem on an older install, but it's fixed with one built from the SRPMs I posted which include a patch for hardware multiply. I haven't had time to integrate that with the mainline developers; a copy is attached. Peter On Tue, Apr 27, 2010 at 5:46 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: OH BTW, this is with mspgcc4 msp430-gcc -v Using built-in specs. Target: msp430 Configured with: /home/user/mspgcc4/build/gcc-4.4.3-build/../gcc-4.4.3/configure --prefix=/home/user/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3 --target=msp430 --enable-languages=c,c++ --with-pkgversion=MSPGCC4_r4-20100210 : (reconfigured) /home/user/mspgcc4/build/gcc-4.4.3-build/../gcc-4.4.3/configure --prefix=/home/user/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3 --target=msp430 --enable-languages=c,c++ --with-pkgversion=MSPGCC4_r4-20100210 : (reconfigured) /home/user/mspgcc4/build/gcc-4.4.3-build/../gcc-4.4.3/configure --prefix=/home/user/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3 --target=msp430 --enable-languages=c,c++ --with-pkgversion=MSPGCC4_r4-20100210 Thread model: single gcc version 4.4.3 (MSPGCC4_r4-20100210) AND msp430-libc-20100207 Anthony Asterisk wrote: I just tried to use strotl() on the msp430f5437. It failed and I tracked the problem down to a problem with multiply. Check this out: register unsigned long int tmp1 = i; unsigned long int tmp2 = i; long int tmp3 = i; int tmp4 = i; printf(i %lx tmp1 %lx tmp2 %lx tmp3 %lx tmp4 %x\n,i,tmp1,tmp2,tmp3,tmp4); tmp1 = tmp1 * base; tmp2 = tmp2 * base; tmp3 = tmp3 * base; tmp4 = tmp4 * base; printf(i %lx tmp1 %lx tmp2 %lx tmp3 %lx tmp4 %x\n,i,tmp1,tmp2,tmp3,tmp4); i 0 tmp1 0 tmp2 0 tmp3 0 tmp4 0 i 0 tmp1 3fff3fff tmp2 3fff3fff tmp3 3fff3fff tmp4 0 Any advice how to proceed with debugging this? Is this a problem with usage of hardwarde multiplier?
Re: [Mspgcc-users] multiply with long int variables broken on msp430f5437
Hmn. Roughly, assuming you have a mspgcc4 area that has the ports subdirectory, cd to it and run: patch -p1 msp430-r4.20100210-chipcat.patch patch is a pretty standard unix command that you should have on any Unix/Linux installation. The -p1 says to strip off one level of the path names from within the patch, which are in the diff lines like: diff --git a/ports/gcc-4.x/gcc/config/msp430/generate_chip_data.py b/ports/gcc-4.x/gcc/config/msp430/generate_chip_data.py Then do a build as normal. Make sure that the build process unpacks the gcc sources and applies the patches from the port directory. Peter On Tue, Apr 27, 2010 at 6:14 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: Thank you very much! a dumb question... how do I apply these patches (roughly)? Peter Bigot wrote: The patch is too big for this mailing list. I've uploaded a copy to: http://sourceforge.net/projects/mspgcc4/files/Patches/msp430-r4.20100210-chipcat.patch It's also available within the SRPM. Peter On Tue, Apr 27, 2010 at 6:06 PM, Peter Bigot p...@peoplepowerco.comwrote: Yes, it is probably due to hardware multiply. I can replicate the problem on an older install, but it's fixed with one built from the SRPMs I posted which include a patch for hardware multiply. I haven't had time to integrate that with the mainline developers; a copy is attached. Peter On Tue, Apr 27, 2010 at 5:46 PM, Anthony Asterisk anthony.aster...@gmail.com wrote: OH BTW, this is with mspgcc4 msp430-gcc -v Using built-in specs. Target: msp430 Configured with: /home/user/mspgcc4/build/gcc-4.4.3-build/../gcc-4.4.3/configure --prefix=/home/user/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3 --target=msp430 --enable-languages=c,c++ --with-pkgversion=MSPGCC4_r4-20100210 : (reconfigured) /home/user/mspgcc4/build/gcc-4.4.3-build/../gcc-4.4.3/configure --prefix=/home/user/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3 --target=msp430 --enable-languages=c,c++ --with-pkgversion=MSPGCC4_r4-20100210 : (reconfigured) /home/user/mspgcc4/build/gcc-4.4.3-build/../gcc-4.4.3/configure --prefix=/home/user/contiki-2.x/platform/castlerock/tools/msp430-gcc-4.4.3 --target=msp430 --enable-languages=c,c++ --with-pkgversion=MSPGCC4_r4-20100210 Thread model: single gcc version 4.4.3 (MSPGCC4_r4-20100210) AND msp430-libc-20100207 Anthony Asterisk wrote: I just tried to use strotl() on the msp430f5437. It failed and I tracked the problem down to a problem with multiply. Check this out: register unsigned long int tmp1 = i; unsigned long int tmp2 = i; long int tmp3 = i; int tmp4 = i; printf(i %lx tmp1 %lx tmp2 %lx tmp3 %lx tmp4 %x\n,i,tmp1,tmp2,tmp3,tmp4); tmp1 = tmp1 * base; tmp2 = tmp2 * base; tmp3 = tmp3 * base; tmp4 = tmp4 * base; printf(i %lx tmp1 %lx tmp2 %lx tmp3 %lx tmp4 %x\n,i,tmp1,tmp2,tmp3,tmp4); i 0 tmp1 0 tmp2 0 tmp3 0 tmp4 0 i 0 tmp1 3fff3fff tmp2 3fff3fff tmp3 3fff3fff tmp4 0 Any advice how to proceed with debugging this? Is this a problem with usage of hardwarde multiplier?
Re: [Mspgcc-users] Cannot compile TI's MSP430F21x2 examples with mspgcc
GCC does not use #pragma directives; they use function attributes instead.
The syntax for marking an interrupt routine is:
// Timer A0 interrupt service routine
// #pragma vector=TIMER1_A0_VECTOR
// __interrupt
__attribute__((interrupt(TIMER1_A0_VECTOR)))
void TIMER1_A0_ISR(void)
{
Beyond changing that, and removing some of the intrinsics that do not
currently exist in mspgcc, the TI examples should work with it.
Peter
On Mon, May 24, 2010 at 6:12 AM, Andres Vahter andres.vah...@gmail.comwrote:
Hi,
I cannot compile TI's MSP430F21x2 examples with mspgcc.
It gives me following error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘void’
* Ubuntu 10.04
* I downloaded mspgcc4 binary from:
http://sourceforge.net/projects/mspgcc4/files/GCC-4.4.2-GDB-7.0-20091124/20091124-msp430-gcc-4.4.2-gdb-7.0-insight-6.8.7z
* I unpacked it and copied to /opt dir
* Then I added following line to .bashrc file: export
PATH=$PATH:/opt/msp430-gcc-4.4.2/bin
Actually I'm not sure if I'm using right mspgcc because I have also
mspgcc-tinyos in my machine (
http://docs.tinyos.net/index.php/Installing_TinyOS_2.1) maybe that might
cause problems.
Source main.c:
//**
// MSP430F20x1 Demo - Comp_A, Output Reference Voltages on P1.1
//
// Description: Output Comparator_A reference levels on P1.1. Program will
// cycle through the on-chip comparator_A reference voltages with output
on
// P1.1. Normal mode is LPM0, TA0_ISR will interrupt LPM0.
// ACLK = n/a, MCLK = SMCLK = default DCO
//
//MSP430F20x1
// -
// /|\| XIN|-
// | | |
// --|RST XOUT|-
//| |
//| P1.1/CA1|-- Vref
//| |
//
// M. Buccini / L. Westlund
// Texas Instruments Inc.
// December 2005
// Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.40A
//**
#include msp430x20x1.h
void delay(void); // Software delay
void main (void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
CACTL2 = P2CA4; // CA1/P1.1 = +comp
CCTL0 = CCIE; // CCR0 interrupt enabled
TACTL = TASSEL_2 + ID_3 + MC_2; // SMCLK/8, cont-mode
_EINT(); // enable interrupts
while (1) // Loop
{
CACTL1 = 0x00; // No reference voltage
_BIS_SR(LPM0_bits); // Enter LPM0
CACTL1 = CAREF0 + CAON; // 0.25*Vcc, Comp. on
_BIS_SR(LPM0_bits); // Enter LPM0
CACTL1 = CAREF1 + CAON; // 0.5*Vcc, Comp. on
_BIS_SR(LPM0_bits); // Enter LPM0
CACTL1 = CAREF1 + CAREF0 + CAON;// 0.55V, Comp. on
_BIS_SR(LPM0_bits); // Enter LPM0
}
}
// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
_BIC_SR_IRQ(LPM0_bits); // Clear LPM0 bits from 0(SR)
}
makefile
# makfile configuration
NAME= leds
OBJECTS = main.o
CPU = msp430x2012
CFLAGS = -mmcu=${CPU} -O2 -Wall -g
#switch the compiler (for the internal make rules)
CC = msp430-gcc-4.4.2
.PHONY: all FORCE clean download download-jtag download-bsl dist
#all should be the first target. it's built when make is run without args
all: ${NAME}.elf ${NAME}.a43 ${NAME}.lst
#confgigure the next line if you want to use the serial download
download: download-jtag
#download: download-bsl
#additional rules for files
${NAME}.elf: ${OBJECTS}
${CC} -mmcu=${CPU} -o $@ ${OBJECTS}
${NAME}.a43: ${NAME}.elf
msp430-objcopy -O ihex $^ $@
${NAME}.lst: ${NAME}.elf
msp430-objdump -dSt $^ $@
download-jtag: all
msp430-jtag -e ${NAME}.elf
download-bsl: all
msp430-bsl -e ${NAME}.elf
clean:
rm -f ${NAME}.elf ${NAME}.a43 ${NAME}.lst ${OBJECTS}
#backup archive
dist:
tar czf dist.tgz *.c *.h *.txt makefile
#dummy target as dependecy if something has to be build everytime
FORCE:
#project dependencies
main.o: main.c
If I'm changing CC = msp430-gcc-4.4.2 to CC=msp430-gcc then i got following
error:
msp430-gcc -mmcu=msp430x2012 -O2 -Wall -g -c -o main.o main.c
main.c:32: warning: return type of `main' is not `int'
main.c:53: warning: ignoring #pragma vector
main.c:54: syntax error before void
main.c: In function `Timer_A':
main.c:56: warning: concatenation of string literals with __FUNCTION__ is
deprecated
make: *** [main.o] Error 1
Do I have to change orginal TI example code to get it compile?
Is makefile OK?
Is there something wrong
Re: [Mspgcc-users] Cannot compile TI's MSP430F21x2 examples with mspgcc
There's a header file signal.h that defines some macros like interrupt and
eint as helpers instead of using the underlying attribute declarations and
intrinsics. You can use either syntax.
Peter
On Mon, May 24, 2010 at 10:52 AM, Dan Bloomquist d...@lakeweb.net wrote:
Peter Bigot wrote:
__attribute__((interrupt(TIMER1_A0_VECTOR)))
void TIMER1_A0_ISR(void)
{...
Hi Peter,
Have things changed with the new compiler? I'm using mspgcc-20080619 and
the likes of:
interrupt ( TIMERA1_VECTOR ) my_name( void )
{...
is what I use.
Best, Dan.
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Cannot compile TI's MSP430F21x2 examples with mspgcc
The 2012 is supported in mspgcc4 in the trunk SVN development; a patch got
merged last week that unifies the supported chips from binutils through
gcc. A debian build from this version should be available eventually; it's
currently difficult to coordinate releases among all the people involved.
If your target is TinyOS, you may get a leg up by going to
http://www.openoshan.net and downloading the ISO for the Ubuntu 10.4-based
LiveCD that incorporates OSHAN support. This provides TinyOS 2.1.1 and a
version of mspgcc4 that has the extra patches. It's really intended for the
CC430 chip, and includes TinyOS extension for 5xx-family chips, but for
older chips you should have a stock TinyOS 2.1.1 environment.
Peter
On Tue, May 25, 2010 at 4:14 AM, Andres Vahter andres.vah...@gmail.comwrote:
Hi,
Now I'm facing another problem. My target MCU is MSP430x2012, but it isn't
in supported MCU list.
msp430-ld: unrecognised emulation mode: msp430x2012
Supported emulations: msp430x110 msp430x112 msp430x1101 msp430x
msp430x1121 msp430x1122 msp430x1132 msp430x122 msp430x123 msp430x1222
msp430x1232 msp430x133 msp430x135 msp430x1331 msp430x1351 msp430x147
msp430x148 msp430x149 msp430x155 msp430x156 msp430x157 msp430x167 msp430x168
msp430x169 msp430x1610 msp430x1611 msp430x1612 msp430x2101 msp430x2111
msp430x2121 msp430x2131 msp430x311 msp430x312 msp430x313 msp430x314
msp430x315 msp430x323 msp430x325 msp430x336 msp430x337 msp430x412 msp430x413
msp430x415 msp430x417 msp430xE423 msp430xE425 msp430xE427 msp430xW423
msp430xW425 msp430xW427 msp430xG437 msp430xG438 msp430xG439 msp430x435
msp430x436 msp430x437 msp430x447 msp430x448 msp430x449
Problem is that I have also TinyOS mspgcc version installed in /usr/bin/
But I also downloaded mspgcc4 binary from:
http://sourceforge.net/projects/mspgcc4/files/GCC-4.4.2-GDB-7.0-20 and
copied it to /opt/
I added to .bashrc: export PATH=$PATH:/opt/msp430-gcc-4.4.2/bin so
msp430-gcc is from /opt dir version, but other tools are executed from
/usr/bin and old msp430-ld does not support msp430x2012.
Should I copy new version instead of /opt to /usr or is there any neat
trick to maintain both versions. I'm not sure is this even necessary -
actually one version that suits for both is better.
There aren't any mspgcc4 .deb packages - are they coming in the future?
Andres
On 24.05.2010, at 17:58, Peter Bigot wrote:
There's a header file signal.h that defines some macros like interrupt
and
eint as helpers instead of using the underlying attribute declarations
and
intrinsics. You can use either syntax.
Peter
On Mon, May 24, 2010 at 10:52 AM, Dan Bloomquist d...@lakeweb.net
wrote:
Peter Bigot wrote:
__attribute__((interrupt(TIMER1_A0_VECTOR)))
void TIMER1_A0_ISR(void)
{...
Hi Peter,
Have things changed with the new compiler? I'm using mspgcc-20080619 and
the likes of:
interrupt ( TIMERA1_VECTOR ) my_name( void )
{...
is what I use.
Best, Dan.
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
(I speak here with reference to the binutils patches in the mspgcc4 repository. Not sure which release you're using.) Chip-specific constants like that are stored in ld/emulparams/msp430all.sh. It appears ones for INFO and BOOT were added for some (but not all) chips, but are never referenced. They probably should be used in ld/scripttempl/ elf32msp430.sc in place of the hard-coded constants. (And maybe elf32msp430_3.sc; not sure why that family merits its own script). Did you discover this by analysis, or can you provide a short shell sequence that generates an elf32 with content in these sections so I can verify before/after behavior on various chips? Below are sections from the ld manual; I don't know specifically why one would want to put data into a memory section but not write it to the chip. ``.bootloader'' Defines the bootloader portion of the ROM (if applicable). Any code in this section will be uploaded to the MPU. ``.infomem'' Defines an information memory section (if applicable). Any code in this section will be uploaded to the MPU. ``.infomemnobits'' This is the same as the `.infomem' section except that any code in this section will not be uploaded to the MPU. Peter On Thu, May 27, 2010 at 5:33 AM, Hans Nieuwenhuis vz...@xs4all.nl wrote: Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this? Thanks, Hans -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just like the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter On Thu, May 27, 2010 at 10:50 AM, JMGross msp...@grossibaer.de wrote: Indeed. When I started messing with the linker files for my bootloader project, I noticed it too, but forgot to report it. I use the 12/08 windows build of mspgcc3 (non-X) The differece between infomem and infomemnobits is that infomemnobits is dumped after relocating. Its contents are not put into the output file and not written to the MSP. So you can define variables placed there and won't cause an infomem write when flashing the chip. In addition, since the 54xx have the INFOA segment handled differently than the others, there should be separate sections. On CCE and IAR, all 4 INFO sections are separate rather than one huge section. And on some MSPs, INFOA contains unique calibration data and should be only usable on purpose and not by jsut placing something in infomem. JMGross - Ursprüngliche Nachricht - Von: Hans Nieuwenhuis An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 12:33:04 Betreff: [Mspgcc-users] Linker script for msp430x54xx Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this? -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc linking problems porting TI Sports Code to mspgcc
The IAR compiler specifically generates very tight code; some of the intrinsics (such as even_in_range) help it do so (while it's possible to create a function that has the same operational behavior as the intrinsic, the code generated for the intrinsic is likely to be smaller). It's quite possible that gcc can't shrink the TI code down to a size that will fit in the 32KB available on the CC430F6137. Try compiling with -Os if you aren't already. If that doesn't work, you'll have to remove functions until it fits. Peter On Tue, Jun 1, 2010 at 1:53 PM, Paul F. Sehorne p...@sehorne.org wrote: Having gotten past the compiling phase in my effort to port the TI Sports Watch code to mspgcc, I'm moving on to the linking phase. I'm getting the following error: c:\users\paul\documents\programming\texas_instruments\ez430\mspgcc4\bin\..\lib\gcc\msp430\4.4.3\..\..\..\..\bin\msp430-ld.exe: build/chronos.430 section `.text' will not fit in region `text' c:\users\paul\documents\programming\texas_instruments\ez430\mspgcc4\bin\..\lib\gcc\msp430\4.4.3\..\..\..\..\bin\msp430-ld.exe: section .vectors loaded at [ff80,] overlaps section .text loaded at [8000,00012bbd] c:\users\paul\documents\programming\texas_instruments\ez430\mspgcc4\bin\..\lib\gcc\msp430\4.4.3\..\..\..\..\bin\msp430-ld.exe: region `text' overflowed by 11324 bytes I don't really know where to start. The mspgcc docs are no help. I know that both IAR and CCS use a linker command file, but I don't know how to implement such in mspgcc. Anypointers are appreciated. Thanks, Paul -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
The patch for the basic problem (bad address for infomem on newer chips) has been submitted to mspgcc4. Once the moderator approves it it'll go in. In the meantime, it's integrated into the next branch of the git repository for mspgcc4. This patch also corrects the use of cc430x5123 which should have been cc430x5133; that affects both binutils and mspgcc4. I started work on splitting out infoa through infod, but stalled: there are 47 data sheets to check, and it was only after the first pass through them that I realized that some chips with a 256b info section split it into two 128-byte chunks, and some into four 64-byte chunks. I need to revisit this, and verify that nobits actually does what it's supposed to, before that can be fixed. I expect infomem to be an alias section that overlays the info* sections available on the chip. Peter On Fri, May 28, 2010 at 5:39 AM, JMGross msp...@grossibaer.de wrote: All MSPs have at least InfoA and InfoB, most have InfoA..InfoD. Many have calibration data on InfoA, the 1x series has not and the 5x series and others have the data in the TLV structure in a separate segment which is (normally) read-only (but maybe writable in an undeocumented way). This is the latest TI invention. Also, on the 5x series and some others, the InfoA segment has a separate write protection bit in the flash controller and is not erased by a mass erase if this bit is set. This protection would have been very useful for those devices with calibration data in InfoA, but there there is no protection adn the 5x series has no data to protect. And then TI has made another not-so-smart move, as this bit is toggled by writing a '1', so a read-modify-write of the register for setting a different bit, will write back this bit as '1' and disable protection, and subsequent changes will read it as '0' and write it as '0', leaving protection off, making it pretty useless as protection scheme. We should provide all, infoX, infoXnobits (what a telling name!) as well as infomem/infomemnobits. Maybe for those devices with protected InfoA, infomem should not include this area. Also, on some devices, such as the 54xxA series (not the ones without A) the bootloader sector is writable. It also contains a software flash fuse area which will disable JTAG access if not all ff or 00, but leave JTAG messaging still intact. No more fuse burning with overvoltage, and it is reversable by the running software. So more and different sections. I do not really understand how the infomemnobits works. On my linker scripts, its script code looks 100% identical to the infomem section. So how does the linker know not to put out code for one of them. I have no idea of the template script, so I don't know what to do and how, or not. JMGross - Ursprüngliche Nachricht - Von: Peter Bigot An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 18:25:39 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just lik= e the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc4 linking problems - relates to bug 5815 in mspgcc
I've been told before that the MSP430X patch set has never been integrated
into mspgcc4. That's on my list to get to, but it's probably between one
and four weeks out.
Peter
On Tue, Jun 1, 2010 at 10:36 PM, p...@sehorne.org wrote:
I am using mspgcc4.
The warning: internal error: unsupported relocation error are all
related to pointer to functions (in my case), details below.
I found mspgcc bug 5815 (fixed a few months ago). But it appears that
this bug also exists in MSPGCC4_r4-20100210.
menu.h
==
struct menu
{
// Pointer to direct function (start, stop etc)
void (*sx_function)(u8 line);
// Pointer to sub menu function (change settings, reset counter etc)
void (*mx_function)(u8 line);
// Pointer to display function
void (*display_function)(u8 line, u8 mode);
// Display update trigger
u8 (*display_update)(void);
// Pointer to next menu item
const struct menu *next;
};
menu.c
===
#define FUNCTION(function) function
const struct menu * ptrMenu_L1 = NULL;
const struct menu * ptrMenu_L2 = NULL;
const struct menu menu_L1_Time = // this is just one of several a linked
list
{
FUNCTION(sx_time), // direct function
FUNCTION(mx_time), // sub menu function
FUNCTION(display_time), // display function
FUNCTION(update_time), // new display data
menu_L1_Alarm,
};
main.c
===
void (*fptr_lcd_function_line1)(u8 line, u8 update);
// the errors originate in main.c with lines like the following
// from function init_global_variables
// both lines generate the error
ptrMenu_L1 = menu_L1_Time;
fptr_lcd_function_line1 = ptrMenu_L1-display_function;
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc4 linking problems - relates to bug 5815 in mspgcc
Good point; in fact, it's probably not related to MSP430X (relocation just signals that thought in my mind). Either way, it's on the queue (I've had a Chronos sitting on my desk for the last three months that I haven't had a chance to look at, so what you're doing could be very useful to me as well). The warning in signal.h is from a previous maintainer, and I just need to look again to confirm there's nothing wrong with what it's doing. Since it's been working fine since January, I don't have much concern. Peter On Fri, Jun 4, 2010 at 12:32 PM, Paul F. Sehorne p...@sehorne.org wrote: Thank you, Peter. I notice you refer to the linking problem as MSP430X. Are the linking problem and the warning issued in signal.h related? Thanks, Paul On 6/3/2010 9:16 AM, Peter Bigot wrote: I've been told before that the MSP430X patch set has never been integrated into mspgcc4. That's on my list to get to, but it's probably between one and four weeks out. Peter On Tue, Jun 1, 2010 at 10:36 PM,p...@sehorne.org wrote: I am using mspgcc4. The warning: internal error: unsupported relocation error are all related to pointer to functions (in my case), details below. I found mspgcc bug 5815 (fixed a few months ago). But it appears that this bug also exists in MSPGCC4_r4-20100210. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Beginner question: writing interrupt handlers?
But that file won't necessarily have the right values for the F2013. For
that chip, I suspect you want msp430x20x3.h. Without looking at the
datasheet, I'm reasonably sure the 2013 doesn't have an ADC12_PLUS or even
an ADC12.
Peter
On Fri, Jun 4, 2010 at 12:04 PM, Paul F. Sehorne p...@sehorne.org wrote:
You will find ADC12_VECTOR and other vectors listed in cc430_.h in
msp430/include in the MSPGCC4 directory structure.
Paul
On 6/4/2010 9:26 AM, Vic wrote:
Hi All.
I'm brand new to writing for the MSP430 - I've got hello world working,
and that's about it.
I'm trying to write an interrupt handler to catch the conversion event
from the ADC on my F2013. The mspgcc manual says that my handler should
be
of the form :-
interrupt (INTERRUPT_VECTOR) IntServiceRoutine(void)
{
/* Any normal C code */
}
...Which is all well and good, but what do I use for INTERRUPT_VECTOR ?
I've tried a number of things, resulting in compiler warnings of the form
:-
temp.c:219: warning: Interrupt vector 0x8f62d8d assigned to ISR `adc_isr'
is invalid.
Doubtless this also involves a header file issue - but I don't really
know
what I'm doing here. What should I be including for the F2013?
Thanks for your assistance, and sorry for the rather basic level of my
incompetence :-)
Vic.
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc linking problems porting TI Sports Code to mspgcc
If you will provide a complete standalone example that reproduces the problem I'll take a look at this. The fragments you posted before(menu.h, menu.c, main.c) aren't complete and I don't really have time to try to fill out the missing pieces. Best way would be to file it as a bug on the mspgcc4 sourceforge bug page and add the attachments there. A small example please; I don't want to deal with the whole Chronos SDK. Peter On Fri, Jun 11, 2010 at 7:46 AM, Paul F. Sehorne p...@sehorne.org wrote: Yesterday I installed mspgcc4 on a Ubuntu 9.10 Linux machine and copied my TI eZChronos Sports Watch project to the machine. Upon building the program I get the same error as when building on Windows 7. This is a showstopper for me. I cannot proceed with mspgcc4 as long as this problem exists. To reiterate one of my previous posts, the problem (in my case) has to do with pointers to functions. Both of the following two lines from TI Sports Watch main.c cause the error. ptrMenu_L1 =menu_L1_Time; fptr_lcd_function_line1 = ptrMenu_L1-display_function; TI's code makes extensive use of pointers to function for the many menus. I can see me writing code of my own without pointers to functions. Thus, this is a show stopper for mspgcc4 and me. And surely I am not the only one experiencing this problem. Paul On 6/1/2010 3:33 PM, Paul F. Sehorne wrote: C:\Users\Paul\cc16wBFJ.o: In function `display_update': main.c:(.text+0x108): warning: internal error: unsupported relocation error main.c:(.text+0x1ea): warning: internal error: unsupported relocation error C:\Users\Paul\cc16wBFJ.o: In function `wakeup_event': main.c:(.text+0x29a): warning: internal error: unsupported relocation error -- Paul Sehorne owned or managed Web Sites * Airport Homes http://airporthomes.org/ * Female Body Building http://bodybuilding.sehorne.net/ * Credit Repair http://creditrepair.sehorne.net/ * Personal Loans http://personalloans.sehorne.net/ * Shopping http://shop.sehorne.net/ * Hidden Valley Airpark http://hiddenvalleyairpark.org/ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc linking problems - Need Linker command file?
The information that TI encodes in their linker command file is built into the MSP430 support in binutils, and is installed in the lib/ldscripts directory installed with binutils. (Other parts of it are coded in the MSP430 include files.) While the relocation problem may be related to something in those scripts, you definitely have linker support for the CC430F6137. Peter On Mon, Jun 14, 2010 at 5:41 PM, p...@sehorne.org wrote: I do not have a linker command file for MSPGCC4. Could this be the source of my linking error warning: internal error: unsupported relocation error? I have read the MSPGCC docs and find no reference to a linker command file. If I need a linker command file will MSPGCC be able to consume the one provided by TI? If so, how do I feed it to MSPGCC? If I need a linker command file but MSPGCC cannot consume the one provided by TI, where do I find instructions on how to create one for MSPGCC? Thanks, Paul -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] memory input 0 is not directly addressable
The value of PORT1_VECTOR + VECTOR_OFFSET is an integer, which is not the
same as an addressable memory location. In gcc4, the parameter to a memory
reference has to be an lvalue.
Try something like:
asm(br %[add] :: [add] m (*(uint16_t*)(PORT1_VECTOR +
VECTOR_OFFSET)));
Peter
On Tue, Jun 15, 2010 at 5:35 PM, Mark Rages markra...@gmail.com wrote:
I'm writing a little bootloader and I am jumping from the interrupt
vector to the relocated interrupted vector with little functions like
this
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br 0xfde4 :: );
}
This compiles and works fine. But it is ugly and has a magic number
in the assembly string.
So I would like to parameterize it out of the way:
#define VECTOR_OFFSET (-512)
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br %[add] :: [add] m (PORT1_VECTOR + VECTOR_OFFSET));
}
but this gives me an error:
main.c: In function ‘PORT1SR’:
main.c:18: error: memory input 0 is not directly addressable
What does not directly addressable mean?
Regards,
Mark
markra...@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markra...@midwesttelecine.com
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] memory input 0 is not directly addressable
I think you don't get the error message because you use gcc3, and the
corresponding code in gcc3 (gcc/stmt.c:expand_asm_operands) only complains
if the value is used as an output. In gcc4
(gcc/gimplify.c:gimplify_asm_expr), the test is refined and an error
produced when the integer value is used as an input as well. Which is good,
if the original source generated undesired code under gcc3.
I had no problems duplicating the problem; PORT1_VECTOR was properly
defined.
Peter
On Thu, Jun 17, 2010 at 1:40 PM, JMGross msp...@grossibaer.de wrote:
Sure you're right.
But I wonder why he got an error while I don't.
I looked at the generated code and the compiler generated a constant
containing the value (PORT1_VECTOR-512), and the branch brances onto the
location pointed to by this constant.
Of course this isn't what was intended, but it produces no error on my
system. The compiler generates an lvalue. And since it is an input an dnot
an output parameter, the 'lvalue' may be constant too.
here's the example:
#define VECTOR_OFFSET (-512)
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br %[add] :: [add] m (PORT1_VECTOR + VECTOR_OFFSET));
}
1659 .stabs j:r(0,4),64,0,204,11
1660 .stabn 192,0,0,.LBB25-testThread3
1661 .stabn 224,0,0,.LBE25-testThread3
1662 .Lscope8:
1663 .stabs ,36,0,0,.Lscope8-testThread3
1664 .p2align 1,0
1665 .LC17:
1666 0840 5EFE .short -418
1667 .p2align 1,0
1668 .stabs PORT1SR:F(0,20),36,0,218,PORT1SR
1669 .global PORT1SR
1670 .global vector_ffde
1671 .type PORT1SR,@function
1672 /***
1673* Interrupt Service Routine `PORT1SR' at 0xffde
1674***/
1675 vector_ffde:
1676 PORT1SR:
215:ez3.c
216:ez3.c
217:ez3.c #define VECTOR_OFFSET (-512)
218:ez3.c interrupt (PORT1_VECTOR) __attribute((naked))
PORT1SR (void) {
1677 .stabn 68,0,218,.LM198-PORT1SR
1678 .LM198:
1679 /* prologue: naked */
1680 .L__FrameSize_PORT1SR=0x0
219:ez3.c asm(br %[add] :: [add] m (PORT1_VECTOR +
VECTOR_OFFSET));
1681 .stabn 68,0,219,.LM199-PORT1SR
1682 .LM199:
1683 /* #APP */
1684 0842 1042 br .LC17
220:ez3.c }
1685 .stabn 68,0,220,.LM200-PORT1SR
1686 .LM200:
1687 /* #NOAPP */
1688
1689 /* epilogue: naked */
1690 .Lfe10:
1691 .size PORT1SR,.Lfe10-PORT1SR
1692 /* End of function **/
Of course that's not what was wanted. Using the 'i' constraint instead of
the 'm' constraint had had the same result, just without the additional
memory constant:
1681 0840 1042 5EFEbr #llo(-418)
With your modification, the compiler generates
1681 0840 1042 5EFEbr -418
which is the intended result.
I still wonder why he got an error message. Maybe PORT1_VECTOR was unknown,
in addition to the wrong addressing mode/parameter type.
JMGross
- Ursprüngliche Nachricht -
Von: Peter Bigot
An: GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 16.Juni.2010 22:02:52
Betreff: Re: [Mspgcc-users] memory input 0 is not directly addressable
The value of PORT1_VECTOR + VECTOR_OFFSET is an integer, which is not the
same as an addressable memory location. In gcc4, the parameter to a memory
reference has to be an lvalue.
Try something like:
asm(br %[add] :: [add] m (*(uint16_t*)(PORT1_VECTOR +
VECTOR_OFFSET)));
Peter
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] GitHub eZChronos okay to flash
While this may have been the problem, be aware that there is an undocumented (AFAIK) chip erratum on the CC430. I had programmed some boards to immediately enter LPM5 on boot; at that point, I could no longer use the FET over JTAG. See the threads titled *Cannot access TI MSP Experimenters board * from this mailing list about three weeks ago for potentially related information. We were able to restore functionality using the BSL over a USB port on our development boards. I have not tried to diagnose this further. If you left the watch programmed and running and it put itself into LPM5 after some extended idle period, that may have been part of the problem. It's possible that there's something about the code generated by mspgcc vice IAR/CCS that makes it happen. Or it may have just been your Windows problem all along. Peter On Sun, Jun 20, 2010 at 9:17 AM, p...@sehorne.org wrote: It turns out there was never a problem with the build. I discovered later that I had a Windows 7 problem that prevented the BM Firmware Update Tool and also TI's BSL_Scripter tool from accessing the the USB FET. I've since rebooted my machine and have repeated flashed the watch with mspgcc4 project with not problems. Paul -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unused functions occupying unnecessary memory
One reason why keep it even if unreferenced may be the default even when optimizations are enabled is that these tools (binutils, gcc) are primarily used in environments that have far more capabilities, and couldn't care less if a few extra kilobytes are present in the image. If you work in Linux with dynamic libraries, which is the common case, it's easy to use dlopen to resolve symbols at runtime that are not referenced at link time, and invoke unreachable code that way. The simplest perspective is user provided it, so leave it alone. The user's supposed to know best; I don't want the software to be overly helpful unless I explicitly give it permission. Peter On Wed, Jun 23, 2010 at 10:07 AM, JMGross msp...@grossibaer.de wrote: Since 1) is the default, binary files may be unnecessary large by default. Yes. And that's what I don't understand: why is the special case (keep it even if not referenced and therefore unreachable) is the default and the default case (keep only what's used) requires extra treatment. Anyway, now that I know that it is so, I can live with it. So while I'm sorry alarming you unnecessarily, I'm quite happy that I did, as I gained some valuable insights from this discussion. And maybe others did too. After all this is a compiler users mailing list and not a compiler programmers list. :) JMGross -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Creating .lst files with C code
Excellent; thank you. With this help I've determined that the msp430 patches to gcc don't enable the check for dwarf2 support on that architecture; as a result the compiler won't generate the line information required for integrated listings. This is probably why another user has complained that gdb can't find file locations. I've verified that a patch to gcc's configure script changes the configuration so the proper symbols are defined. I'll do additional testing, see if there are other features that aren't being supported because of a similar problem, and get it into the mspgcc4 git repository and push the patch upstream to the primary mspgcc4 maintainers for release. It should be available for builds from the git repository by Friday morning; I can't speak to when it'll be available in svn or as pre-built packages. Peter On Thu, Jul 1, 2010 at 7:11 AM, Hans Nieuwenhuis vz...@xs4all.nl wrote: I noticed the missing C source in mspgcc4 too a while ago. There is a difference between mspgcc3 and mspgcc4 in this area. But it could also be the underlying binutils which cause this behaviour. Just tried to compile an ordinary X86 program using GCC 4.4.3 on Ubuntu with these options: CFLAGS += -Wa,-adhlns=$(subst $(suffix $),.lst,$) This one gives me listing with C source mixed. It looks like a mspgcc issue. Mspgcc4 has an additional -Xassembler arg option, but that one has the same behaviour. Regards, Hans On Thu, 1 Jul 2010 12:42:24 +0200 JMGross msp...@grossibaer.de wrote: I too use objdump to generate a complete project listing from the elf file. It has, however, some serious drawbacks. Not only that jumps and calls are not printed with their symbolic name, also the source code in the listing is sometimes (often) from a completely different file or from different lines of the same file. So it is virtually useless. I guess the problem is related to the fact that I do not compile into the source folder (but into a /bin subdir) and also compile code from a common folder. The .lst ifles directly generated by the compiler with the option -Wa,-ahlms=$(addprefix $(OBJDIR)/,$(notdir $(:.c=.lst))) is fine. Of course the compiler knows the correct source :) Yet I use mspgcc 3, not 4. JMGross On 2010-06-30, Diane Gagne drose.ga...@gmail.com wrote: I am in the process of moving from mspgcc 3.2.3 to mspgcc4, but I am having trouble with the creation of the .lst files. When my source is compiled with the 3.2.3 the list files have the C code printed in them along with the assembly. Using the same makefile, and compiling with the mspgcc4 the C code goes away which makes it harder to read. I realize that objdump will give me close to what I am looking for, but those files do not have the jumps listed. Is there a way to get the C code back, maybe a default option changed that I do not realize? -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] (no subject)
Certainly you'll need an updated header. It may also be necessary to update binutils and gcc; the 430x41x2 chips are not currently recognized as different from the 430x41x chips, and I haven't looked into the issue enough to estimate whether it's trivial or messy to fix this. You might be able to get away with just lying to the compiler, but that's not a good habit to get into. (Unrelated comment: For the last six months or so, I've been updating binutils, mspgcc, and msp430-libc to support new chips. I'm happy to keep doing this, but is there anybody out there from the group that did all the original work to get msp430 supported in open software that wants to be involved? Please let me know.) The header isn't a big issue: TI has graciously provided me with draft mspgcc-compatible headers generated from their internal chip databases, with an implied promise to feed me new ones as they update their product line and fix header bugs. The only hold-up on making it official is their need to nail down the text of the BSD-style license they want applied to the files. This would allow mspgcc to use exactly the same names, preprocessor directives, etc as both Code Composer and IAR's compiler, and remove much of the burden on the msp430-libc maintainer(s) of trying to transcribe stuff from 40+ datasheets. Source-level portability between compilers: what a concept. The gotcha is that the header file organization is very different, since they generate complete headers for each chip rather than try to pick relevant pieces from a common functional module header as msp430-libc currently does. I've also dragged my feet on integrating this because I know it'll break older code: the headers won't have the lower-case __msp430_have_* symbols, and they definitely won't have any of the structure definitions to overlay UART registers and the like. What I plan to do is add a build-time option to msp430-libc to select either the legacy or TI-provided headers. My initial tests indicate this has promise. Sounds like you could be a candidate to help test this new configuration. If so, and especially if you're comfortable building binutils, gcc, and msp430-libc individually and manually as patches are applied, please add a tracker ticket on the mspgcc4 project to add this support, including information on any time constraints you're working under (msp430 toolchain support isn't officially among my primary tasks). If anybody else has an interest in testing TI-provided headers with MSP430 software and gcc, please let me know. (BTW: The draft TI headers I have include USB support on the 55xx.) Peter 2010/7/2 Asser Lähdemäki likapyykkiavuodest...@hotmail.com Hello everyone, I'm involved in a project in which I intend to use msp430F4152. However, it seems that mspgcc currently does not support the msp430F41x2 devices though it supports msp430F4xx devices.. I was thinking that msp430F415 and msp430F4152 are not too much different( I need 2 USCIs, that's why msp430F415 won't do), I could probably write the header file even myself. But what about debugging, would it work? And is there something else to it except the header file? PS. Will there be support for the 55xx series with USB peripheral module in future? _ Uudessa IE8 selaimessa on uudet pikatoiminnot. http://www.microsoft.com/finland/windows/products/winfamily/ie/beta/default.mspx -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] (no subject)
Everything's up on the mspgcc4 project. I use git to manage things. See http://mspgcc4.git.sourceforge.net/git/gitweb-index.cgi Baseline mspgcc4 is maintained in subversion by some folks in the EU; I have several patches submitted to them but don't muck with their repository until they've approved the changes. Nonetheless, I feel what's in git is pretty stable, and the subversion repository has most of what's needed. mspgcc4's git repository has a branch next that's always the most solid version I have available. mspgcc4 incorporates patches to a couple versions of binutils. There's a git repository in which those patches are maintained in branches, to make it easier to update them. msp430-libc is also hosted in a git repository on mspgcc4. The mspgcc4 git repository incorporates some spec files for building RPMs, based on your work in fact, but the project owners weren't thrilled about adding distribution-specific stuff. I think that's the best way to help get the latest version into various distributions, but haven't pursued it. I'd love to get debian build infrastructure as well, but haven't been able to get the equivalent to a spec file: debian tools seem to require a lot more pieces. The guy who builds them for Ubuntu has said he'll do it through his launchpad setup, but prefers to wait until the subversion repository is updated. For the OSHAN TinyOS environment that People Power distributes, I do a very crude approach based on checkinstall. Peter On Fri, Jul 2, 2010 at 8:32 PM, Robert Spanton rspan...@zepler.net wrote: Hi Peter, On Fri, 2010-07-02 at 10:18 -0500, Peter Bigot wrote: Unrelated comment: For the last six months or so, I've been updating binutils, mspgcc, and msp430-libc to support new chips. Awesome. Have you put the code up anywhere public? Cheers, Rob -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] problems with atol()
I haven't, though http://old.nabble.com/430X-patch:-ldiv.S,-and-strtoul-problem-td27293374.htmldescribes a problem that might be related. My records indicate the patch for that is in the current msp430-libc release. Did you get mspgcc4 from deb package files somewhere, or building from either the subversion or the git repository from the mspgcc4 project? Can you replicate the problem in a small program that you can send me? Peter On Mon, Jul 19, 2010 at 6:45 PM, Todd Allen msp...@tangoalfa.com wrote: Hi, I just upgraded to Ubuntu 10.04, then switched from mspgcc to mspgcc4. I recompiled an existing project (CPU = msp430x2619) and got some new warnings about assigning uint8_t to char, which I fixed. But the MCU seems to reset every time atol() is called. I tried calling strtol() directly and it crashed as well. I'm working around the problem by calling a slightly modified version of atoi(), which works fine. Has anyone else encountered this? Todd -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] mspgcc4 new release and updated maintainer
mspgcc4 is a port of the mspgcc tool chain to the GCC 4.x series of compilers. It is available from SourceForge at http://sourceforge.net/projects/mspgcc4/ I've taken over primary responsibility for maintaining mspgcc4 and its associated patches to binutils, gcc, gdb, and the msp430-libc distribution. Thanks to Matthias Andree and Ivan Shcherbakov for their efforts and for consenting to the transition. The current best-available version for mspgcc4 is now hosted in the git repository at: git://mspgcc4.git.sourceforge.net/gitroot/mspgcc4/mspgcc4 Downstream packagers should track the master branch of this repository. People who don't want to use git may download tar files containing versioned releases from the sourceforge Files area in the mspgcc4 subdirectory. A goal for mspgcc4 is to simplify installation by delegating the packaging of complete systems to distributions, making it easier on end users who aren't really interested in building the system from scratch themselves. I would prefer to avoid building pre-packaged releases for installation on various platforms, so the default download will soon become the source release for the latest release. I'm soliciting community assistance in providing builds for specific distribution. I have confirmation of support from the Fedora packager (Rob Spanton). I would appreciate it if other packagers, expecially for Windows-based distributions (cygwin, mingw) and OSX, would contact me. To celebrate the transition, a new version of mspgcc4 has been pushed to the repository. This version uses gcc 4.4.4 and gdb 7.1 by default (older versions are still available). It also includes, as an option at build-time, the first msp430-libc release that is based on header files provided by Texas Instruments under a BSD license. This is a major step towards making mspgcc4 support the full line of TI chips, and to ensure compatibility with existing software developed using the IAR or Code Composer development environments. Please consider trying this. (Sorry, you currently can't have both libc versions installed at the same time.) Existing code that depends on register names, structures, and preprocessor symbols that are not compatible with TI's headers will not work, but I could get TinyOS to build with them with one small change so it's pretty close. You can use the presence of the __MSP430_TI_HEADERS__ preprocessor symbol to detect an msp430-libc installation that uses these headers. (Note: MSP430X support has not yet been integrated into mspgcc4. I expect to do this in the context of gcc 4.5.0 and simultaneous with a review of the msp430 architecture models in binutils, gcc, and gdb to make them more compatible with TI's chip families and to reduce the number of multilib variants required. If you use MSP430 chips with CPUX or CPUX2 support and would like to help test these updates, please let me know.) Bug reports may be filed on the SourceForge bug tracker at http://sourceforge.net/tracker/?group_id=277223atid=1177287. For now, please use this mailing list for general-interest support questions and discussion of how to improve the tool chain. Should users of the mspgcc toolchain prefer that mspgcc4 support move elsewhere, I'll set up a second mailing list, but would prefer that the MSP430 open source community not fragment any further. Peter
Re: [Mspgcc-users] question about volatile keyword
I think busy is a red herring here, since the compiler optimizes it away
completely. The bug is that it doesn't respect the sequence points in the
statement list. It improperly moves the bic.b before the read of P4IN even
though the writes to P4OUT and the read of P4IN are all volatile operations
separated by sequence points.
Offhand, I think it's a bug in mspgcc4. Marking busy volatile simply
changes the code enough to obscure the bug.
Sigh. If you'd be so kind as to file it on the mspgcc4 tracker site to
remind me, I'll take a look this weekend.
Peter
On Fri, Jul 30, 2010 at 12:33 PM, Todd Allen msp...@tangoalfa.com wrote:
sorry if this is a duplicate, problems with from address
I've got a device driver that I've been using for an HD44780 LCD display.
It's been working under mspgcc for quite a while, but it stopped working
when I upgraded to mspgcc4.
There's some code that polls the busy flag, which is on the DB7 pin.
Basically you bring the E pin high, read the busy flag, then bring the E
pin
low again. A simplified version of the code follows:
bool busy;
do {
P4OUT |= E_PIN;
busy = P4IN DB7_PIN;
P4OUT = ~E_PIN;
} while (busy);
There are some nops for timing as well, plus a bit of code so that it
doesn't wait forever, but that's the basic idea.
I finally discovered that the compiler had reordered things so that the E
pin was brought high, then low, then it checked the DB7 pin, which was too
late. (Just to confuse things, if I put a scope probe on this pin, the
capacitance slowed it down just enough to make it work occasionally.)
The solution of course was to use the volatile keyword for busy. My
question is this: If P4IN is already marked volatile, why would busy have
to be volatile too? The busy variable isn't really volatile anyway, it's
the input port that's volatile.
Anyone have any insight about this?
Todd
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc or mspgcc4 for a msp430f5529
I believe some people are having some success using mspgcc4 and compiling with the TI headers version of msp430-libc. There's a bug in the headers right now that means you should include the legacy header msp430x552x.h instead of the chip-specific one, and the compiler isn't aware of the 5529 so you'll have to provide it an option for a different 5xx family chip, such as -mmcu=msp430x5418. Patches for both these problems are in the works. msp430-libc as available on the mspgcc4 project should also work with mspgcc if you need to use the MSP430X support that's in that CVS branch. Peter On Wed, Aug 11, 2010 at 8:10 AM, Aurélien Gauducheau aurelien.gauduch...@gmail.com wrote: Hi, I try to load the OS on a Contiki msp430f5529 I would like to know if mspgcc or mspgcc4 support msp430f5529. If not, is there a procedure or a patch for that mspgcc or mspgcc4 support the msp430f5529? thanks you Best regards Aurélien -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Building MSPGCC from Source Code - The Build procedure
(a) For a ticketing approach, might be better to create tickets on the sourceforge project instead of emailing everybody with each one. Though I don't know if anybody's going to maintain the how-to for the existing mspgcc infrastructure; my preference is to leave packaging to downstream and just provide the patches. (b) Not sure what the last problem was; the failure to find msp430-ar? Probably you installed binutils in a directory that is not in your PATH. sudo can contribute to confusion there, since the path it uses is not the same as the path you've got in your main shell; contrast msp430-ar -v with sudo msp430-ar -v (c) You might be better off using mspgcc4 until we get the two projects back together. Run the buildgcc.pl script it comes with. Peter On Wed, Aug 11, 2010 at 5:43 PM, Errol errol.kow...@gmail.com wrote: Being a newbie to this, I wasn't sure if each problem should be treated as something unique, or part of the wider picture. I opted for the former, and more of a ticketing approach. Please accept my humblest apologies for erring on the wrong side. However, that said, the last (unanswered) problem has, in my opinion, little to do with typos, and the source code build, and more likely the compiler I'm using in my Ubuntu Jaunty installation. This one is the show stopper. Anyone got any ideas? - regards, Errol Kowald ^ Engenia Pty Ltd, 2 Clear St., Palmerston, ACT 2913, Australia pH:+612 6242 0351 ^ On Wed, 2010-08-11 at 16:00 -0400, John Porubek wrote: (hope no-one is too put-out by my pedantic nit picking) I've got no problems with the nit-picking, but I am a little put off by small changes to each subsequent Subject line so that each message shows up as the start of a new thread (instead of being properly nested as a single thread). Hope no one is too put off by my curmudgeonly response, John -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Updates to MSP430 toolchain: binutils
Thanks for your input. (Note: Detailed discussion of the mechanics of
reconciling mspgcc/mspgcc4/msp430x is intended to be held on mspgcc-devel.
Please subscribe to that list if you're specifically interested in this
topic.)
Re errata: to whatever extent binutils or mspgcc{3,4} already supports
chip-specific errata I'll have to retain that. To whatever extent I can
come up with a way to add support, I'll do so. But I expect this'll be an
on-demand sort of thing: having gotten away from the need to read every data
sheet to figure out where the flash sections start, I'm not going to start
reading every errata document to figure out what's broken on which revision
of which chip.
Names are TBD, but yes, I foresee something like:
-msp430=cpu (cpux, cpuxv2)
-mpy=none (mpy, mpy32)
if I choose to be cute and use the m from the machine-specific option as
part of the option name, at least within gcc. Gonna have to review prior
art to see what's the best solution.
I'm going to do what I can to delay resolving peripheral addresses to the
final link phase. Having control of the standard header files should make
that easier.
I'm very sympathetic to your views on watchdogs, and would like to make it
easier to control that function. However, a large portion of the MSPGCC
user community is completely ignorant of the presence of WDT because it's
always been automatically turned off for them. I'm just not willing to deal
with the fallout from changing the existing default behavior.
Peter
On Tue, Aug 10, 2010 at 5:48 AM, JMGross msp...@grossibaer.de wrote:
- Ursprüngliche Nachricht -
Von: Peter Bigot
Gesendet am: 10 Aug 2010 01:17:03
What I propose to do instead is reduce the machines to those required
reflect the chip CPU architecture (MSP430, MSP430X, MSP430XV2), and not
try
to indicate things like available peripherals and the like as distinct
machine types. The only other feature that affects generated code is
presence/absence of hardware multiply support (none, MPY, MPY32), and I
think that can be done without having to add another axis to the
architecture matrix.
This is AFAIK the only part that needs care, besides the X/XV2 thing.
Of course there are the errata which should be taken care of, or the
compiler
will possibly create code that will simply crash. This is mostly X/XV2
related
stuff (forbidden sequences of instruction, necessary NOPs, not doing some
PC/SP manipulations etc.
Unfortunately, this is machine dependent. SOmetimes it applies to whole
families or groups of processors, sometimes only single ones are affected.
I fear this could break the 'slim' concept you want to introduce.
There can be, however, basic support for yet unsupported machines by
supporting the base architecture and MPY through parameters or
generic machine types. This allows compiler/assembler support for new
processors. (of course, linker scripts and include files are necessary, but
these can be written by 'normal' people)
I propose that an unknown mmcu will recognize a -core and -mpy parameter
and use the generic machines if given (or throw an error or assume non-X no
MPY if not set). This way it would be compatible to the current mechanisms
of forking inside header files etc.
If this works, the guts of binutils (the assembler and linker) becomes
independent of specific chip details, except for the location of ld
sections
(RAM, ROM, etc) and the base address of a few peripherals. Since TI's
now
providing me with a table containing, for each chip, the necessary
addresses
all the way down to individual info sections, it should be much easier to
do
this; plus, I believe it can be done in a way that allows new chips to be
targeted without having to rebuild the toolchain.
Because of the silicon errata this can prove difficult to impossible.
Except there is a way to manually set errata flags.
But I don't know whether TI has a 'global' errata naming. I fear the
errata names are independent for each group of processors and same name
may mean different things for different processors.
Some of the questions that arise include:
*) Is it necessary to retain support for the existing machine definitions
in
binutils, at least to allow linking to legacy libraries that can't be
rebuilt?
I don't think existing libraries are a problem.
If they cannot be rebuilt, they'll work or not.
machine-dependent defines are already resolved during compilation.
All that's left is resolving the symbols and this is a
machine-independent process. Either they are provided in the
(properly) compiled project object files or they are missing and
linking is impossible.
Some special code (like the startup) depends on machine-dependent
information, but this is usually part of the linker scripts.
*) Can critical values like the address of the watchdog reset or multiply
peripheral registers be correctly resolved using separate compilation
Re: [Mspgcc-users] Updates to MSP430 toolchain: MSP430X
I'm not convinced that presence of a single far pointer requires that every address kick up to 32 bits. If near/far is maintained as an attribute on the symbol, as apparently IAR uses a __data20 qualifier, it should be possible to manage things properly. Whether GCC+binutils makes it reasonably easy to do this, I don't know yet, but it's certainly not a new problem. If a function address is qualified as near/far, adapting the CALL instruction to the right form at the time the executable is generated should be straightforward. Some email from Dmitry Diky to the binutils reflector back in the mid 2000s when MSP430X was first added implied the linker (as opposed to assembler) was already handling that sort of thing in some cases where PCREL jump instructions were selected based on the size of intervening instructions. Locating and updating the corresponding RET may be a bit trickier, though again this isn't a problem that only applies to the MSP430. Maybe this isn't doable, but I think it's worth putting some serious effort into trying. If putting printf format strings in far memory means doubling the size of every address in my application, I'm not sure I'm going to want to enable that feature. But for those who need it, the fallback will be distinct near and far models for code and data, independently, as currently done in the MSP430X branch. (BTW: Anybody know how to get ahold of Dmitry Diky? He's officially the maintainer of binutils for msp430, though I haven't been able to contact him at any known address and haven't seen anything from him in the archives since maybe 2006.) Peter On Wed, Aug 11, 2010 at 7:01 AM, JMGross msp...@grossibaer.de wrote: Von: Michiel Konstapel Gesendet am: 10 Aug 2010 14:40:06 Generally using 20 bit registers isn't advisable as it increases code size and execution times and only a fraction of the MSP users needs the additional code size. Many (inlcuding me) just need the higher speed, more ram or better peripherals. On the other hand, many (including me) are mainly interested in the extra flash and are happy to take the step BACK in RAM going from a 1611 to a 2418. It's faster doesn't help if you're stuck at but it doesn't fit :) Some do, some don't. Indeed, if you NEED the space, then you need it. My experience at e2e.ti.com is that many only think they need it while they actually need petter programming skills and more imagination :) And even if so, often putting the functions far is good enough. Constant data, too, would be nice, but I agree with the advantages of sticking to 16 bit data pointers (unless 20 bits are requested by a switch). The problem is that it affects code. If you use a single 20 bit pointer, then all code in the whole project needs to be written to support 20 it pointers. As it needs to save the registers as 32 bit on stack, (including ISRs), needs to deal with stack parameters differently etc. For bulk data, you can fall back to a manual loading routine. that's what I do with my dynamically loaded firmware update and for some constants. A hand-crafted 'getter' and 'setter' method. Those who are already using C++ objects won't notice the difference or the overhead :) Being able to automatically split code into both low and far memory would be great, but as far as I understand, is fairly impossible for ld. Yes, it's a rather complex task *) How much unhappiness would there be if the default compiler behavior was to support near-mode compilation, with far-mode for code and/or data as an option specified either by attributes in the source or compiler flags? I don't mind which becomes the default, if it's easy to (globally) change. The -mdata-64k and -mcode-64k flags of mspgcc3's MSP430X branch, or their inverse, would do the trick. But it is necessary to note the usage of these flags in the object file. You may not mix code compiled with or without a flag. It will result in erratric program behaviour. So my proposal is: far attribute for functions and constants (automatic for strings e.g. in printf), but for constants only if enabled with additional commandline switch. Then the command line switch would select a different, precompiled library with far data pointers? yes. If I understand correctly, the overhead for 20 bit code addresses is localized to the functions that use it (so libraries can be compiled once and will work either near or far), but 20 bit data pointers force that overhead on the whole program? Basically yes. 20bit program code needs to be called with 20bit CALLA instruction, but the calling function and all surroundings may be 16 bit completely except for the function call itself. ISRs work transparent (the missing 4 bits are automatically saved in an unused area of the status word) A problem are all library functions which take (callback) function pointers. As the pointers (and pointer variables) are 16 bit. If these
Re: [Mspgcc-users] Building MSPGCC from Source Code - The Build procedure
As noted in earlier email to this list, svn for mspgcc4 is left in its legacy state in support of the WASP project. Download either the release tarball of mspgcc4, or clone the git repository. (Sorry if there is still how-to documentation somewhere that implies otherwise. Somebody needs to take charge of new-user step-by-step instructions; my time is overcommitted on getting the two forks back into one. Again this is why I want downstream packaging: so y'all don't *have* to build this stuff yourselves.) The following is more than you need, but should add the packages required for building mspgcc. Peter apt-get install -y \ emacs build-essential checkinstall \ git git-core texinfo \ file patch perl python autoconf automake autotools-dev \ dh-make debhelper devscripts fakeroot gnupg xutils-dev \ lintian pbuilder patchutils \ ncurses-dev libz-dev tk8.4-dev On Thu, Aug 12, 2010 at 3:37 AM, Errol errol.kow...@gmail.com wrote: Thanks for your help Peter. I didn't realise that the root PATH would be different to the user PATH, so after trying to learn how to work around that, I took you advice, at (c), and tried building mspgcc4, from the procedure at http://mspgcc4.sourceforge.net/ What could go wrong? It's only 3 lines. :- ~$ svn checkout https://mspgcc4.svn.sourceforge.net/svnroot/mspgcc4 checked out revision 139 ~$ cd mspgcc4 ~/mspgcc4$ sh buildgcc.sh accepted all of the default choices started the build right now with the result :- Selected GCC 3.2.3 GDB version: 7.0.1 Insight version: 6.8-1 Target location: /opt/msp430-gcc-3.2.3 Binary package name: msp430-gcc-3.2.3_gdb_7.0.1.tar.bz2 - Do you want to start build right now? (y/n) [n] y Running sh do-binutils.sh /opt/msp430-gcc-3.2.3 2.20.1 http://ftp.uni-kl.de; build === makeinfo is missing from path, but required for the binutils build. Please install texinfo. Aborting. === sh do-binutils.sh /opt/msp430-gcc-4.4.3 2.20.1 http://ftp.uni-kl.de; build exited with status code 1. Failed to execute sh do-binutils.sh /opt/msp430-gcc-4.4.3 2.20.1 http://ftp.uni-kl.de; build at ./buildgcc.pl line 247, STDIN line 9. Where is makeinfo? What should PATH= ? What should the root PATH= ? Errol On Wed, 2010-08-11 at 18:08 -0500, Peter Bigot wrote: (a) For a ticketing approach, might be better to create tickets on the sourceforge project instead of emailing everybody with each one. Though I don't know if anybody's going to maintain the how-to for the existing mspgcc infrastructure; my preference is to leave packaging to downstream and just provide the patches. (b) Not sure what the last problem was; the failure to find msp430-ar? Probably you installed binutils in a directory that is not in your PATH. sudo can contribute to confusion there, since the path it uses is not the same as the path you've got in your main shell; contrast msp430-ar -v with sudo msp430-ar -v (c) You might be better off using mspgcc4 until we get the two projects back together. Run the buildgcc.pl script it comes with. Peter On Wed, Aug 11, 2010 at 5:43 PM, Errol errol.kow...@gmail.com wrote: Being a newbie to this, I wasn't sure if each problem should be treated as something unique, or part of the wider picture. I opted for the former, and more of a ticketing approach. Please accept my humblest apologies for erring on the wrong side. However, that said, the last (unanswered) problem has, in my opinion, little to do with typos, and the source code build, and more likely the compiler I'm using in my Ubuntu Jaunty installation. This one is the show stopper. Anyone got any ideas? - regards, Errol Kowald ^ Engenia Pty Ltd, 2 Clear St., Palmerston, ACT 2913, Australia pH:+612 6242 0351 ^ On Wed, 2010-08-11 at 16:00 -0400, John Porubek wrote: (hope no-one is too put-out by my pedantic nit picking) I've got no problems with the nit-picking, but I am a little put off by small changes to each subsequent Subject line so that each message shows up as the start of a new thread (instead of being properly nested as a single thread). Hope no one is too put off by my curmudgeonly response, John -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
I dislike the coupling between binutils and mspgcc that has gcc decoding section names and changing the flags on the sections it generates. Especially since with addition of infoa-infod we have six such sections that would need to be special-cased instead of two (.noinit is the other). It's cruel to the poor maintainer who's trying to figure out what's going on, and to any user who wants to create a similar section and can't see where the magic happens. What I propose to do is instead add an attribute like section but titled nobits which will change the .section pseudo-op in the generated assembly code to use @nobits instead of @progbits for whatever declaration it's attached to. I'll probably make any occurrence of: __attribute__((section(.infomemnobits))) equivalent to: __attribute__((section(.infomem),nobits)) which will be almost the same as what it does now. But the new sections for INFOA through INFOD will not have explicit nobits variants, and the .infomemnobits section will be deprecated. This approach should also eliminate the confusion that results if you use both sections in one application. Currently, the declarations are independent and therefore overlay each other. What'll happen with this change is, if you do that in one translation unit, you'll get an section type error from the compiler. If you do this across object files, the section will be initialized but the regions corresponding to nobits data will not be written. (That is, the object file will include space but no data for those bytes. Whatever actually programs the mcu may still wipe the entire flash block, but I can't do anything about that.) Comments? Peter On Thu, Jun 3, 2010 at 9:58 AM, Hans Nieuwenhuis vz...@xs4all.nl wrote: Cool! I'll check it out later. From what I have read in the GCC sources it will flag the infomemnobits section as belonging to SECTION_BSS and therefore will not emit any code to the linker if I understood correctly. I think the best strategy is to let GCC do the same for infomemnobits[AD]. Regards, Hans On Thu, 3 Jun 2010 09:15:34 -0500 Peter Bigot p...@peoplepowerco.com wrote: The patch for the basic problem (bad address for infomem on newer chips) has been submitted to mspgcc4. Once the moderator approves it it'll go in. In the meantime, it's integrated into the next branch of the git repository for mspgcc4. This patch also corrects the use of cc430x5123 which should have been cc430x5133; that affects both binutils and mspgcc4. I started work on splitting out infoa through infod, but stalled: there are 47 data sheets to check, and it was only after the first pass through them that I realized that some chips with a 256b info section split it into two 128-byte chunks, and some into four 64-byte chunks. I need to revisit this, and verify that nobits actually does what it's supposed to, before that can be fixed. I expect infomem to be an alias section that overlays the info* sections available on the chip. Peter On Fri, May 28, 2010 at 5:39 AM, JMGross msp...@grossibaer.de wrote: All MSPs have at least InfoA and InfoB, most have InfoA..InfoD. Many have calibration data on InfoA, the 1x series has not and the 5x series and others have the data in the TLV structure in a separate segment which is (normally) read-only (but maybe writable in an undeocumented way). This is the latest TI invention. Also, on the 5x series and some others, the InfoA segment has a separate write protection bit in the flash controller and is not erased by a mass erase if this bit is set. This protection would have been very useful for those devices with calibration data in InfoA, but there there is no protection adn the 5x series has no data to protect. And then TI has made another not-so-smart move, as this bit is toggled by writing a '1', so a read-modify-write of the register for setting a different bit, will write back this bit as '1' and disable protection, and subsequent changes will read it as '0' and write it as '0', leaving protection off, making it pretty useless as protection scheme. We should provide all, infoX, infoXnobits (what a telling name!) as well as infomem/infomemnobits. Maybe for those devices with protected InfoA, infomem should not include this area. Also, on some devices, such as the 54xxA series (not the ones without A) the bootloader sector is writable. It also contains a software flash fuse area which will disable JTAG access if not all ff or 00, but leave JTAG messaging still intact. No more fuse burning with overvoltage, and it is reversable by the running software. So more and different sections. I do not really understand how the infomemnobits works. On my linker scripts, its script code looks 100% identical to the infomem section. So how does the linker know not to put out code for one of them. I have no idea of the template script, so I don't know what to do and how
[Mspgcc-users] release 20100815 of mspgcc4+msp430-libc available
Download the source from from http://sourceforge.net/projects/mspgcc4/files/mspgcc4/mspgcc4-20100815.tar.bz2. Please continue to try the variant msp430-libc that uses Texas Instruments-provided headers: this is the way of the future. Sorry, no pre-built binaries. I'm still looking for downstream packagers for Ubuntu (especially) and any Windows variants. I've also dropped some of the patch files for older versions of gcc and gdb to reduce maintenance overhead. Most of the changes were to msp430-libc and are listed below. There was one compiler change, due to a bug in gcc itself; that's been filed upstream as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235 and the proposed fix from the upstream maintainers applied for mspgcc4 under gcc 4.4.3 and 4.4.4. Report problems here or on the mspgcc4 tracker at http://sourceforge.net/tracker/?group_id=277223atid=1177287 mspgcc4 is now in maintenance-only mode. Major updates, including support for gcc 4.5.x/4.6.x and integration of new chips, standardization on TI headers, and integrated MSP430X support will be done in the mspgcc project, and are being based directly off the upstream development repositories. The expectation is that the mspgcc4 project will be deprecated once the new capabilities are released under the mspgcc umbrella. Peter 20100815 - e46e0d6 SF 3006833: missing string.h prototypes - 7d17d09 SF 3043392: msp430xG439 does not include compa.h - b7d9fd8 SF 3037713: remove extra underscores from preprocessor symbol 20100815-ti - 5278dc2 Fix C++/header-id modifications for files that use upper-case chip identifiers - 8edaf13 Temporarily unconditionally define macros for CPUX. - 60022af Re-generate derived headers from munge.sed and 53243ef857 - 7bd9f39 Fix 3036130; comment the converter script
Re: [Mspgcc-users] MSPGCC4 (gcc-4.4.3) problems
The -T msp430x149.x option overrides the default linker script. Does
the one you're using provide definitions for those symbols?
Try eliminating that option; it shouldn't be necessary unless you're
doing something special.
Peter
On Tue, Aug 17, 2010 at 8:54 AM, Berndt Josef Wulf w...@ping.net.au wrote:
G'day,
Using the current SVN source tree, I've built mspgcc4 on NetBSD-5.0.2. The
building and installation process completed without any noticeable problems.
When compiling projects I'm getting the following error messages:
[...]
/usr/pkg/msp430-gcc-4.4.3/bin/msp430-gcc -O2 -s -mmcu=msp430x149 -Wall -
D__MSPGCC__ -Wl,-Map monitor.map -T msp430x149.x -o monitor command.o
monitor.o usart.o utilities.o version.o intrjump.o iojump.o lowflash.o
/usr/pkg/msp430-gcc-4.4.3/lib/gcc/msp430/4.4.3/msp2/libgcc.a(_copy_data.o): In
function `__do_copy_data':
(.init4+0x2): undefined reference to `__data_size'
/usr/pkg/msp430-gcc-4.4.3/lib/gcc/msp430/4.4.3/msp2/libgcc.a(_copy_data.o): In
function `__do_copy_data':
(.init4+0xc): undefined reference to `__data_load_start'
/usr/pkg/msp430-gcc-4.4.3/lib/gcc/msp430/4.4.3/msp2/libgcc.a(_clear_bss.o): In
function `__do_clear_bss':
(.init4+0x2): undefined reference to `__bss_size'
collect2: ld returned 1 exit status
gmake: *** [monitor] Error 1
This application compiled fine with an older version of MSPGCC (gcc-3.3.2 by
memory).
I've searched the mailing list archive and found a similar case in 2008 on OSX
and the solution was the application of the binutils patches. However, all
patches have been applied to the source tree.
MSPGCC was build using the buildgcc.sh script with the options gcc-4.4.3,
gdb-7.0.1, libc-20100430 and stripped executables.
The Makefile contains the following configuration lines:
CPU = msp430x149
CC = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-gcc
LD = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-ld
OBJCOPY = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-objcopy
OBJDUMP = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-objdump
CFLAGS += -O2 -s -mmcu=${CPU} -Wall -D__MSPGCC__
Has anyone else seen this and if so, what was the solution?
With many thanks in advance,
cheerio Berndt
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSPGCC4 (gcc-4.4.3) problems
The new linker script,
/usr/pkg/msp430-gcc-4.4.3/msp430/lib/ldscripts/msp430x149.x is empty and just
contains a header declaring
that it is the default linker script for normal executables.
That is the problem. The script should not be empty. Something went
wrong with the binutils build/install.
Rather than try to figure out what, given that the subversion
repository is no longer maintained, please try the 20100815 release
tar file. This is the default download featured on the mspgcc4
project page at http://sourceforge.net/projects/mspgcc4.
I would remove the svn repository access, and possibly update the
build instructions, but mspgcc4 is referenced by the WASP project who
originated it and until their project completes I can't make changes
to what they did without breaking their documentation.
Peter
cheerio Berndt
On 18/08/10 Peter Bigot wrote:
The -T msp430x149.x option overrides the default linker script. Does
the one you're using provide definitions for those symbols?
Try eliminating that option; it shouldn't be necessary unless you're
doing something special.
Peter
On Tue, Aug 17, 2010 at 8:54 AM, Berndt Josef Wulf w...@ping.net.au wrote:
G'day,
Using the current SVN source tree, I've built mspgcc4 on NetBSD-5.0.2. The
building and installation process completed without any noticeable
problems.
When compiling projects I'm getting the following error messages:
[...]
/usr/pkg/msp430-gcc-4.4.3/bin/msp430-gcc -O2 -s -mmcu=msp430x149 -Wall -
D__MSPGCC__ -Wl,-Map monitor.map -T msp430x149.x -o monitor command.o
monitor.o usart.o utilities.o version.o intrjump.o iojump.o lowflash.o
/usr/pkg/msp430-gcc-4.4.3/lib/gcc/msp430/4.4.3/msp2/libgcc.a(_copy_data.o):
In
function `__do_copy_data':
(.init4+0x2): undefined reference to `__data_size'
/usr/pkg/msp430-gcc-4.4.3/lib/gcc/msp430/4.4.3/msp2/libgcc.a(_copy_data.o):
In
function `__do_copy_data':
(.init4+0xc): undefined reference to `__data_load_start'
/usr/pkg/msp430-gcc-4.4.3/lib/gcc/msp430/4.4.3/msp2/libgcc.a(_clear_bss.o):
In
function `__do_clear_bss':
(.init4+0x2): undefined reference to `__bss_size'
collect2: ld returned 1 exit status
gmake: *** [monitor] Error 1
This application compiled fine with an older version of MSPGCC (gcc-3.3.2
by
memory).
I've searched the mailing list archive and found a similar case in 2008 on
OSX
and the solution was the application of the binutils patches. However, all
patches have been applied to the source tree.
MSPGCC was build using the buildgcc.sh script with the options gcc-4.4.3,
gdb-7.0.1, libc-20100430 and stripped executables.
The Makefile contains the following configuration lines:
CPU = msp430x149
CC = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-gcc
LD = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-ld
OBJCOPY = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-objcopy
OBJDUMP = /usr/pkg/msp430-gcc-4.4.3/bin/msp430-objdump
CFLAGS += -O2 -s -mmcu=${CPU} -Wall -D__MSPGCC__
Has anyone else seen this and if so, what was the solution?
With many thanks in advance,
cheerio Berndt
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc or mspgcc4 for a msp430f5529
That problem should be fixed in the 20100815 release of mspgcc4 and msp430-libc (again the ti version). Also with that version you should be able to include the correct header for the chip rather than the legacy one. You'll still have to lie about the mcu. Peter 2010/8/20 Frédéric Sureau frederic.sur...@gmail.com: Hi all, I tried to compile a flash the led example for the msp430f5529 using your method : include legacy header : msp430x552x.h using mmcu : msp430x5418 I encountered this error (on many lines) : /opt/msp430-gcc-4.4.4/lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x552x.h:1448: erreur: expected ‘)’ before numeric constant The problem seems to be on lines using the macro function const_sfrb or const_sfrw. When I search for these macro in iomacros.h there is no definition. For the moment I tried using sfrb instead, and the compilation is OK (I did not tried on target yet). Fred Le 19 août 2010 15:35, Frédéric Sureau frederic.sur...@gmail.com a écrit : -- Forwarded message -- From: Peter Bigot p...@peoplepowerco.com Date: 2010/8/11 Subject: Re: [Mspgcc-users] mspgcc or mspgcc4 for a msp430f5529 To: GCC for MSP430 - http://mspgcc.sf.net; mspgcc-users@lists.sourceforge.net I believe some people are having some success using mspgcc4 and compiling with the TI headers version of msp430-libc. There's a bug in the headers right now that means you should include the legacy header msp430x552x.h instead of the chip-specific one, and the compiler isn't aware of the 5529 so you'll have to provide it an option for a different 5xx family chip, such as -mmcu=msp430x5418. Patches for both these problems are in the works. msp430-libc as available on the mspgcc4 project should also work with mspgcc if you need to use the MSP430X support that's in that CVS branch. Peter On Wed, Aug 11, 2010 at 8:10 AM, Aurélien Gauducheau aurelien.gauduch...@gmail.com wrote: Hi, I try to load the OS on a Contiki msp430f5529 I would like to know if mspgcc or mspgcc4 support msp430f5529. If not, is there a procedure or a patch for that mspgcc or mspgcc4 support the msp430f5529? thanks you Best regards Aurélien -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Sorry; my suggestion was meant to trick the compiler into defining some relevant CPU and MPY flags, and work around an include file limitation. I'd neglected to look into the binutils issues. Unfortunately, there are no existing supported chips that match the layout of the 55xx chips. I can add the twenty-four chips in the 55xx sub-family to the existing mspgcc4 support list while continuing to rework the infrastructure so this won't be quite so painful in the future. Before I go through all that, are there other chips that people need added? Peter 2010/8/26 Alexandre Malo alexandre.m...@usherbrooke.ca Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l *ABS* __OP2L 04e2 l *ABS* __OP2H 04e4 l *ABS* __RES0 04e6 l *ABS* __RES1 04e8 l *ABS* __RES2 04ea l *ABS* __RES3 04ec l *ABS* __MPY32CTL0 0001 g .text _efartext 445e g .text _etext 4400 g .text __dtors_end 4400 g .text __ctors_start 4400 g F .text 005e main ff80 g .text _vectors_end 4400 g .text __dtors_start 4400 g .text __ctors_end 4400 g *ABS* __stack 2400 g .text _edata 2400 g .text _end -- Is there a formal way to add a new mmcu to the tools? I hack'd the patch and source and that may not be the right way hehe. Thanks for any queue! Alexandre Malo -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Those patches are generated by diffs from development repositories that include gcc/binutils/gdb, so it's generally easier to do them in that context. Someday those repositories will be available on SF so other folks can do it the easy way too; I'm still working out the maintainer infrastructure. (The wiki page you followed is right, it's just a really unpleasant process that encourages unintentional inconsistencies.) I can't say why the program doesn't work. Only suggestion is: are you using the TI-provided header for the 5529? The addresses of peripherals might not be right with the older msp430-libc sources. (I do not intend to back-port the non-TI msp430-libc to the new chips. If somebody wants to contribute and provide support for such a port, I'll undertake to add it, but I think the time would be better spent validating and improving the TI headers.) Peter 2010/8/26 Alexandre Malo alexandre.m...@usherbrooke.ca Thanks for the quick reply and the work you do! I guess you are better than I to do this. ps: I forgot to say in my mail that the mspgcc tools did compile and then my msp code, but it still does not execute. I found http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=AddingNewDeviceon mspgcc wiki. Thats what I tried to follow :) Thanks again and have a good day! Alex On 10-08-26 10:14 AM, Peter Bigot wrote: Sorry; my suggestion was meant to trick the compiler into defining some relevant CPU and MPY flags, and work around an include file limitation. I'd neglected to look into the binutils issues. Unfortunately, there are no existing supported chips that match the layout of the 55xx chips. I can add the twenty-four chips in the 55xx sub-family to the existing mspgcc4 support list while continuing to rework the infrastructure so this won't be quite so painful in the future. Before I go through all that, are there other chips that people need added? Peter 2010/8/26 Alexandre Maloalexandre.m...@usherbrooke.ca Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l *ABS* __OP2L 04e2 l *ABS* __OP2H 04e4 l *ABS* __RES0 04e6 l *ABS* __RES1 04e8 l *ABS* __RES2 04ea l *ABS* __RES3 04ec l *ABS* __MPY32CTL0 0001 g .text _efartext 445e g .text _etext
Re: [Mspgcc-users] Lastest version of mspgcc
You can download the latest source release of mspgcc4 (20100815, though there should be another later today) from http://sourceforge.net/projects/mspgcc4/. There's a MinGW.txt file in the root directory that may help with building, if you're not using cygwin. I don't have a good windows development environment, and personally want to stay out of the distribution business, so unless/until somebody volunteers to provide packaged versions the latest versions are only available in source form. Peter On Fri, Aug 27, 2010 at 9:44 AM, HardMaker hardma...@gmail.com wrote: Hi, I'm testing a litle example using the msp430f2132 and the compiler send a some error's in tlv.h Searching a solution a find a diferent version of this file (tlv.h) in the sourceforge of I have downloaded in the install package of the compiler. Where can I download the lastest working version of the mspgcc for win32? Thank's Sergio -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] release 20100829 of mspgcc4+msp430-libc (TI) available
New source releases for mspgcc4 are available. Download the source from from http://sourceforge.net/projects/mspgcc4/files/mspgcc4/mspgcc4-20100829.tar.bz2. mspgcc4 20100829 contains these changes: - Support for following chips in binutils and gcc: msp430x5510 msp430x5513 msp430x5514 msp430x5515 msp430x5517 msp430x5519 msp430x5521 msp430x5522 msp430x5524 msp430x5525 msp430x5526 msp430x5527 msp430x5528 msp430x5529 msp430x6638 Note: Only binutils-2.20.1 and gcc 4.4.4 have been tested. The new chip support is present and untested in binutils 2.20 and absent from 2.19. - Internal Compiler Error (SF 3055171) Legacy msp430-libc remains at 20100815: it did not change. Note: The new chips are not supported in legacy msp430-libc, though this remains the default for buildgcc.pl. TI-header msp430-libc updated to 20100829: - Support for following chips: msp430x5510 msp430x5513 msp430x5514 msp430x5515 msp430x5517 msp430x5519 msp430x5521 msp430x5522 msp430x5524 msp430x5525 msp430x5526 msp430x5527 msp430x5528 msp430x5529 msp430x6638 Please raise questions here or file bug reports on the mspgcc4 sourceforge project at http://sourceforge.net/projects/mspgcc4/. Peter
Re: [Mspgcc-users] Lastest version of mspgcc
msp430-objcopy -I elf32-little -O ihex main.exe main.hex msp430-objcopy --info tells you the supported formats. Peter On Mon, Aug 30, 2010 at 8:55 AM, HardMaker hardma...@gmail.com wrote: Very thank's Peter I can build the lastest version on linux without problem. But, I use bsl with ti txt binary format. How can convert from the gcc output to ti txt hex file format? Very thank's again. Sergio Peter Bigot wrote: You can download the latest source release of mspgcc4 (20100815, though there should be another later today) from http://sourceforge.net/projects/mspgcc4/. There's a MinGW.txt file in the root directory that may help with building, if you're not using cygwin. I don't have a good windows development environment, and personally want to stay out of the distribution business, so unless/until somebody volunteers to provide packaged versions the latest versions are only available in source form. Peter On Fri, Aug 27, 2010 at 9:44 AM, HardMaker hardma...@gmail.com wrote: Hi, I'm testing a litle example using the msp430f2132 and the compiler send a some error's in tlv.h Searching a solution a find a diferent version of this file (tlv.h) in the sourceforge of I have downloaded in the install package of the compiler. Where can I download the lastest working version of the mspgcc for win32? Thank's Sergio -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSPGCC and MSP430F5529
Your program builds for me using mspgcc4 release 20100829 built with
the TI header support. (Came out two days ago; this is the only
version that will support that chip. Good timing.)
msp430-gcc -mmcu=msp430x5529 q.c
Peter
On Tue, Aug 31, 2010 at 3:03 PM, Arturo Gurrola
mgurr...@gdl.cinvestav.mx wrote:
Has anyone tried to compile code with MSPGCC for MSP430F5529?
Is it compatible?
I'm getting some errors of undefined reference although I have all the
header files needed for it to compile (I'm still a newbie here, so there
might be something else wrong).
For example, I have this simple code (an example by TI):
#include msp430f5529
http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=msp430f5529.h
void main(void)
{
volatile unsigned int i;
WDTCTL = WDTPW+WDTHOLD; // Stop WDT
P1DIR |= BIT0; // P1.0 set as output
while(1) // continuous loop
{
P1OUT ^= BIT0; // XOR P1.0
for(i=5;i0;i--); // Delay
}
}
And I get these errors:
undefined reference to `WDTCTL'
undefined reference to `PADIR_L'
undefined reference to `PAOUT_L'
Note that P1OUT makes reference for PAOUT_L in MSP430f5529.h, but then it
doesn't find the reference for PAOUT_L inside that header, I don't know what
to do there.
What do you recommend?
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
Not a cygwin user, so I'm reaching here, but there may be a package libcurses-devel (or libncurses-devel) that you need in order to get the headers. This is generally the fix for this problem when it arises under Linux. Unless you're sure the curses.h you found matches the libncurses library, I do not recommend copying it into the gdb source area. You'll probably just find that there's another header that's missing too. Peter On Thu, Sep 2, 2010 at 12:52 PM, Arturo Gurrola mgurr...@gdl.cinvestav.mxwrote: Hello everyone, I'm installing MSPGCC4 through Cygwin on windows (command: perl buildgcc.pl). BinUtils, GCC and Libc have installed correctly so far. But then when it comes to GDB (command in the script: bash do-gdb.sh /cygdrive/c/mspgcc4/ 7.1 http://ftp.uni-kl.de; build gdb), and after Unpacking gdb... and a bunch of patching file ..., I get try184.c:1:20: error: curses.h: No such file or directory and then Note that you must have libcurses developer headers installed. Abort.. Now, I do have the package Libs (and a bunch of others) which contains some libncurses... files in my Cygwin installation. And I do have the file curses.h somewhere in my mspgcc4 directory. Should I install a specific package for Cygwin? Or should I copy curses.h to a specific directory? Thanks in advance. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
Go to http://www.elprotronic.com and download FET-Pro430. The Lite (free) version has done everything I needed. Use msp430-objcopy to convert the elf output from mspgcc to Intel hex and program with FET-Pro430. You may need to name the file something.hex to get FET-Pro430 to recognize it. Best solution I found prior to mspdebug working under Linux. Peter On Thu, Sep 2, 2010 at 1:38 PM, Mark J. Blair n...@nf6x.net wrote: On Sep 2, 2010, at 10:52 AM, Arturo Gurrola wrote: try184.c:1:20: error: curses.h: No such file or directory and then Note that you must have libcurses developer headers installed. Abort.. I'm also installing MSPGCC4 under Cygwin right now, and I ran into the same problem. I have libncurses-devel installed, which provides ncurses/curses.h, but MSPGCC4's do-gdb.sh script looks for curses.h and doesn't find it. Since the compilation runs so terribly slowly for me (I'm running WinXP in a virtual machine on my Mac, and the compilation is easily an order of magnitude slower than it was when doing it natively under OSX), and buildgcc.pl does a brute-force compilation which will rebuild gcc before it even gets around to choking on gdb... I decided to try skipping do-gdb.sh and instead compile gdb manually. What I've done so far is: cd build/gdb-7.1 ./configure --prefix=/opt/msp430-gcc-4.4.4 --target=msp430 --disable-werror make It failed to find libz and choked on the compilation, so I'm not there just yet. I plan to use the compiler under OSX, but I'm still trying to build it under WinXP so that I can try to use gdb + gdbproxy to download code with my eZ430 dongle or MSP-FET430UIF, which aren't supported under OSX yet. I wouldn't mind using IAR or CCC to download code built by msp430-gcc, but it seems that they want the code in a .d43 format which I don't know how to create with msp430-gcc. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
Don't have Mac OS X, but mspdebug allows me to use the FETUIF-430 under Fedora 13 on Linux. Infinitely nicer than an ssh terminal under Windows and a shared disk drive. See mspdebug.sourceforge.net. http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_Mac_OS_X#Installing_mspdebug_under_Mac_OS_X On Thu, Sep 2, 2010 at 2:02 PM, Mark J. Blair n...@nf6x.net wrote: On Sep 2, 2010, at 11:57 AM, Peter Bigot wrote: Go to http://www.elprotronic.com and download FET-Pro430. The Lite (free) version has done everything I needed. Thanks for the suggestion! I'll give that a try. I hope that someday I'll be able to use the TI USB programmers under Mac OS X, without needing to pop up WinXP on a virtual machine. Has anybody looked into reverse-engineering the USB protocols for those programmers so that a fully open-source implementation that supports them can be created? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
MA: Thanks. The patches look good, and I've merged them to the next branch of the git repository. MB: Help is certainly welcome. Wiki pages with updated instructions, especially how to build (especially on windows) would address the biggest problems; perhaps, having recently succeeded, you could document what you did? As we're moving back to putting everything under mspgcc, and we have to keep mspgcc4 somewhat stable due to external references to its content by the WASP project, I'd suggest that be done on the existing mspgcc wiki at: https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki If you need somebody to give you write access, contact me directly with your sourceforge userid. Just mark the stuff that's currently only relevant to mspgcc4; I don't think we're going to change the existing mspgcc infrastructure, just supersede it. I'm hoping for a new release under the mspgcc project within a couple weeks, with my updates that eliminate all the specialized hard-coded chip-specific addresses and assumptions. Unfortunately, real work has started to interfere again, so it's already later than I'd intended. We could also use a downstream packager for OSX, so people won't have to fight with the build process. (Ubuntu and Windows, too; I think Rob Spanton's doing Fedora/RedHat, though we haven't coordinated the release processes yet: that should be done with the return to mspgcc.) Peter On Fri, Sep 3, 2010 at 10:45 AM, Mark J. Blair n...@nf6x.net wrote: On Sep 3, 2010, at 7:33 AM, M. Andree wrote: Sorry for that, I've done that quick hack as an assistance to newbies, but evidently it backfires on recent Cygwin and some Solaris versions. I have now figured that finding curses.h reliably and portably is a major undertaking (way more time that I can spend), and will anyways not necessarily match what ./configure digs out later, so let's just remove the check. Don't feel too bad... making any complex package build portably can be very difficult! I'm up and running with MSPGCC4 and mspdebug under OSX now, and I'm really happy that this fully open and complete toolchain exists. I hope that I'll be able to contribute in some small way towards its growth and improvement, because I believe that it's beneficial for development tools to be free in order to enable and stimulate creation of new and better things. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Errors in a .h file?
Could be this: https://sourceforge.net/tracker/?func=detailaid=3038718group_id=277223atid=1177287 Make sure you're using the latest TI headers version of msp430-libc. That should be the ti-20100829 release. If you are, it may be that there's another header named iomacros.h that is being included instead of the one that is needed. Peter On Mon, Sep 6, 2010 at 1:03 PM, Arturo Gurrola mgurr...@gdl.cinvestav.mxwrote: I'm using mspgcc4 (http://sourceforge.net/projects/mspgcc4/) to build FreeRTOS' msp430_GCC demo, this is what the make command throws: make msp430-gcc -c -mmcu=msp430x449 -Os -g -I. -I../../Source/include -I../Common/include -DGCC_MSP430 -Wall -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wunused main.c -o main.o In file included from ./FreeRTOSConfig.h:57, from ../../Source/include/FreeRTOS.h:67, from main.c:85: /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:232: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:241: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:256: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:277: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:286: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:301: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:310: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:657: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:714: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:759: error: expected ) before numeric constant /cygdrive/c/mspgcc4/bin/../lib/gcc/msp430/4.4.4/../../../../msp430/include/msp430x44x.h:861: error: expected ) before numeric constant main.c: In function main: main.c:160: warning: pointer targets in passing argument 2 of xTaskGenericCreate differ in signedness ../../Source/include/task.h:1255: note: expected const signed char * const but argument is of type char * make: *** [main.o] Error 1 So the problems seem to be coming from mspgcc (msp430x44x.h). Any ideas? -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TimerA registers definitions
Yes, that extra-underscore fix is in the 20100815 release. I'm really unmotivated to continue to patch the hand-written header files (and no, the peripherals do not stay in the same place, and it's hard to determine where they're going to end up from general chip family information). The TI headers are much more likely to be correct. However, th.ln if you'll please open a ticket on the mspgcc project, and post in that ticket a tar file containing all your suggested changes (rather than a separate email with each one in an attachment, which is really inconvenient), I'll review them for integration into an upcoming release. Peter On Wed, Sep 8, 2010 at 9:43 AM, William Chops Westfield wes...@mac.com wrote: On Sep 8, 2010, at 2:28 AM, thln wrote: PS : Don't hesitate to correct the document if you found some mistakes * 2009-09-08 - THLN * - definition updated with flexible base address #define TA0CTL_H_ __MSP430_TA0_BASE__ + 0x1 /* TA0 Control Register Hi */ As a general practice, shouldn't such constructs be parenthesized to prevent surprises if the macros are used in a more complicated arithmetic expression? #define TA0CTL_H_ (__MSP430_TA0_BASE__ + 0x1) Now, these are not popular symbols to use in a end-user program, and I don't think they'll cause problems within the context of the existing usage, but it never hurts to be careful... (applies to all these edits, I think.) (hmmph. An here I was recently admiring that MSP430 peripherals stayed in the same place across all the chips. Sigh.) /* TimerA IV names */ #if defined(__MSP430_HAS_TA3__) || defined(__MSP430_HAS_TA2) #define TAIV_NONE 0x00 /* No interrupt pending */ #define TAIV_CCR1 0x02 /* Capture/compare 1 TACCR1 CCIFG Highest */ #if defined(__MSP430_HAS_TA3__) #define TAIV_CCR2 0x04 /* Capture/compare 2 TACCR2 CCIFG */ #endif /*__MSP430_HAS_TA3__*/ #define TAIV_OVERFLOW 0x0A /* Timer overflow TAIFG Lowest */ #endif /*__MSP430_HAS_TA3__ || __MSP430_HAS_TA2__*/ You're missing the recent fix here (or is that not in yet?) BillW -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] latest mspgcc vs latest webpage/wiki/etc...
I'm doing the work in local git repositories that are mirrors of the official GNU binutils and gcc ones. I'd been reluctant to push them to sourceforge because of size, but in the end I think that's the right solution. The status is that I've successfully built applications with hand-crafted linker scripts, and all chip-specific (as opposed to feature-driven) data has been eliminated from binutils and gcc. It's not really ready for anybody else to use; I need some updates from TI, and a way to package the MSP430 binutils scripts, then I can document what I did and why and push things to a repository where people can play. The initial releases will *not* have build script support: you'll need to be able to build and install binutils and gcc and msp430-libc manually. Unfortunately, though People Power is committed to community support and has approved my work on this, there are some short-term deadlines that are impacting how much time I can spend on it this month. I'm fighting to restore mspgcc's priority. Nonetheless, if you can't get ti-20100815 to build with the current mspgcc4 on any reasonable platform, that's something we need to get fixed ASAP. Can you provide more details, here or as a ticket on the mspgcc project (or is there already a ticket I've missed)? Peter On Thu, Sep 9, 2010 at 4:27 AM, William Chops Westfield wes...@mac.comwrote: What's the status of the new git-based mspgcc4 (with TI includes/ etc)? Sourceforge and/or the wiki still don't mention it at all, and I can't get it to install libc due to fairly obvious problems that ought to be cross-platform... Thanks Bill W -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] latest mspgcc vs latest webpage/wiki/etc...
completely disabled and so XPUSHM does not get defined. I don't see how this compiles on any platform... Neither do I. It only affects the msp3 and msp5 multilibs, which I don't use since until last week I didn't have relevant hardware, and the Makefile (under Linux) just blows right over the error for those two sub-builds. SF ticket 3062827 on mspgcc created, fix submitted and merged to next. Patch attached. Please let me know whether it fixes the problem. I'll try to do better at scanning the make output. Peter
Re: [Mspgcc-users] Building MSPGCC4 from SVN.
For legacy reasons, SVN is still present, but is no longer used for maintenance. The latest version is in git. The latest stable release is 20100829. The zip and tar.bz2 files have identical content; I just don't use windows so make it available in zip in case it's hard to deal with tar.bz2 files there. Peter On Sat, Sep 18, 2010 at 10:54 AM, Claude Sylvain csylv...@electro-technica.com wrote: Hello, - I am trying to build MSPGCC4 from SVN, using the procedure indicated at http://mspgcc4.sourceforge.net/ Surprisingly, the SVN version is older than the latest source package (mspgcc4-20100829.tar.bz2) !? - Is there a way to get an up-to-date version of MSPGCC4 from SVN ? Claude. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] mspdebug and f5438 erase problem
Got a EXP430F5438 so I can eventually do far-memory work on gcc/binutils. Verified the hardware and MSP-FET430UIF work by using Code Composer on Windows to install and run the User Experience. Now need this on Linux. Using the current master of the mspdebug repository (ecccfb5), I get: linux[19]$ mspdebug -d /dev/ttyUSB1 -j uif Trying to open UIF on /dev/ttyUSB1... Initializing FET... FET protocol version is 20404000 Configured for JTAG (2) Sending initial reset... Set Vcc: 3000 mV Device ID: 0x5438 Device: MSP430F5438 Code memory starts at 0x5c00 Number of breakpoints: 8 Displaying memory works fine. But I want to load a small test program, and do: (mspdebug) erase Erasing... uif: read error: Connection timed out fet: erase command failed (mspdebug) At that point, I can't talk to the FET430UIF again until I pull and re-insert the USB. When I do, it appears that the flash has been erased. I can then use load to program a new application without invoking erase again, but it's a bit inconvenient to have to keep unplugging the FET430UIF between those steps. Any ideas? Thanks. Peter
Re: [Mspgcc-users] MSGCC4. A linker error.
*Adding* -lc might be enough; keep -lgcc. Peter On Sat, Sep 25, 2010 at 2:05 PM, Peter Bigot p...@peoplepowerco.com wrote: _unexpected_ is defined in libc.a, which you are not including. Try using msp430-gcc instead of msp430-ld as the linker. That's usually safer when linking code compiled in higher-level languages where language-specific runtime support is needed. (-lgcc is not sufficient in this case. -lc might be enough.) Peter On Sat, Sep 25, 2010 at 12:51 PM, Claude Sylvain csylv...@electro-technica.com wrote: Hello, - I am currently trying MSPGCC4 under Cygwin (1.7.x)/Window XP professional. The MSPGCC4 package I use is mspgcc4-20100829.tar.bz2, and was compiled under Cygwin. - I try to port to MSPGCC4 a project that built correctly with MSPGCC, and I have the following linker error: +++ msp430-ld ./obj/common/delay.o ./obj/common/misc.o ./obj/drivers/uart/uart2.o ./obj/app/hb.o ./obj/app/main.o ./obj/app/test.o ./obj/common/ach_con.o ./ obj/drivers/led.o ./obj/drivers/timera.o ./obj/drivers/tp.o ./obj/drivers/fla sh/flash_idle.o ./obj/kernel/kernel.o ./obj/mcu/mcu_init.o -Tmsp430x1121.x -Ma p=./out/app.map --cref --no-warn-mismatch -L/opt/mspgcc4/lib/gcc/msp430/4.4.4/ - L/opt/mspgcc4/msp430/lib/ -lgcc -o out/app.elf /opt/mspgcc4/msp430/lib//crt430x1121.o: In function `vector_fffc': (.text+0x2): undefined reference to `_unexpected_' make: *** [out/app.elf] Error 1 +++ - After some makefile and linker script revision, I can not figure out what can produce this error. Any help will be appreciated. Claude. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSGCC4. A linker error.
_unexpected_ is defined in libc.a, which you are not including. Try using msp430-gcc instead of msp430-ld as the linker. That's usually safer when linking code compiled in higher-level languages where language-specific runtime support is needed. (-lgcc is not sufficient in this case. -lc might be enough.) Peter On Sat, Sep 25, 2010 at 12:51 PM, Claude Sylvain csylv...@electro-technica.com wrote: Hello, - I am currently trying MSPGCC4 under Cygwin (1.7.x)/Window XP professional. The MSPGCC4 package I use is mspgcc4-20100829.tar.bz2, and was compiled under Cygwin. - I try to port to MSPGCC4 a project that built correctly with MSPGCC, and I have the following linker error: +++ msp430-ld ./obj/common/delay.o ./obj/common/misc.o ./obj/drivers/uart/uart2.o ./obj/app/hb.o ./obj/app/main.o ./obj/app/test.o ./obj/common/ach_con.o ./ obj/drivers/led.o ./obj/drivers/timera.o ./obj/drivers/tp.o ./obj/drivers/fla sh/flash_idle.o ./obj/kernel/kernel.o ./obj/mcu/mcu_init.o -Tmsp430x1121.x -Ma p=./out/app.map --cref --no-warn-mismatch -L/opt/mspgcc4/lib/gcc/msp430/4.4.4/ - L/opt/mspgcc4/msp430/lib/ -lgcc -o out/app.elf /opt/mspgcc4/msp430/lib//crt430x1121.o: In function `vector_fffc': (.text+0x2): undefined reference to `_unexpected_' make: *** [out/app.elf] Error 1 +++ - After some makefile and linker script revision, I can not figure out what can produce this error. Any help will be appreciated. Claude. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSPGCC4. GDB can not debug at full speed.
I can't help with this, not using windows or Olimex. I understand that msp430-gdbproxy is based on proprietary code and can't be rebuilt; it may not be compatible with current versions of gdb. I believe mspdebug is the preferred solution. Others on the list may be able to provide more help. Peter On Sat, Sep 25, 2010 at 8:57 PM, Claude Sylvain csylv...@electro-technica.com wrote: Hello, - This is just to report something that seems to be a bug on MSPGCC4 GDB. - I am currently trying MSPGCC4 under Cygwin (1.7.x)/Window XP professional. The MSPGCC4 package I use is mspgcc4-20100829.tar.bz2, and was compiled under Cygwin. - The target is based on a MSP430F1121. The debugger I use is a MSP430-JTAG-ISO from Olimex. msp430-gdbproxy says: Remote proxy for GDB, v0.7.1. - mspgcc-gdb seems to not be able to run an MSP430F1121 based target at full speed. In GDB, when setting a (normal) break point in the main program loop, and typing continue, gdb-proxy display a lot of time the following message: debug: MSP430_State() 1, (-1 steps) and run the target very slow. As slow as if a conditional breakpoint was set (break if cond). In the same condition, the classic MSPGCC GDB do not display any of that messages, and run the target at full speed. - Also, typing continue without any breakpoint set, the target is running very slow (not full speed). This is not the case with the classic MSPGCC GDB. Any thought about that? Claude. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] 227x HW multiplier?
As I mentioned before, mspgcc4 does not properly prevent generation of the routines that reference the hardware multiplier registers, even though it does correctly categorize the 2274 as an msp1 chip that does not have the hardware multiplier. Unless something generates a reference to mulsi3hw, you should not see problems resulting from that. So the question is why you're referencing that routine. One possibility is if you use strtol, which apparently even in msp1 refers to the hw version of the multiplier function. I have no idea why. There is no workaround at the moment; it'll take me a couple hours to dig through all the dependencies to see what's going on, and I won't have a chance to do that until later this week. I'll try to get something out by this weekend. Peter On Mon, Sep 27, 2010 at 4:16 PM, Paolo Zebelloni p.zebell...@vodafone.it wrote: I still can't compile my project under 4.4.4, but I have an idea: AFAIK 2274 doesn't have a HW multiplier, but at link stage I get this error (and others similar): /opt/msp430-gcc-4.4.4/lib/gcc/msp430/4.4.4/msp1/libgcc.a(_mulsi3hw.o): In function `__umulsi3hw': /home/clabs/Downloads/MSPGCC/mspgcc4-20100829/build/gcc-4.4.4- build/../gcc-4.4.4/libgcc/../gcc/config/msp430/libgcc.S:229: undefined reference to `__MPY' IMHO the problem is the reference to __umulsi3hw, instead of a reference to __mulsi3: this drives me to think about a wrong CPU description. Keep in mind that 3.2.3 compiles and links without any issue. Regards. -- Paolo Zebelloni E-Mail: p.zebell...@vodafone.it Mobile: +39.347.8000945 Skype: p.zebelloni -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] 227x HW multiplier problem identified (Paolo Zebelloni)
Well, it's in stdlib as opposed to being in binutils or gcc. And has nothing to do with hardware multiply being used in the demonstration program. A one-line program calling printf with a format parameter shows the problem. Which is that when msp430-libc builds the multi-lib variants, it doesn't bother to tell the compiler which MCU class to use when building functions (it does for the chip-specific crt0 modules, but not for the libc archives that supposedly provide family-specific variants). This falls under the heading of how did it ever work, the answer appears to be that it didn't. The necessary distinguishing flags were not preserved when mspgcc3's two variants (with/without hardware multiply) were converted to multilibs in support of mspgcc4's six variants. I'll get a new msp430-libc release out later today. Peter On Wed, Oct 6, 2010 at 5:28 AM, JMGross msp...@grossibaer.de wrote: Not necessarily IN it, only related to it. :) The question is, why got only this function compiled with reference/usage of the hwmul functions and all other didn't. Or do you just use only this one function that does multiplication? Is the complete stdlib compiled wrong and uses hwmul while it shouldn't? Or just strtol? If so, why and how (all should be compiled the same way) Or is the linker using the wrong version of the stdlib? If so, why? And in this case it isn't the fault of the stdlib at all, but in the linker script. how did you redefine strtol? did you use your own version of it, do you not use it anymore or did you change something in the stdlib sources and recompiled it? My suggested hotfix was to write your own hwmul function override and use the stdlib normally. (the hwmul functions are in the gcclib and never called directly, they are helper functions the compiler calls depending on normal C multiplications, and they are weak, so you can write your own). I did so for the mspgcc3, so the functions use the MPY32 instead of the MPY16 emulation where it is available. Much faster and also a bit smaller. JMGross - Ursprüngliche Nachricht - Von: Paolo Zebelloni An: mspgcc-users@lists.sourceforge.net Gesendet am: 06 Okt 2010 00:21:19 Betreff: [Mspgcc-users] 227x HW multiplier problem identified (Paolo Zebelloni) Peter, JMGross, After a stupid patch (a simple redefinition of strtol) I can compile the whole project. Now I'm sure that problem ***IS*** in stdlib, as Peter said. Regards. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] Release 20101006 of mspgcc4 and msp430-libc
New mspgcc4 release numbered 20101006 posted on http://sourceforge.net/projects/mspgcc4/. See specific changes at http://mspgcc4.git.sourceforge.net/git/gitweb-index.cgi. Let me know if something that used to work doesn't anymore. msp430-libc legacy headers: - 6bccacf SF 3082318: c++ dislikes uninitialized const structure declaration - 5fde82b Add some missed chips - daebe6a SF 3056437: MSP430F54xx is missing ADC12 define - cc1d75c SF 3082367: multilib misbuilds libc for msp1 - 305dc03 Provide macros for extended instructions that do not depend on 20-bit addresses msp430-libc TI headers: - 4f9a595 Provide macros for extended instructions that do not depend on 20-bit addresses - fcf9225 SF 3082367: multilib misbuilds libc for msp1 - 8a45d75 Incorporate new TI release. - 73986ca Update release history mspgcc4: - 5affcde Merge branches 'ma/gdb' and 'ma/readme' into next - 89b239a Shuffle README files around, update README-1st.txt. - 5533d77 Install Insight before GDB; fix undef'd warnings. - 3458481 [SF 3059894] Don't check for curses.h, too fragile. - 5151e9d Update versions Peter -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
That's not an ABI problem. Without a declaration available at the point of
call, C mandates that the parameter be assumed to be an int (two bytes). If
you define a function with non-int parameters, you have to have a compatible
declaration in scope wherever it's invoked. Using to mask off bits, or
even casting the parameter, won't do any good.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
Sorry, you're right: I read this too quickly.
I don't think it's an ABI problem so much as a compiler problem: it's
actually passing the 32-bit value in registers r14 and r15, instead of
truncating it to an int and passing it in r15, as it's supposed to do when
there's no declaration.
Fine. Yet another bug to fix.
Still, work around is to properly declare the function. Then you can pass
it as a uint32_t, int, or uint8_t, whatever you want.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] Use of mspgcc* in critical production environment
On Thu, Oct 7, 2010 at 5:49 AM, JMGross msp...@grossibaer.de wrote: Thanks for all your work (even if I don't use mspgcc4 as it isn't ready for critical production environment) You're welcome. But: In case somebody reads this and decides to avoid mspgcc4 in favor of a supposedly production-ready mspgcc3, the parameter non-truncation problem Kim Toms found seems to be present there too. The difference? Nobody's going to fix it in mspgcc3. None of this stuff is what I would call ready for a critical production environment. If you've been using something for years, and have hand-coded around the problems and limitations that you've found affect your current code, there's little motivation to move to a new version that may have new problems to discover. But don't assume that's an indication of quality from an independent perspective, or that there aren't things going wrong that you just haven't found yet. Dealing with updates is a pain, but I've found that in general the overall quality improves with time. Problems you identify help somebody else, and vice-versa. The tragedy of the commons applies very nicely in open source development. Peter -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
Third time's the charm? It's been so long since I've dealt with KR C I've
forgotten the rules.
The behavior is correct. char and short are upcast to int when no
declaration is in scope. Integral types that are larger than int are left
as is. That you're masking off all but the low byte does not change the
type of the expression that's used as a parameter: it's a 32-bit int on a
16-bit microcontroller, and requires two registers to pass by value.
No bug here. Either explicitly cast to int, or make sure there's a
declaration in scope so the compiler knows what to do. I suggest the
latter.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSPDebug 0.11 and msp430f247
The 247 and 249 do have different layouts, but I would have expected mspdebug to write data to the addresses specified in the object file, but perhaps it does something else. If the object file is built for -mmcu=msp430x247, the text section should start at 0x8000 and data at 0x1100. If for -mmcu=msp430x249, the text is at 0x1100 and data at 0x0200. Check this with msp430-objdump -s a.out. If that's right, it would seem to be an mspdebug issue. Peter On Fri, Oct 15, 2010 at 3:00 AM, Michiel Konstapel m.konsta...@sownet.nlwrote: Hi Daniel and others, I've been using mspdebug for flashing (mainly 2418s), which works great. However, when I try to program a 247, there seems to be a problem: flashing completes without errors, but the program doesn't run. Maybe it gets loaded to a wrong location? Anything I can do to help you debug it? The output looks perfectly fine: Trying to open UIF on /dev/ttyUSB0... Device: MSP430F249 Erasing... Programming... It does identify the device as a 249, maybe causing it to assume a different memory layout? Kind regards, Michiel -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSPDebug 0.11 and msp430f247
Bad flash on the chip? From a quick look, it seems that the hex of the readback (excluding address and checksum) shows zeros where there should be ones, but never ones where there should be zeros. Seems implausible if something's changing the data as it gets written. Might try erasing the flash or writing patterns to it and seeing what you can read back. At any rate, not a compiler/binutils problem, so my work here is done. Peter On Fri, Oct 15, 2010 at 9:19 AM, Michiel Konstapel m.konsta...@sownet.nlwrote: If the object file is built for -mmcu=msp430x247, the text section should start at 0x8000 and data at 0x1100. If for -mmcu=msp430x249, the text is at 0x1100 and data at 0x0200. Check this with msp430- objdump -s a.out. If that's right, it would seem to be an mspdebug issue. Yup, it is for a 247. msp430-objdump says: Contents of section .text: 8000 31400021 b240805a 20013f40 2c000f93 1...@.!.@.Z .?@,... 8010 04241f83 cf430411 fc233f40 04000f93 .$...c.@ ... Contents of section .data: 1100 00010100 Contents of section .vectors: ffe0 30803080 e8837284 30803080 30803080 0.0...r.0.0.0.0. fff0 a8805c80 30803080 c483ea80 30800080 ..\.0.0.0... So that looks alright. It seems things are ending up in the right spot. However, if I flash a hex image, then dump it with hexout, the bytes are different. This'll probably get mangled in the email, but it's the first bit of sdiff output: :108031400021B240805A20013F402C000F93A4 | :10803140B240805A20013F402C000F93C5 :108014241F83CF430411FC233F4004000F932B | :108014241F83CF430400FC233F4004000F933C :108025242F839F4F0E8C0011FB233040FC84CE | :108025242F839F4F0688FB233040B8842F :1080300030400C8C100050009000D000F00088 | :1080300030400488100050009000D000F00094 :10804F4212C30F100F110F115FF332C203431F :10804F4212C30F100F110F115FF332C203431F :108050007FF330414F93012432D230410F120E1280 :108050007FF330414F93012432D230410F120E1280 :10806D120C12B01278803C413D413E413F411F :10806D120C12B01278803C413D413E413F411F :10807000B1C0F0131F4262018F105FF3D7 :10807000B1C0F0131F4262018F105FF3D7 :108082241F42720130411F4264018F105FF3CE :108082241F42720130411F4264018F105FF3CE :108092241F42740130411F4266018F105FF3BA :108092241F42740130411F4266018F105FF3BA :1080A2241F42760130410F120E120D120C12E3 :1080A2241F42760130410F120E120D120C12E3 :1080B0001F422E0112C34F107FF31F930C242F93E6 :1080B0001F422E0112C34F107FF31F930C242F93E6 :1080C5382F930A20B0129880073C0F930520A3 :1080C5382F930A20B0129880073C0F930520A3 :1080D000B0127880023CB01288803C413D413E4164 :1080D000B0127880023CB01288803C413D413E4164 :1080E0003F41B1C0F0130F120E120D123C :1080E0003F41B1C0F0130F120E120D123C :1080FC124F43B0120A813C413D413E413F4189 | :1080FC12000218013C413C413E4131405D :1081B1C0F01330414E4F7FF33F92AA | :1081B01312431402300011 :10811000592C0F5F104F1881288158816A817A810C | :108110001900020118811800020130015E :108120008A819A81AA81BA811F4282018F105FF3EE | :1081200082808A81820182810A02020082100C020E :108133241F4292013041B2F0EFFF820182938B | :108130200F4290013040A0128201000197 I don't know what to make of that, but it might be relevant. Michiel -Original Message- From: Peter Bigot [mailto:p...@peoplepowerco.com] Sent: vrijdag 15 oktober 2010 15:56 To: GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] MSPDebug 0.11 and msp430f247 The 247 and 249 do have different layouts, but I would have expected mspdebug to write data to the addresses specified in the object file, but perhaps it does something else. If the object file is built for -mmcu=msp430x247, the text section should start at 0x8000 and data at 0x1100. If for -mmcu=msp430x249, the text is at 0x1100 and data at 0x0200. Check this with msp430- objdump -s a.out. If that's right, it would seem to be an mspdebug issue. Peter On Fri, Oct 15, 2010 at 3:00 AM, Michiel Konstapel m.konsta...@sownet.nlwrote: Hi Daniel and others, I've been using mspdebug for flashing (mainly 2418s), which works great. However, when I try to program a 247, there seems to be a problem: flashing completes without errors, but the program doesn't run. Maybe it gets loaded to a wrong location? Anything I can do to help you debug it? The output looks perfectly fine: Trying to open UIF on /dev/ttyUSB0... Device: MSP430F249 Erasing... Programming... It does identify the device as a 249, maybe causing it to assume a different memory layout? Kind regards, Michiel
Re: [Mspgcc-users] Position independent code
I doubt there's any explicit support for it. Position independent code is mostly irrelevant in embedded systems where there won't be any dynamic loading. There are applications where one might replace code with overlays, but those can be generally be handled with fixed addresses. I believe binutils has support for this, though I haven't used it myself. If you care to file a tracker problem on mspgcc or mspgcc4, I'll eventually make sure that, at the least, -fPIC doesn't silently generate non-PIC code. If you have an application which actually does require position-independent code, that warrants its own enhancement request. Peter 2010/10/18 Frédéric Sureau frederic.sur...@gmail.com Hi all, Does MSPGCC support a way to produce position independent code ? The assembly generated using -fPIC argument seems to still be position dependent. Fred -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Position independent code
Adding a feature request is probably a good idea, since I'm likely to resolve the bug by making -fPIC generate an error. I understand the use cases, but personally will not get to this any time soon. Uniarch (eliminating the need to create new releases of every component in the toolchain just because there's a new chip like the MSP430G2231) and far data/code support are much higher priority. Peter 2010/10/19 Frédéric Sureau frederic.sur...@gmail.com Hi, There are many research interests in being able to dynamically load code in the MCU. For example, the Contiki OS (dedicated to Wireless Sensor Networks) proposes a solution to dynamically link and relocate native code (in ELF format) in microcontrollers. http://www.sics.se/%7Eadam/dunkels06runtime.pdf One of the arguments of the author is that position independent code is not supported by MSP compilers. But this article was written 4 years ago... I think that dynamic loading of native code could be extremely simplified using PIC. If the on-board linker is simplified, it would leave more space in RAM/ROM for the real application. I have reported the bug (-fPIC silently won't work). Should I also send a feature request ? Fred 2010/10/19 JMGross msp...@grossibaer.de: - Ursprüngliche Nachricht - Von: Peter Bigot Gesendet am: 19 Okt 2010 04:48:41 I doubt there's any explicit support for it. Position independent code is mostly irrelevant in embedded systems where there won't be any dynamic loading. There are applications where one might replace code with overlays, but those can be generally be handled with fixed addresses. I believe binutils has support for this, though I haven't used it myself. Well, there IS an application where PIC is required (even if it can be solved using non-PIC code as well): If you need to place functions in RAM, but don't want to place them there permanently (by putting them into the data segment and hoping they will be there untouched ever after PUC). A prominent example is a flashing function, which is copied from flash to ram when needed. For those functions, however, I'd prefer the use of (inline) assembly, which can be made either position-independent or explicitely written for the intended destination. There is another possible usage for PIC: if you want to dynamically load code from a library stored in external flash. Doing so using overlay mechanisms is far more complex (if it is a collection of more or less complex and indepentent functions) than using PIC. My own projects, however, don't have grown so much that they won't fit into existing flash anymore, so I never needed this so far. JMGross 2010/10/18 Fr=E9d=E9ric Sureau frederic.sur...@gmail.com Hi all, Does MSPGCC support a way to produce position independent code ? The assembly generated using -fPIC argument seems to still be position dependent. Fred -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSPGCC Support for MSP430G2231
No, that chip is not supported. File a ticket requesting support on the mspgcc4 project and I'll add it in the next release, whenever that is. This will impact binutils, gcc, and msp430-libc, with the only really important stuff being in binutils (msp430all.sh needs to be updated with the correct addresses for that chip). If you need it faster, you can follow the steps at https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=AddingNewDevice. Treat it as an ISA_22 and name it msp430x2231. Or wait for the uniarch release, but that probably won't be until sometime in November. Peter On Tue, Oct 19, 2010 at 8:27 AM, Michael Heidinger mch.heidin...@gmx.dewrote: Hi, I wonder if there's MSPGCC for the MSP430G2231. I found in the include dir the corresponding msp430g2231.h file. But if I take a look to io.h i cannot find the controller. Is there a support for it? If not, how to add it? Thank you for your help! Michael -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Calling constructors (C++) manually with mspgcc4
Constructors for global C++ objects should be called automatically, as long
as you're not doing something in the link phase that disrupts things. My
testing with the program below shows that it seems to work. Note that if
you fall off the end of main(), the global dtors are called.
0x1c00#global ctor
0x2bfe#local ctor
In main
0x2bfe#local dtor
0x1c00#global dtor
Peter
#include stdio.h
class CtorDtor {
public:
CtorDtor (const char* id) :
id_(id)
{
printf(%p#%s ctor\r\n, this, id_);
}
~CtorDtor ()
{
printf(%p#%s dtor\r\n, this, id_);
}
private:
const char* id_;
};
CtorDtor global(global);
int main ()
{
CtorDtor local(local);
printf(In main\r\n);
return 0;
}
On Wed, Oct 20, 2010 at 9:48 AM, Tobias Baumgartner
tb...@ibr.cs.tu-bs.dewrote:
Dear list,
I'm currently trying to port a project (using C++) from mspgcc (3.2.3)
to mspgcc4. It is a generic C++ library, running (among other systems)
on top of Contiki (which is a C-based firmware/OS).
As far as I know, constructors of global C++ objects are not called
automatically, so that the user must call them manually. So far I did
this successfully via
typedef void(*ctor_t)();
extern ctor_t __ctors_start;
extern ctor_t __ctors_end;
...
ctor_t ctor = __ctors_start;
while( ctor __ctors_end )
{
ctor();
ctor = (ctor_t)((void*)ctor + sizeof(void*));
}
However, compiling the project with mspgcc4, it doesn't work anymore.
Printing addresses of ctors_start/end via
printf( Call ctors from %04x to %04x\n,
(unsigned int)*__ctors_start,
(unsigned int)*__ctors_end );
produces a higher number for ctors start address than for the end
(looking in the *.map-file, everything looks fine).
Do I understand sth wrong (so, is the above code incorrect, and it
worked on the 3.2.3 just by luck)? Do you have an idea, how I should
call the constructors?
Or is the information above incomplete - then please let me know!
Best,
Tobias
--
Nokia and ATT present the 2010 Calling All Innovators-North America
contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in
marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] new version 0.12:programmation in the flash2onthe MSP430F5438A
mspgcc4 does not support more than 64KB of flash. You can probably hand-code calls; there should be instructions somewhere on the list archives, now available at http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/ Would somebody who has gotten the MSP430X branch of mspgcc3 to generate code for far text and/or data mind writing up a short how-to for the wiki? Peter On Thu, Oct 21, 2010 at 4:32 AM, Emilie e.la...@watteco.com wrote: Hi Daniel, With the new Hex.c file, the program loads in the flash1 and flash2. But the execution of the program is not ok. With the same program: when I load only in the flash1, the execution is ok. To use the flash2 with my program in the compilation mspgcc4, I used the command __attribute__((section(.fartext))) before several functions. I'm going to check if the options of my compilation mspgcc4 are good. Perhaps that I must use a specific option with mspdebug to load the format large_memory_model? Regards, Emilie LAYEC. -- From: Daniel Beer dlb...@gmail.com Sent: Wednesday, October 20, 2010 10:46 PM To: Emilie e.la...@watteco.com Cc: GCC for MSP430 - http://mspgcc.sf.net; mspgcc-users@lists.sourceforge.net Subject: Re: [Mspgcc-users] new version 0.12:programmation in the flash2onthe MSP430F5438A On Wed, Oct 20, 2010 at 09:13:19AM +0200, Emilie wrote: Hi Daniel, You will find in the attached file the hex file. Thanks a lot for your help, Regards, Emilie LAYEC Hi Emilie, I found a bug in HEX file parsing which caused the 64k portions of this file to be loaded at the wrong address. I've pushed through a change to the git repository which should fix this problem. Instructions for getting at the git repository can be found on this page: http://mspdebug.sourceforge.net/download.html Let me know if this change works for you. Cheers, Daniel -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Switching from legacy headers to TI headers
I wonder whether it would be appropriate for this tiny patch to be applied as part of the mspgcc4 build process? Probably somebody included iomacros.h before including a chip-specific header. What I think I'll do is just remove the condition in the iomacros.h that comes with the TI header variant so it's not necessary. If you could file a bug on the mspgcc4 SF tracker that'd help remind me to do this. Do any of y'all have any ideas about the cleanest way to deal with this? So far, I haven't found a way to either trick the C preprocessor into stripping out the U suffixes, or to get the assembler to digest them properly. Bah. Those had to be added in to avoid warnings about integer value overflow when generating 16-bit constants that had the high bit set. In the short term, I'd suggest editing the installed headers to remove the suffix from the constants you need, and again filing a tracker ticket, which I'll resolve by coming up with some solution that works on both C and assembler. Fixes for both these should be pretty straightforward, and ought to be in the next release (no estimate when that'll be, I'm buried in other tasks at the moment). Peter On Sun, Oct 24, 2010 at 5:46 PM, Mark J. Blair n...@nf6x.net wrote: I'm trying to switch from using the legacy headers to the TI ones, in order to start compiling code for MSP430F55xx processors. My first flow-flushing process is to re-do my previous port of the slac139d code for the ez430-RF2500 platform, since I found that it would no longer compile properly once I switched to the TI headers. I'm using mspgcc4 from the git repository, from the master branch, last pulled around 10/6/2010. I'm building under Mac OS X. First, I found that I had to add this #define near the beginning of .../msp430-gcc-4.4.4/msp430/include/iomacros.h in order to get the const_sfrb() macros to work: #define __MSP430_TI_HEADERS__ I'm not sure why this definition didn't carry through from the other headers that included iomacros.h, but adding that line cured the barfing on const_sfrb(), and let my compilation proceed a lot further. I wonder whether it would be appropriate for this tiny patch to be applied as part of the mspgcc4 build process? I'm stuck on the best way to approach the second issue I'm having, though. There's a small amount of assembled code in the slac139d project, and it includes msp430x22x4.h to pick up register definitions. Unfortunately, lots of the TI header files use integer constants with U suffixes, and the assembler barfs on those. I hope that I can avoid needing to massage all of the TI header files to get rid of those, because that would be a headache that I'd need to re-live every time I upgrade mspgcc4, and such a sweeping change doesn't seem like something that's appropriate as part of the standard mspgcc4 distribution. Do any of y'all have any ideas about the cleanest way to deal with this? So far, I haven't found a way to either trick the C preprocessor into stripping out the U suffixes, or to get the assembler to digest them properly. Thanks in advance for any suggestions. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Switching from legacy headers to TI headers
For mspgcc4's git repository, stay on master. The changes will probably be limited to the msp430-libc repository; if you follow that, use the pab/ti_headers branch, as master is still used for the legacy headers. Peter I understand; I've been swamped at my day job, and have been putting off working on this stuff for a couple of weeks already. Should I remain on the master branch, or will the next release be made in a different branch? -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Switching from legacy headers to TI headers
Yes. Peter On Sun, Oct 24, 2010 at 8:47 PM, Mark J. Blair n...@nf6x.net wrote: On Oct 24, 2010, at 6:26 PM, Peter Bigot wrote: For mspgcc4's git repository, stay on master. The changes will probably be limited to the msp430-libc repository; if you follow that, use the pab/ti_headers branch, as master is still used for the legacy headers. I'm not manually following the msp430-libc repository yet. If I just continue following the mspgcc4 repository and building with buildgcc.pl, will I automatically get the new libc release if I do a git pull on mspgcc4 and re-run buildgcc.pl after the new libc release has been made? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Regarding support of msp430G2231 and msp430G2211 in mspgcc4
The memory layout of the G2231 appears to be the same as for the F2011. Try using -mmcu=msp430x2011 on the command line. Version 20101006 mspgcc4, if built with the TI headers, should have an msp430g2231.h include file. Include that file explicitly instead of msp430.h or io.h or any of the other ways that might otherwise require preprocessor directives to figure out which header is required. Peter On Wed, Nov 10, 2010 at 2:07 PM, suresh kumar suresh...@yahoo.com wrote: Hi, I am working with controller msp430G2231.But this processor is not supported by mspgcc4. when I compile I am getting an error due to controller is not in list which is handled by mspgcc4.I checked the all the processor header files in include folder.But these processor header files are not defined.Can anyone guide how I can proceed further. Thanks Regards Suresh -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Regarding support of msp430G2231 and msp430G2211 in mspgcc4
Alright, I've added support for the Value Line chips MSP430G2201, MSP430G2211, MSP430G2221, and MSP430G2231. Use the standard msp430x2201-style mcu tags. Will be in the updated release later today. You must use the TI headers for these; they're not supported in the legacy msp430-libc. These are the *only* value-line (G2xx) chips that can be supported directly. There is no corresponding standard MSP430F chip for these four. All others, such as MSP430G2131 (1KB flash / 128b RAM), have a different memory layout than the corresponding chip, such as MSP430F2131 (8KB flash / 256 b RAM). As such, there is no way to distinguish them without creating new infrastructure that incorporates what used to denote the memory type (F) rather than genericizing it with an X or an underscore. Hope this doesn't confuse anybody, and that non-value-line chips in the 22x1 generation/series/family aren't added before I complete the uniarch revisions which will get rid of this mess. At that point, you'll have to specify the exact chip name (mcu=msp430g2031). Peter On Sun, Nov 14, 2010 at 12:43 AM, Michael Heidinger mch.heidin...@gmx.dewrote: I also use this mcu, but can you please implement it as a own mcu? This workaround causes much confusing, adding it as a own mcu would clean this up. Thank you Michael On 11/13/2010 07:31 PM, suresh kumar wrote: Hi Peter, Thanks a lot for your guidance.Now I am able to compile and execute my program. with mmcu settings specified you,I am able to run my program including io.h header. I even verified by using TI headers,Now I am able to run my program. Regards Suresh --- On Wed, 11/10/10, Peter Bigotp...@peoplepowerco.com wrote: From: Peter Bigotp...@peoplepowerco.com Subject: Re: [Mspgcc-users] Regarding support of msp430G2231 and msp430G2211 in mspgcc4 To: GCC for MSP430 - http://mspgcc.sf.net; mspgcc-users@lists.sourceforge.net Date: Wednesday, November 10, 2010, 12:23 PM The memory layout of the G2231 appears to be the same as for the F2011. Try using -mmcu=msp430x2011 on the command line. Version 20101006 mspgcc4, if built with the TI headers, should have an msp430g2231.h include file. Include that file explicitly instead of msp430.h or io.h or any of the other ways that might otherwise require preprocessor directives to figure out which header is required. Peter On Wed, Nov 10, 2010 at 2:07 PM, suresh kumarsuresh...@yahoo.com wrote: Hi, I am working with controller msp430G2231.But this processor is not supported by mspgcc4. when I compile I am getting an error due to controller is not in list which is handled by mspgcc4.I checked the all the processor header files in include folder.But these processor header files are not defined.Can anyone guide how I can proceed further. Thanks Regards Suresh -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -Inline Attachment Follows- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev -Inline Attachment Follows- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Mspgcc-users mailing list
[Mspgcc-users] mspgcc4 20101114 released
Version 20101114 of mspgcc4 has been released. Highlighted bug fixes: - SF 3109143: Support value-line MSP430G22x1 devices - SF 3090697: Adding mspgcc4 support for msp430G series - SF 3103015: Bug in strtol, implies ldiv bug - SF 3094472: TI headers define assembler-incompatible constants - SF 3094467: iomacros.h requires #define __MSP430_TI_HEADERS__ - SF 3090574: -fPIC silently won't work - SF 3087663: internal compiler error - SF 3096352: Illegal disassembly instruction (addx.a R14,R15) The default compiler has been updated to gcc 4.4.5. Furthermore, the TI header variant of msp430-libc has been made the default, as it is required for the G2xx value-line chips, and in general is better anyway. Users who relied on the register bit structures in the legacy headers should port their code or select the legacy header variant of msp430-libc. All please note: SF 3103015 was due to an unintentional ABI change introduced either when mspgcc was first ported to the GCC4 series, or during that series. If strtol or strtoul ever worked for you, you were lucky; similarly, ldiv would return garbage. The details are below for anybody who's interested. There is a 20101114 version of the TI header variant of msp430-libc; the legacy variant remains at 20101113, since it does not support the MSP430G22x1 devices and I'd already prepared that release. Downstream packagers please proceed to do your magic, and post here when packages are available. Thanks. Peter commit b65f5ec7fc69ffdaff2a4fcb6deb6a01a1180ece Author: Peter A. Bigot pabi...@users.sourceforge.net Date: Mon Nov 8 00:17:18 2010 -0600 SF 3103015: Bug in strtol, implies ldiv bug mspgcc was designed to return struct/union values that do not exceed 8 bytes in registers; the RETURN_IN_MEMORY macro was defined in msp430.h to enable this. In GCC4, that macro was renamed to TARGET_RETURN_IN_MEMORY, which is not defined consequently resulting in the GCC default behavior (any type that is a BLKmode is return in memory regardless of size). The stdlib/ldiv.S source assumed that the register return values from __divmodsi4 could simply be left in place, so the return value of any invocation of ldiv was whatever garbage happened to be in the stack at the point-of-call. Changing the ABI back to the mspgcc3 standard is not appropriate within this release series. It may be done upon the uniarch revisions that resume use of mspgcc (vice mspgcc4) for the updated compiler. Rewrote ldiv.S to store the structure return value in memory. Note that, although div(3) also returns values in structs, GCC categorizes that struct as an SImode rather than a BLKmode and it is still returned in registers. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] optimizations and (mis)alignment of instruction operands
Historically I've worked around this by forcing the buffer to be aligned,
but that's not the right solution. I've seen other hints that mspgcc
doesn't handle non-aligned byte accesses correctly.
Based on a quick test with GCC/intel, something like this should work.
Please create a ticket on the mspgcc4 SourceForge project bug tracker so I
have somewhere to hang some test code. What you have below is clear and
sufficient; no more details necessary. Thanks.
Peter
On Tue, Nov 16, 2010 at 10:44 AM, Alexandre Boeglin
alexandre.boeg...@inria.fr wrote:
Hello,
I'm currently working with Contiki, on a platform that uses a
MSP430F1611 uC.
I'm using the git branch of mspgcc4, with gcc version 4.4.5 and libc
version ti_20101114.
Here are excerpts of the source code i'm trying to compile, preprocessed
using the -E option:
void *packetbuf_dataptr(void);
struct cxmac_hdr {
uint8_t dispatch;
uint8_t type;
};
struct cxmac_hdr *hdr;
hdr = packetbuf_dataptr();
if(hdr-dispatch == 0 hdr-type == 0x13) {
[...]
}
The packetbuf_dataptr() function returns a pointer inside a byte array.
The index of the returned pointer depends of the length of the header of
a received packet.
So, even if the byte array that is used to store the packet is aligned
on an even address, the returned pointer can be an odd address if the
header length length is odd.
When compiling with -O0, everything's fine, as byte variants of the mov,
tst and cmp instructions are used:
601c: b0 12 a0 88 call#0x88a0
6020: 84 4f 1c 00 mov r15,28(r4) ;0x001c(r4)
6024: 1f 44 1c 00 mov 28(r4), r15 ;0x001c(r4)
6028: 6f 4f mov.b @r15, r15
602a: 4f 93 tst.b r15
602c: 1b 20 jnz $+56;abs 0x6064
602e: 1f 44 1c 00 mov 28(r4), r15 ;0x001c(r4)
6032: 5f 4f 01 00 mov.b 1(r15), r15 ;0x0001(r15)
6036: 7f 90 13 00 cmp.b #19,r15 ;#0x0013
603a: 14 20 jnz $+42;abs 0x6064
But when compiling with -Os, the two tests inside the if condition are
merged into one single cmp instruction:
567c: b0 12 8a 6a call#0x6a8a
5680: bf 90 00 13 cmp #4864, 0(r15) ;#0x1300, 0x(r15)
5684: 00 00
5686: 0d 20 jnz $+28;abs 0x56a2
And in the event that r15 contains an odd address, its LSB is discarded,
and the comparison is done against wrong bytes of the array.
I believe this is a bug, but I'm not really familiar with gcc internals.
Should I fill in a bug report ? Do you need additional details ?
Is there an optimization option I could disable without too many side
effects (I still need the size optimization for the code to fit on the
uC)?
Best regards,
Alexandre Boeglin
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] mailing list administrivia
Two points: 1) I propose to change the list management so that email to it from people who are not subscribed is immediately bounced (saying that the list requires subscription for posting), rather than put into a pending bucket where Chris or I have to look at it. If it's worth our time to read, it's worth the sender's time to subscribe so they can see responses. 2) Anybody who subscribes from an address that implements a screening filter like Boxbe so that mail to the list results in a request to add yourself to the recipient's Guest List will be summarily unsubscribed. Maybe I'll send an email saying why. I won't bother to add myself to your guest list to tell you that it's happened. Manage your spam without inconveniencing me, thank you very much. Comments on either of these? Peter -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mailing list administrivia
Looks like your signatures come as application/pgp-signature. I'll look into whether that can easily be made an exception. While I don't want to discourage patches, I also don't want to fill everybody's mailbox with them. The current build mechanism makes applying patches very difficult, so few readers would benefit from seeing them in isolation. (I definitely don't want to see patches to the patches that are in mspgcc4; too confusing.) I prefer that any real problem be backed by a bug artifact on the sourceforge tracker (either mspgcc or mspgcc4; mspgcc4 will go legacy come the millennium and I actually get a chance to complete the uniarch revisions). Patches attached to bug reports are a lot easier to deal with. Peter On Wed, Nov 17, 2010 at 3:09 AM, Robert Spanton rspan...@zepler.net wrote: On Tue, 2010-11-16 at 11:35 -0600, Peter Bigot wrote: 1) I propose to change the list management so that email to it from people who are not subscribed is immediately bounced (saying that the list requires subscription for posting), rather than put into a pending bucket where Chris or I have to look at it. If it's worth our time to read, it's worth the sender's time to subscribe so they can see responses. Any chance we can also have the 'no attachments' rule lifted? It's quite annoying that I have to remember to turn GPG signing off for every email that I send to this list. Hard work for patch submitters too... Cheers, Rob -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mailing list administrivia
Thanks for the responses. (1) has been implemented. Unsubscribed posters will promptly get a response saying: mspgcc-users does not accept postings from non-members. Please resubmit your post after subscribing at: https://lists.sourceforge.net/lists/listinfo/mspgcc-users If you think that your messages are being rejected in error, contact the mailing list owner at mspgcc-users-ow...@lists.sourceforge.net. If you wish to file a bug report, please enter a ticket at: https://sourceforge.net/tracker/?group_id=42303atid=432701 I hope that will be a good compromise. The user whose Boxbe account provoked (2) has not resubscribed AFAIK, though I did try to forward this to him/her in explanation. Signatures attached using application/pgp-signature should now pass. I'm afraid to make more significant changes to the content filters since what's there now seems to mostly work. The list's reply-to behavior was also raised. Until now, the Reply-To has rewritten to appear to come from the list, so that all responses go to the list. This improves the visibility of discussions by avoiding loss of answers that others might find interesting. However, it makes it fairly difficult (at least using gmail) to respond directly to the poster: one must hand-copy the sender's address. As of this message, I'm trying the alternative: direct replies should go to the poster, while group reply (reply-all) should go to both. This is the default and recommended behavior for mailman lists. We may lose a little public discussion until people get used to this, but I do want to give it a try. If you have strong preferences for the existing behavior, speak up. (Using group-reply, of course.) We now return you to your regularly scheduled bug reports. Peter On Tue, Nov 16, 2010 at 11:35 AM, Peter Bigot p...@peoplepowerco.com wrote: Two points: 1) I propose to change the list management so that email to it from people who are not subscribed is immediately bounced (saying that the list requires subscription for posting), rather than put into a pending bucket where Chris or I have to look at it. If it's worth our time to read, it's worth the sender's time to subscribe so they can see responses. 2) Anybody who subscribes from an address that implements a screening filter like Boxbe so that mail to the list results in a request to add yourself to the recipient's Guest List will be summarily unsubscribed. Maybe I'll send an email saying why. I won't bother to add myself to your guest list to tell you that it's happened. Manage your spam without inconveniencing me, thank you very much. Comments on either of these? Peter -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Right way to contribute patches to msp430-libc?
Create a Bugs tracker ticket on the mspgcc4 sourceforge project and attach your patch to that. If the changes are to the headers themselves, I may have to push them upstream to TI. Peter On Fri, Nov 19, 2010 at 2:57 PM, Ben Ransford ransf...@cs.umass.edu wrote: Hello, What's the right way to contribute patches to msp430-libc-ti_20101114, the version that mspgcc4's build script builds by default? For now, I've modified mspgcc4/do-libc.sh to optionally apply a patch after downloading the libc tarball from SourceForge, but I'd like to submit my changes as far upstream as possible. FWIW, the msp430-libc patch I'd like to contribute makes the header files compatible with LLVM+clang, which now has a workable MSP430 backend. The most significant change gives address-pinned globals like P1IN external linkage so that they don't get emitted as common symbols. AFAICT mspgcc is violating the C standard by *not* emitting them as common symbols now, given the way they're declared. -ben -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] __no_init equivalent?
Dunno. What does __no_init do in IAR? Or, more importantly, what does it do in TI's example code? Peter On Fri, Nov 19, 2010 at 5:49 PM, Mark J. Blair n...@nf6x.net wrote: I'm porting some TI example code which uses the __no_init keyword, and I'm having trouble figuring out whether there's an equivalent for it in GCC, and/or if it's something I can simply ignore/omit. Assuming that I correctly understand what __no_init does in IAR, will GCC automagically do the right thing for any global variables without initializers? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] __no_init equivalent?
To expand on what Chris said: The .noinit section is an alias for the .infomemnobits section. Using __attribute__((section(.infomem))) causes the storage for the variable to be placed in one of the MCU's information memory blocks. In the current implementation, there are two: .infomem is a catenation of two or four blocks, depending on chips, that is marked for initialization. This allows you to place, for example, a state structure in non-volatile memory and provide an initial value for it. If no global initializer is present, then the object file incorporates zeros to initialize it. .infomemnobits is an alternative section that is supposed to overlay .infomem, but does not include initial data in the object file. This might be appropriate for things like the information memory sections on old devices that contained chip-specific calibration constants (these are now stored in the TLV structures), or application data that should survive a firmware update. Building a program that mixes .infomem and .infomemnobits assignments results in undefined behavior. Thus, there are really two distinct issues: preventing initialization of the memory (either at the time the image is programmed, if in flash, or at power-on-reset, if in RAM) and placing the variable into memory (either at an arbitrary location in the data region of flash, with the section infomem attribute, or at a specific address using the asm syntax). If you use asm statements to place variables in RAM, that region will be zeroed on a power-on-reset, along with the rest of RAM. Perhaps the IAR/CCS __no_init directive is intended to inhibit this. If so, I don't believe msp430 gcc has an equivalent capability. I was peripherally (hah!) aware that the MSP430 chips with USB support overload parts of RAM to use for USB structures. I have not yet added explicit support for that. Perhaps offline we can talk about the details, and I'll add that feature in the uniarch updates, which are much more friendly to supporting chip-specific memory layouts. (BTW: The specific syntax for placing variables in information memory will be enhanced in uniarch, as I want to be able to identify individual information memory sections, allowing you to have some that are initialized and some that are not. I'll be as backwards-compatible as I can, but one enhancement is likely to be that nobits will be a separate attribute from the section attribute, so we don't have to have two linker sections defined for each flash memory block.) Peter On Sat, Nov 20, 2010 at 12:47 PM, Mark J. Blair n...@nf6x.net wrote: On Nov 20, 2010, at 10:40 AM, Chris Liechti wrote: positioning variables is also quite easy: int im_in_infomem_on_a_2xx asm(0x1000); but this will not work with initialized variables. Aha! I'll give that a try. I found that my first attempt with symbols defined in a little .S file works well enough to let the device enumerate on the USB bus (yay!), but I'll see if I can get handle things more cleanly this way. Thanks! I'll continue to dig in to the linker operation, since I still have a lot to learn about how it maps things to memory. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] __no_init equivalent?
Thank you; I had not noticed .noinit specifically before, and misinterpreted a too-rapid scan of the source. Data marked in noinit does indeed appear in RAM, following the unqualified data which goes in the .bss section and is initialized. Delete that first sentence and I think the rest of what I wrote is correct (if not necessarily relevant). I suspect assigning a specific address using asm, though, overrides this and makes the section irrelevant. In any case, I believe there may need to be a different linker script used for these devices when the USB is to be enabled, to ensure program variables don't end up creeping in the area reserved for USB. Yet another variation point Peter On Sat, Nov 20, 2010 at 2:46 PM, Chris Liechti cliec...@gmx.net wrote: Am 20.11.2010 20:38, schrieb Peter Bigot: To expand on what Chris said: The .noinit section is an alias for the .infomemnobits section. i do not think so. .noinit is the name of a section in RAM. it is specified in the linker scripts. at least, that was the case for mspgcc (3) and if the behavior was different, a number of programs of mine would no longer work ;-) chris -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] __no_init equivalent?
On Sat, Nov 20, 2010 at 3:06 PM, Mark J. Blair n...@nf6x.net wrote: On Nov 20, 2010, at 1:00 PM, Peter Bigot wrote: I suspect assigning a specific address using asm, though, overrides this and makes the section irrelevant. In any case, I believe there may need to be a different linker script used for these devices when the USB is to be enabled, to ensure program variables don't end up creeping in the area reserved for USB. Yet another variation point Are you aware of any other MSP430 peripherals which steal memory blocks like the USB interface? Not at this time. It might have been done with the CC430 line to put the radio buffers in memory, though that could have been too big a change in the internal architecture. I don't know what's done on the chip that has a bluetooth stack built in (msp430bt5190, which is really an msp430f5438 optimized for use with a CC2560, according to the guy at TI who explained how they broke their part numbering scheme with that chip). If this is something that we'll see more of as TI creates more MSP430 variants, then it may be necessary to devise a clean, generalized way to deal with varying memory maps within a given part. Maybe just defining different part ID variants (e.g. -mmsp430f5529usb, -mmsp430f5529nousb, etc.) would be good enough, or maybe that would become too cumbersome if there's ever a part with a lot of memory map variability. Oh yeah. We're definitely going with a solution that doesn't increase the number of part numbers. Probably a linker option that alters the selection of the ldscript that's used. Though I do want to remain compatible with how Code Composer Studio approaches the problem. Would you mind filing a bug report asking for this (prevent use of USB-reserved memory on relevant devices), so I don't forget it? Thanks. Peter -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] __no_init equivalent?
A single report is fine. Thanks. Yes, it appears the USB section of RAM was not incorporated in the device list I got from TI, so you should be safe from potential assignment collisions. I'll look at the linker scripts in Code Composer when I deal with the bug, but if that's the model they use those chips will always have a USB memory section defined, and if you want to use it as normal RAM you'll have to assign variables to it explicitly using the section attribute. You could probably avoid the assembler file with a simple: uint8_t USBMEM[2048] asm(0x1c00); in your C source somewhere. Peter On Sat, Nov 20, 2010 at 3:25 PM, Mark J. Blair n...@nf6x.net wrote: On Nov 20, 2010, at 1:15 PM, Peter Bigot wrote: Would you mind filing a bug report asking for this (prevent use of USB-reserved memory on relevant devices), so I don't forget it? Thanks. No problem, I'll do that. Shall I file two separate reports, with one asking to prevent mis-use of the USB RAM when the USB interface shall be used, and another asking for a way to return the USB RAM to the general pool if the USB interface won't be used? Or shall I combine both of those into a single report? I'm beginning to study the msp430f5529 linker scripts now, and they don't appear to define the existence of the USB RAM (0x1C00-0x23FF) at all. If I understand this correctly, does this mean that the linker won't try to place any general variables into the USB memory, and my current technique (hack?) of not allocating the USB endpoint buffers in C code and simply defining their symbol addresses in an assembler file is likely to work (even if it's not the ideal way to do this)? -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
