-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
preventing Lpl getting stuck after shutdown #263
base: master
Are you sure you want to change the base?
Conversation
This commit fixes the problem of DefaultLpl from cc2420 getting stuck in EBUSY state after the radio is turned off. The update solves a bug that I observed and the fix takes care of it. The fix also addresses one potential bug that I haven't seen (thou I had not run enough experiments to wait for it to happen). Both situations occur when the cc2420 radio is turned off from the ActiveMessage layer while sending a packet. Both bugs are presented on the figures from the files uploaded to: http://www.cs.columbia.edu/~msz/wsn/default_lpl_bug/ The first bug ( on the figures with the files named DefaultLpl_bug.* ) happens when Csma completes transmission of a packet and reports sendDone followed by stopDone. The sendDone signal is used by DefaultLpl to clear its S_LPL_SENDING state; however, it does not go to the idle state if the last transmission before shutting down was not acknowledged, while it should be. This results from DefaultLpl getting stuck in S_LPL_SENDING. The second (potential) bug ( on figures with the files named DefaultLPL_potential_bug.* ) may happen when DefaultLpl received sendDone and goes to the idle state, but before it receives the stopDone signal from the PowerCycle, it already receives send call to transmit another message, which again keeps this module in S_LPL_SENDING state. These bugs have a wider impact that just the scope of this module. When DefaultLpl stays in S_LPL_SENDING state, it does not signal sendDone. As a result of that, the UniqueSend is also stuck in a busy state, as well as other modules that are waiting for the sendDone signal; example AMQueueImplP stays EBUSY until it receives sendDone. Best, |
This looks like a reasonable patch. One suggested change: could you change the name of SplitControlState to SubControlState so the binding between the two is clearer? I'll merge the pull once you do. Thanks! |
- remove not used variable dutyCycling - remove useless interface Init
The name change has been applied and tested. It's ready to be merged. |
- remove not used variable dutyCycling - remove useless interface Init
proposing changes to DefaultLPL from cc2420 radio stack, that fix the problem of the module getting stuck after radio is turned off as a result of the ActiveMessage SplitControl.stop() call.