TI E2E Community (Beta)
Welcome to the TI E2E (Engineer-to-Engineer) Community! We invite you to freely and openly interact with your peer Engineers, TI Engineers, and other experts in order to ask questions, share knowledge, explore ideas, and help solve problems.
More Search Options

Output Buffer Full causes network lockout

rated by 0 users
Not Answered This post has 0 verified answers | 4 Replies | 2 Followers

Not Ranked
4 Posts
Community Member
Shawn Lord posted on 4 Nov 2009 10:11 AM

Setup:

I have a network that consists of an Access Point with an End device and multiple End Devices.  One of the End devices is designated as a polling end device with the messages queued on the Access Point.  Messages for the polling end device are generated by the software running on the same chip as the AP so packets sent to the polling device are queued. 

Problem:

The problem lies in when the polling EP loses power or shuts down (full power off not sleep).  When this happens, the queue on the access point fills with messages for the EP.  Once this happens the AP is completely locked and cannot send Link, Join or any other transmissions as the Output Buffer is full of packets for an EP that no longer exists on the network.

Question:

Is there a way to:

- Detect how many waiting messages are sitting in the AP output Buffer for a certain EP (this would be done by the code on the AP.

- Flush the entire output Buffer or all Messages queued for polling devices.

- Check that the Polling EP is still on the network ie. checking its messages

 

For a temporary solution, I will be trying to make sure that there is only one message sent from the application to the EP at a time before hearing an application level ack this should limit my Output Buffer overhead to 1 dead message per poling EP. This will make my output buffer unnecessarily large but is the best solution I can think of right now.

Any ideas would be greatly appreciated

Thanks,

Shawn

All Replies

Top 100 Contributor
57 Posts
Community Member

Hello.

Interesting setup you have.

The problem is that the cast-out scheme for the output queue has not been implemented. See the comment in nwk_QMgmt.c:nwk_QfindSlot() line 147.

None of the 3 remedies you suggest are currently available. The best solution would be to implement the cast-out scheme for the Tx queue. You will have to modify the stack code to do this. To get things going for your scenario, when the output queue is full  you might implement a scheme that just casts out the first frame that is in the state FI_INUSE_UNTIL_FWD or something like that. Look at the scheme for in-queue cast out, though input queue management is more complicated than you will need for output because the input queue is accessible by both the user thread and the interrupt thread so an intermediate state is needed.

This idea is off the top so I can't vouch that it is a complete solution. I leave it as an exercise for the designer...

Hope this helps.

lfriedman

Not Ranked
4 Posts
Community Member

Thanks,

I noticed the TODO notes about the output queue cast-out.  I have implemented a function to remove all frames with a state of FI_INUSE_UNTIL_FWD.  I have attached the function below for reference.  When reading through the cast out code for the incoming queue there is some order management.

 In the output queue, do you know if the order is self healing or will I need to manage the order when I am removing frames?

Thank you,

Shawn

 

Code:

/******************************************************************************
 * @fn          nwk_QflushSandF
 *
 * @brief       Look through frame queue and remove any frames tagged as
 *                 store and forward by seting the usage to FI_AVAILABLE
 *
 * input parameters
 * @param   which      - INQ or OUTQ to adjust
 *
 * output parameters
 *
 * @return      number of frames removed
 */
uint8_t nwk_QflushSandF(uint8_t which)
{
  frameInfo_t *pFI;
  uint8_t i, num, count;

  if (INQ == which)
  {
    pFI  = sInFrameQ;
    num  = SIZE_INFRAME_Q;
  }
  else
  {
    pFI  = sOutFrameQ;
    num  = SIZE_OUTFRAME_Q;
  }

  for (i=0; i<num; ++i, ++pFI)
  {
    /* if frame is waiting to be forwarded remove it*/
    if (pFI->fi_usage == FI_INUSE_UNTIL_FWD)
    {
        pFI->fi_usage = FI_AVAILABLE;
        count ++;
    }
  }
  return count;
}

Top 100 Contributor
57 Posts
Community Member

Hello.

If you remove all the frames waiting you should not have to worry about managing the order.

NOTE: In looking over the code I believe there might be a bug. Line 263 in nwk_mgmt.c:send_poll_reply() assumes that the frame being sent is in the input queue. This is true unless the AP itself has an application trying to send to a polling device. In that case the waiting frame is in the output queue.

That call as-is should not be done if the pointer returned is pointing to a frame in the output queue. There are various ways to fix this. [For example, quick (and terrible) hack would be to set fiPtr->orderStamp = 0 at line before the return in line 843 of nwk_frame.c:nwk_getSandFFrame(). This will, as a side effect, make the call to nwk_QadjustOrder() do nothing. But you didn't read it here -- and I wouldn't do it this way.] TI is scheduled to do a maintenance release for SimpliciTI very soon. It is probably too late to get this bug fixed in that release.

Any fix here should be thoroughly tested. This is pretty sensitive code.

lfriedman

Top 100 Contributor
57 Posts
Community Member

Ooops. I apologize -- the hack I mentioned previously is incorrect. See what happens?! The hack should be to set the structure element to a number bigger than the size of the input queue (SIZE_INFRAME_Q+1) to have the desired effect.

But...you didn't do the first thing anyway, right?! A better way would be to learn the context of the pointer returned by the nwk_getSandFFrame() call and only call the nwk_QadjustOrder() routine if the pointer called out an input queue element.

Sorry for any inconvenience.

lfriedman

 

Page 1 of 1 (5 items) |

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.