[Tinyos-devel] Update on mspgcc development series

Jacob Andersen jacand at cs.au.dk
Wed Feb 8 14:17:43 PST 2012

Hi list,

About a month ago, I did some experiments with the 4.6.1-based mspgcc on 
tmotes. Among other things, I installed UDPEcho on a number of Tmotes to 
form a small mesh network and observe the behaviour of network 
programming (with nwprog) over several RPL-hops (the results were not 
good when programming over several hops, but this is not the subject of 
this mail). In the process of setting up this experiment, I ran into a 
couple of problems with the TinyOS build system (in addition to those 
listed by Peter in the previous mail). Alas, I did not take any notes at 
the time, so I have probably forgot some of them, but here goes from the 
top of my head:

When building an image to be installed along with TOSBoot, the linker 
flag --defsym=_reset_vector__=0x4000 is set in 
support/make/tosboot.extra. Unfortunately, this causes the linker to 
conclude that the startup code from crt0 (initializing the stackpointer, 
.data, and .bss sections) is unreachable and thus optimised out. I did 
not find any obvious way to avoid this and ended up removing the 
--defsym from tosboot.extra and afterwards hand-editing the vector table 
in the resulting .ihex images of the applications.

The optimizer in the new compiler seems to be a lot more aggressive. One 
instance, I noted, is in tos/lib/tosboot/telosb/hardware.h, where the 
wait() function contains an empty for-loop which is optimized out. This 
is likely to happen in other places as well, so th lesson is: be 
generous with the "volatile" keywords ;-)

As far as I can tell, the watchdog is kept on by default in the new crt0 
scripts. As far as I remember, there is a linker flag or preprocessor 
macro which will change this. I just remember the problem popping up 
with the TOSBoot bootloader, which did not turn off the watchdog 
(because the author of TOSBoot assumed this is done in crt0) and ended 
up in an infinite reset-loop...


Den 08/02/12 18.59, Peter Bigot skrev:
> Phil asked that I send this out: although the upcoming TinyOS release
> is targeted to the (patched) LTS 20110716 mspgcc which is based on gcc
> 4.5.3, some may be interested in using the current development series,
> which is based on 4.6.1 and includes a variety of enhancements that
> will eventually add 20-bit support.
> A bug was reported at
> https://sourceforge.net/tracker/?func=detail&aid=3482629&group_id=42303&atid=432701
> that this version does not work with TinyOS.  In fact, the problems
> with that are not with mspgcc, but known issues in TinyOS:
> * https://sourceforge.net/tracker/?func=detail&aid=3153727&group_id=56288&atid=480036
> is a nesC bug that must be fixed.  I believe this has been fixed for
> the nesC currently packaged for TinyOS.
> * https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2011-November/005057.html
> notes the need to remove any use of genericized MCU identifiers from
> MSP430-based platforms.  I don't know whether this has been done, but
> want to remind everybody that it's important, and that it's OK to do
> it now (the LTS version supports both specific and genericized MCU
> identifiers).
> * https://sourceforge.net/tracker/?func=detail&aid=3468269&group_id=56288&atid=480036
> is another nesC bug that results in an error if a structure includes a
> bitfield for which the base time is larger than the unsigned integer
> type.  Technically doing this isn't valid C, and I don't know if
> anything other than OSIAN uses the feature (it was useful to extract
> data from an EUI64), but to my knowledge this issue has not been
> fixed.
> When these issues are addressed, the current development series of
> mspgcc has worked fine for me on TinyOS/OSIAN applications.  The 4.6.x
> series, and msp430-specific enhancements in it, is likely to
> significantly reduce code size (one user reported 2KB smaller than LTS
> with -Os; though that might be as little as 3% depending on the
> original size, it's still significant if you were running that close
> to the maximum code size).
> Peter (can't remember whether I'm allowed to email tinyos-devel since
> I'm not actively subscribed, so if this doesn't show up there somebody
> on bcc'd core please forward; thanks)
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

More information about the Tinyos-devel mailing list