Small correction, the cc2420 driver does not have this bug (I think). It's the CC2420x driver, which uses the rfxlink library instead of the code in chips/cc2420. And yes, this bug bit me just today on a new platform I am working on.
Cheers, - Thomas On Wed, Jun 27, 2012 at 4:01 PM, Eric Decker <[email protected]> wrote: > > The cc2420 and derived drivers (including the CC2520) have an outstanding > bug. > > I don't remember if I've fixed this in the downstream TinyProd code. I do > know that its hasn't been fixed in the development tree yet. > > I don't know what the plans are for fixing it, but it would be good if it > got fixed. > > The bug in question has been reported as: Issue 131 > > > > On Wed, Jun 27, 2012 at 5:27 AM, "Erdélyi Ádám [Edöm]" > <[email protected]> wrote: >> >> Hi, >> >> I had the same problem while interfacing CC2520 radio with MSP430F5438A >> uc. Martin's second solution eliminates the problem, but this way I cannot >> rely on any TinyOS repository if I want to publish only my platform >> implementation. >> Is there any other way to change the order of function calls during >> initialization? >> >> Adam Erdelyi >> >> Hello. >> >> On Sat, 11 Feb 2012, Eric Decker wrote: >> > I have problem with Resource.request() in SoftwareInit.init(), >> > simple code >> > (the same code as in RF230DriverLayerP.SoftwareInit.init()): >> >> > You can't do this in SoftwareInit.init. >> > Why? Because FcfsResource gets initialized via SoftwareInit.init and >> > order of initialization is not stated nor can you count on it. >> > SoftwareInit does not guarantee any ordering. >> > ----> You can't call Resource.request for a Resource that uses Fcfs are >> > the queuing mechanism. >> > Do it from Boot.booted. >> >> I read about this issue in "TOS programming book" in chapter "4.4. >> Multiple wirings". (The order of the calls is not defined.) >> >> There are following issues: >> >> 1) The standard tinyos code uses this wrong mechanism. For example (at >> least): >> ./platforms/mulle/fix/RF230DriverHwAckP.nc >> ./platforms/mulle/fix/RF230DriverLayerP.nc >> ./chips/rf230/RF230DriverLayerP.nc >> ./chips/rf230/RF230DriverHwAckP.nc >> ./chips/rf212/RF212DriverLayerP.nc >> >> 2) How to implement "LocalIeeeEui64C" on external shared bus that must be >> available before the Boot.booted() event (TEP122). >> >> > How to establish "specific initialization ordering" for >> > MainC.SoftwareInit (tep107) ? >> > >> > What are you referring to in TEP107. 107 doesn't say anything about >> > specific ordering. >> >> Yes, TEP107. >> Yes, TEP107 does not say anything _how_ to implement ordering. >> But there is statement: >> >> ... "Components whose initialization does not directly depend on hardware >> resources SHOULD wire to MainC.SoftwareInit. If a component requires a >> specific initialization ordering, then it is responsible for establishing >> that ordering. Due to the semantics of Init, this is usually quite rare; a >> component SHOULD NOT introduce initialization dependencies unless they are >> required." .... >> >> Is there some mechanism to establish call order ? >> >> I see two solution. >> >> 1) Add next initialization layer between PlatformInit and SoftwareInit. >> >> 2) Rebind "component's data initialization"/"software data init" from >> SoftwareInit.init() to PlatformInit.init(). (and modify TEP107) >> >> For example: >> >> =================================================================== >> --- tos/system/SimpleFcfsArbiterC.nc (revision 5889) >> +++ tos/system/SimpleFcfsArbiterC.nc (working copy) >> @@ -89,11 +89,11 @@ >> uses interface ResourceConfigure[uint8_t id]; >> } >> implementation { >> - components MainC; >> + components RealMainP; >> components new FcfsResourceQueueC(uniqueCount(resourceName)) as Queue; >> components new SimpleArbiterP() as Arbiter; >> >> - MainC.SoftwareInit -> Queue; >> + RealMainP.PlatformInit -> Queue; >> >> Resource = Arbiter; >> ResourceRequested = Arbiter; >> =================================================================== >> --- tos/system/FcfsArbiterC.nc (revision 5889) >> +++ tos/system/FcfsArbiterC.nc (working copy) >> @@ -96,11 +96,11 @@ >> uses interface ResourceConfigure[uint8_t id]; >> } >> implementation { >> - components MainC; >> + components RealMainP; >> components new FcfsResourceQueueC(uniqueCount(resourceName)) as Queue; >> components new ArbiterP(uniqueCount(resourceName)) as Arbiter; >> >> - MainC.SoftwareInit -> Queue; >> + RealMainP.PlatformInit -> Queue; >> >> Resource = Arbiter; >> ResourceRequested = Arbiter; >> =================================================================== >> >> M.C> >> >> >> >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
