Hi all, I'm new to mspgcc so bear with me if these topics are repetitive, but
The stdio.h seems incomplete - FILE and fopen(), fclose(), etc. appear to be missing. This is raising havoc with a port I'm working on which is "ANSI" C. I'm puzzled how a C99 compiler and libc can have a subset of stdio any ideas on the best way to resolve it? Thanks /steverino2 -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, February 25, 2009 5:22 AM To: [email protected] Subject: Mspgcc-users Digest, Vol 33, Issue 20 Send Mspgcc-users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/mspgcc-users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Mspgcc-users digest..." Today's Topics: 1. Re: Volatiles are miscompiled (Dmitry Dikiy) 2. Re: Connection failure during close and re-open msp430-gdbproxy by msp430-insight (Matthias Hartmann) 3. strange things happening with -save-temps (JMGross) 4. Re: strange things happening with -save-temps (Sergey A. Borshch) 5. Re: error w/msp430x54xx.h in win release mspgcc-20081230.exe (JMGross) 6. Re: 64K code limit? (JMGross) 7. Re: error w/msp430x54xx.h in win release mspgcc-20081230.exe (Sergey A. Borshch) ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Feb 2009 00:34:14 +0300 From: Dmitry Dikiy <[email protected]> Subject: Re: [Mspgcc-users] Volatiles are miscompiled To: "GCC for MSP430 - http://mspgcc.sf.net"; <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Ok, may be I'm here... :) volatiles are ... difficult. from the point of view of the compiler the 'volatile' qualifier means nothing else but 'the compiler does know how the variable is evaluated'. That's it. So, - one can find a perfect example which will break the compiler's behaviour. - one may learn a bit from the past experience if the 'V' qualifier is absolutely necessary (it there a chapter in docs about this? :) ) - one may find a way which is most suitable for the particular case. Like interrupt source, semaphores, etc. other? - if you fill the thing does not work properly - ask and show us why or where :) then fix it :) I did not use any other compiler than gcc for last 20 years (except one from arm, but this is a different story)... Volatiles worked :) Cheers, ~d P.S. Chris, thanks for the good explanation. ...and the stuffmaintenance. Keep doing this fine thing. Chris Liechti ?????: > i don't have a smart comment except: > > - on msp430 it's perfectly possible to read-modify-write to peripherals. > that's what the original 3.2.3 code was doing on all volatiles. Dmitry > implemented an optimization so that bis/bic instructions are emitted > where possible. > > - except for the watchdog and flash controller... where the example they > are showing in the paper would never be used by a developer. > WATCHDOG=WATCHDOG is nonsense as the MSP430 watchdog by design reads a > different value that it is required to write, causing the WDTPW to be > wrong. so even if GCC would read the register and write it back, it > would still reset. > > - volatile access only disables caching, it doesn't protect against > incomplete data for larger data types. that is, if one function reads > a 32 bit value while the interrupt function modifies that data, it can > read intermediate values. the correct thing to do is to disable > interrupts during the data structure access. that's easiest done with > a separate access function, marked with the "critical" attribute. > (see ringbuffer in libmspgcc for an example) > > - if there is a bug, it's open source feel free to provide patches ;-) > > chris > > John Porubek schrieb: > >> Not sure if this has been discussed previously, but it's worth a >> mention if not. This is not MSP430 specific (although the referenced >> paper does mention the GCC port to the MSP430), but applies to anybody >> using C or C++ for development. A colleague showed me an item in the >> February 2009 issue of Embedded Systems Design magazine written by >> Jack Ganssle that is both interesting and scary. In a nutshell, >> compilers sometimes miscompile code using "volatile" qualifiers. See: >> >> http://preview.tinyurl.com/cb3sk2 >> >> It references a paper that discusses the problem in detail. URL here >> for convenience: >> >> http://preview.tinyurl.com/6pmr42 >> >> It would be interesting to hear the viewpoints on this of the compiler >> vendors who follow this group. >> >> John >> >> ---------------------------------------------------------------------------- -- >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Mspgcc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> > > > ---------------------------------------------------------------------------- -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > ------------------------------ Message: 2 Date: Sat, 21 Feb 2009 06:55:42 +0100 From: Matthias Hartmann <[email protected]> Subject: Re: [Mspgcc-users] Connection failure during close and re-open msp430-gdbproxy by msp430-insight To: "GCC for MSP430 - http://mspgcc.sf.net"; <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 I am not using spy-bi-wire, but form reading the output of msp430-gdbproxy.exe --help msp430 I would guess, you should add parameter --spy-bi-wire to the call to msp430-gdbproxy.exe. msp430-gdbproxy.exe --debug --port=2000 msp430 --spy-bi-wire USBFET Drmn4ea schrieb: > Hi, > I am running into problems keeping msp430-gdbproxy connected to the target > while using msp430-insight (msp430-gdb.exe) under win32. I am using the TI > spy-bi-wire FET (the USB side of the eZ430-RF2500 development kit) as the > programmer/debug interface to a msp430f2013, which is working reliably for > flashing and running new code on the target via msp430-jtag. > > But when running gdbproxy with Insight to debug, the connection between > gdbproxy and the FET appears to bomb out when msp430-insight closes and > re-opens the connection to gdbproxy, as it seems to do routinely in the > course of its business. E.g. attempting to download and run an executable > fails; with gdbproxy output: > > --- > P:\project>msp430-gdbproxy --debug --port=2000 msp430 USBFET > > Remote proxy for GDB, v0.7.1, Copyright (C) 1999 Quality Quorum Inc. > MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood > > GDBproxy comes with ABSOLUTELY NO WARRANTY; for details > use `--warranty' option. This is Open Source software. You are > welcome to redistribute it under certain conditions. Use the > '--copying' option for details. > > debug: msp430: msp430_open() > debug: MSP430_Initialize() > debug: MSP430_Configure() > debug: MSP430_VCC(3000) > debug: MSP430_Identify() > info: msp430: Target device is a 'MSP430F20x3' (type 52) > debug: MSP430_Configure() > notice: msp430-gdbproxy: waiting on TCP port 2000 > notice: msp430-gdbproxy: connected > debug: msp430: msp430_connect() > debug: MSP430_Registers(READ) > debug: msp430: msp430_current_thread_query() > debug: msp430: msp430_offsets_query() > debug: msp430: msp430_set_gen_thread() > debug: msp430: msp430_read_registers() > debug: MSP430_Registers(READ) > debug: msp430: msp430_write_mem(0xF800, ptr, 0) > debug: msp430: msp430_write_mem(0xF800, ptr, 0) > debug: MSP430_Memory(WRITE) > debug: msp430: msp430_write_mem(0xF824, ptr, 0) > > ...etc... > > debug: msp430: msp430_read_mem(0xFA24, ptr, 0, ptr) > debug: MSP430_Memory(READ) > debug: msp430: msp430_kill() > debug: MSP430_Reset(ALL) > debug: msp430: msp430_close() > debug: MSP430_Reset(ALL) > debug: MSP430_Close() > info: msp430-gdbproxy: session killed. Will wait for a new connection > debug: msp430: msp430_open() > debug: MSP430_Initialize() > debug: MSP430_Configure() > debug: MSP430_VCC(3000) > debug: MSP430_Identify() > error: msp430: Could not read device Register (33) > debug: MSP430_VCC(0) > error: msp430: Not supported by selected Interface or Interface is not > initialized (34) > debug: MSP430_VCC(3000) > error: msp430: Not supported by selected Interface or Interface is not > initialized (34) > debug: MSP430_Reset(ALL_RESETS) > error: msp430: Not supported by selected Interface or Interface is not > initialized (34) > debug: MSP430_Close() > error: msp430: Not supported by selected Interface or Interface is not > initialized (34) > Assertion failed: !msp430_status.is_open, file target_msp430.c, line 745 > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > > --- > > The 'global variable workaround' > (http://www.nabble.com/gdb-problem%3A-sect_index_data-not-initialized-td9076 831.html) > already is present in the .elf. As seen in other random forums posts > scattered around the web, I created a gdb.ini file (does msp430-gdb.exe > honor this?) and populated it with: > > set remoteaddresssize 64 > set remotetimeout 999999 > target remote localhost:2000 > monitor erase all > > ...with no improvement to the problem at hand. > > Has anyone seen this problem before, or better yet can suggest a fix? > > Thanks, > > Tim / Drmn4ea > ------------------------------ Message: 3 Date: Tue, 24 Feb 2009 16:30:52 +0100 From: "JMGross" <[email protected]> Subject: [Mspgcc-users] strange things happening with -save-temps To: "MSPGCC mailing list," <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="ISO-8859-1" Hi there! I'm (still) using the 2006-05-02 build of mspgcc (to avoid surprises, it's used in a productivity environment) under WinXP. Yesterday I installed the latest build (2008-12-30). Mainly because I plan to migrate to the 5436 processor and wanted to check whether mspgcc supports it. While I had to learn that the extended memory range isn't supported yet (well, one can stick with all the stuff in the lower 64K and just use the extended hardware modules for a lower price), I noticed that the latest version of mspgcc doen't like my makefiles. I always use the -save-temps option to keep the temporary files for debugging and delete them right after compilation. In case of a compiler error, make stops before deleting them. A convenient way to not clobber the code folder with unnecessary files while having them when necessary. To my surprise, the latest compiler produces empty object files if I delete the temp files. I I do not delete them, all is well, but if I delete them (even manually after the compiling and linking is done), the next compilation run results in an empty object file and a list file that reads 'no symbols, no code'. Does anyone know why this is happening now? Of course I can remove the option from the makefile and insert it only when necessary, but I don't like the idea of constantly changing the makefile - as well as I don't like all the temporary files clobbering my source folder(s). For now, I have switched back to the old compiler, but when I ever want to use the newwer processors, I have to switch sooner or later (and pray that the new compiler won't break the old code through new and unexpected optimisations), so this change in the compiler behaviour is still an issue for me. Any comments or hints or explanations are welcome. And sorry that I didn't scan the last 3 years of the mail archive for a mail that fits. I just checked the last 2 months and found nothing. JMGross ------------------------------ Message: 4 Date: Tue, 24 Feb 2009 19:22:13 +0200 From: "Sergey A. Borshch" <[email protected]> Subject: Re: [Mspgcc-users] strange things happening with -save-temps To: [email protected], "GCC for MSP430 - http://mspgcc.sf.net"; <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed JMGross wrote: > I always use the -save-temps option to keep the temporary files for debugging and delete them right after > compilation. In case of a compiler error, make stops before deleting them. A convenient way to not clobber the code > folder with unnecessary files while having them when necessary. > > To my surprise, the latest compiler produces empty object files if I delete the temp files. I I do not delete them, all is > well, but if I delete them (even manually after the compiling and linking is done), the next compilation run results in > an empty object file and a list file that reads 'no symbols, no code'. I can reproduce this behavior with two -save-temps in gcc command line. With one -save-temps everything looks ok. > Does anyone know why this is happening now? I think it's because mingw32/msys build. Toolchain built from the same sources under linux works fine. That's all I can say for now. -- Regards, Sergey A. Borshch mailto: [email protected] SB ELDI ltd. Riga, Latvia ------------------------------ Message: 5 Date: Wed, 25 Feb 2009 13:05:46 +0100 From: "JMGross" <[email protected]> Subject: Re: [Mspgcc-users] error w/msp430x54xx.h in win release mspgcc-20081230.exe To: "MSPGCC mailing list," <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="ISO-8859-1" > swallen wrote: >> WDT_A register is defined wrong per the datasheet (). >> >> from the listing: >> 00000150 l *ABS* 00000000 WDTCTL >> >> from datasheet (SLAS612?SEPTEMBER 2008): >> >> REGISTER BASE OFFSET >> WDTCTL 0150h 0Ch (=0x15C) >> >Yes, you are right. Wrong offset in wdt_a.h. Fixed in repository: >http://mspgcc.cvs.sourceforge.net/viewvc/mspgcc/msp430-libc/include/msp430/ wdt_a.h?r1=1.3&r2=1.4 It's not the only bug in wdt_a.h: #define WDTPW (0xA5<<8) should read #define WDTPW (0x5A<<8) Looks like the WDT is not often used ;) Some thing I had to fix in the default startup code is the default disabling of the WDT. Of course copying the initialized data into RAM is a lot faster if you don't have to toggle the WDT in between, but it renders the WDT useless for any application where WTD resets might be cause by ESD influence - if the processor crashes again (due to continued ESD influence) while copying the data, the device will never recover until manual reset. It took quite some time after starting with MSPs and mspgcc until I noticed that the WDT is silently disabled right after reset and all triggering of it was void. A wrong password together with a wrong register address wouldn't have changed anything ;) Fixing the startup code suddenly showed up a LOT of timing problems in the current projects where the WDT was suddenly causing a reset. JMGross ------------------------------ Message: 6 Date: Wed, 25 Feb 2009 13:25:41 +0100 From: "JMGross" <[email protected]> Subject: Re: [Mspgcc-users] 64K code limit? To: "MSPGCC mailing list," <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="ISO-8859-1" From: Hugh Hartwig <hhart...@be...> - 2009-01-26 16:43 >So there is a way to compile and link up to 64K. When I compile for the >2618 it fails to link above 45K (3K for boot code) because of the location >of .vectors. The linker file defines .fartext, but it doesn't seem to take >advantage of this additional code space. Is there an attribute flag that >will specify the location of code to this .fartext region? The linker doesn't support sections with holes. Since the vectors are at 0x0ff80, the .text section can only extend to 0x0ff7f. Unfortunately the compiler automatically places everything into the ..text section. you could place a function into the (for the linker defined) .fartext section by using the __attribute__((section (".fartext"))). But calling these functions requires a CALLA command instead of the normal CALL as well as a special return command (polling a 32 bit instead of a 16 bit return address from stack). The compiler won't generate them, so the code cannot be executed in the .fartext section. Without compiler support for the 430X command set, the .fartext section can only be used for data. And accessing the data must be done by a self-written assembly function using the 430X commands for 20 bit access. Also, since the compiler does not know about .fartext except that it is a separate section of arbitrary location, it will issue a section attribute error when you try to place code AND data into it by using the __attribute__((section (".fartext"))). Anyway, if you have a big precalculated table (like a sinus table), you can place it in .fartext and access it with your own assembly code, freeing up a lot of the normal 64k area. Better than nothing. A good opportunity for designated math library or a printf_F function for format text constants placed in .fartext JMGross ------------------------------ Message: 7 Date: Wed, 25 Feb 2009 15:21:55 +0200 From: "Sergey A. Borshch" <[email protected]> Subject: Re: [Mspgcc-users] error w/msp430x54xx.h in win release mspgcc-20081230.exe To: [email protected], "GCC for MSP430 - http://mspgcc.sf.net"; <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1251; format=flowed JMGross wrote: >> swallen wrote: >>> WDT_A register is defined wrong per the datasheet (). >>> >>> from the listing: >>> 00000150 l *ABS* 00000000 WDTCTL >>> >>> from datasheet (SLAS612?SEPTEMBER 2008): >>> >>> REGISTER BASE OFFSET >>> WDTCTL 0150h 0Ch (=0x15C) >>> >> Yes, you are right. Wrong offset in wdt_a.h. Fixed in repository: >> http://mspgcc.cvs.sourceforge.net/viewvc/mspgcc/msp430-libc/include/msp430/w dt_a.h?r1=1.3&r2=1.4 > > It's not the only bug in wdt_a.h: > > #define WDTPW (0xA5<<8) > > should read > > #define WDTPW (0x5A<<8) This was fixed even early: http://mspgcc.cvs.sourceforge.net/viewvc/mspgcc/msp430-libc/include/msp430/w dt_a.h?r1=1.2&r2=1.3 > Some thing I had to fix in the default startup code is the default disabling of the WDT. It's very simle: just add function named __low_level_init() with __attribute__((naked, section ".init3")) into your project. It replaces default peripheral init function. Library function looks like: __attribute__((naked, section(".init3"))) void __low_level_init() { WDTCTL = WDTPW + WDTHOLD; } don't forget extern "C" if you add this function into C++ source file. You can also replace data init routines by redefining __do_clear_bss() and/or __do_copy_data() in section .init4 Don't forget __attribute__((naked))! Redefining function _reset_vector__() replaces whole startup code except C++ static objects constructors. > It took quite some time after starting with MSPs and mspgcc until I noticed that the WDT is silently disabled right > after reset and all triggering of it was void. It's not safe at all to believe in default value in any peripheral sfr. I strongly recommend to explicitly init all used sfrs even with default values. > A wrong password together with a wrong register address wouldn't have > changed anything ;) ;) -- Regards, Sergey A. Borshch mailto: [email protected] SB ELDI ltd. Riga, Latvia ------------------------------ ---------------------------------------------------------------------------- -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ------------------------------ _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users End of Mspgcc-users Digest, Vol 33, Issue 20 ********************************************
