<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: AF_DataRequest - BeeAppDataConfirm - sometimes no confirm in 8-bit Microcontrollers</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181674#M13269</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;1.&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;I think I &lt;EM&gt;did&lt;/EM&gt; misunderstand...&amp;nbsp; I thought you meant confirmed with a "pConfirm-&amp;gt;status == gSuccess_c".&amp;nbsp; But apparently you mean any confirm.&amp;nbsp; I guess it would be ok to "&lt;STRONG&gt;expect&lt;/STRONG&gt;" a confirm (not a success) from every request.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;2.&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;I have watched the protocol analyzer, but my networks&amp;nbsp;are small (1 coordinator and 1 to 3 end devices), so I have not seen this router issue you are experiencing.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;One more thing you could try, is to qualify "missed confirms" with a counter (to allow for a few missing confirms).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;Sorry I could not help more,&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;- Ware&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 03 Sep 2008 00:40:39 GMT</pubDate>
    <dc:creator>Ware</dc:creator>
    <dc:date>2008-09-03T00:40:39Z</dc:date>
    <item>
      <title>AF_DataRequest - BeeAppDataConfirm - sometimes no confirm</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181671#M13266</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;P align="left"&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;&amp;nbsp;I am using BeeStack 2.0. mesh nwk, SRB boards.&lt;/SPAN&gt;&lt;/P&gt;&lt;P align="left"&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;"For each &lt;SPAN style=": ; font-size: 3; font-family: 'Courier New';"&gt;AF_DataRequest()&lt;/SPAN&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;, there is exactly one data confirm. The data confirm comes back to the application in the function&lt;/SPAN&gt; &lt;SPAN style=": ; font-size: 3; font-family: 'Courier New';"&gt;BeeAppDataConfirm()&lt;/SPAN&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;."&amp;nbsp; states the BeeStack SW Reference Manual.&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P align="left"&gt;&lt;SPAN style=": ; font-family: Times-Roman;"&gt;1. Sometimes I experience that&amp;nbsp;there is not any&amp;nbsp;data confirm after a data request. My application waits for a flag which is set by the data confirm function and it doesn't call the AF_DataRequest any more if there is no confirm... So&amp;nbsp;my app stops&amp;nbsp;working properly if there is no confirm.&lt;/SPAN&gt;&lt;/P&gt;&lt;P align="left"&gt;&lt;SPAN style=": ; font-family: Times-Roman;"&gt;2. So I decided to write a watchdog timer which monitors this flag and if this flag is not set by the BeeAppDataConfirm function, I set it manually so that my app does not stop and it calls the AF_DataRequest again.&lt;/SPAN&gt;&lt;/P&gt;&lt;P align="left"&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;3. But if I use this watchdog function and I set the flag I will experience memory management problems after a while.&lt;/SPAN&gt;&lt;/P&gt;&lt;P align="left"&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;4. I am using SRB boards and I after (2.) sometimes my app freezes totally and the LED5 turns off&amp;nbsp;(and I don't set/reset LED5 in my app manually.) What can be the reason such a total crash? Is it because of memory management problems?&lt;/SPAN&gt;&lt;/P&gt;&lt;P align="left"&gt;&lt;SPAN style="font-family: Times-Roman;"&gt;How can I use AD_DataRequest if I cannot be sure that a confirm would come?&lt;/SPAN&gt;&lt;/P&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 25 Aug 2008 16:38:25 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181671#M13266</guid>
      <dc:creator>zoz</dc:creator>
      <dc:date>2008-08-25T16:38:25Z</dc:date>
    </item>
    <item>
      <title>Re: AF_DataRequest - BeeAppDataConfirm - sometimes no confirm</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181672#M13267</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;zoz,&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;I am using BeeStack 2.0 mesh nwk also...&amp;nbsp; but I believe these are issues for any BeeStack version.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;1. Sometimes the message doesn't make it....&amp;nbsp; it won't be confirmed (code should probably be writen to live with the fact that RF is not as good as copper at transmitting data).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;2, 3, and&amp;nbsp;4 Sound very dangerous -&amp;gt; To me it sounds like you are forcing BeeAppDataConfirm() to be called and process a message that doesn't exist (and this function (if unmodified) also pops this nonexistant message off of the stack with MSG_Free(pMsg), which would cause huge memory management problems).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;Conclusion:&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp; Don't "expect" a confirm.&lt;/DIV&gt;&lt;DIV&gt;I'm not sure exactly what you are trying to accomplish, but maybe you could use a timer to "time-out" after a "long" period of time, if a confirm has not been indicated, and then&amp;nbsp;re-send the data you need (with another AF_DataRequest() call).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;Hope&amp;nbsp;this helps,&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;- Ware&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;BR /&gt;&lt;BR /&gt;Message Edited by Ware on &lt;SPAN class="date_text"&gt;2008-08-27&lt;/SPAN&gt; &lt;SPAN class="time_text"&gt;08:29 AM&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;Message Edited by Ware on &lt;SPAN class="date_text"&gt;2008-08-27&lt;/SPAN&gt; &lt;SPAN class="time_text"&gt;08:31 AM&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Aug 2008 19:27:05 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181672#M13267</guid>
      <dc:creator>Ware</dc:creator>
      <dc:date>2008-08-27T19:27:05Z</dc:date>
    </item>
    <item>
      <title>Re: AF_DataRequest - BeeAppDataConfirm - sometimes no confirm</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181673#M13268</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;1.&lt;/DIV&gt;&lt;DIV&gt;I think you have misunderstood the problem.&amp;nbsp; A request to the lower layer must be alwalys confirmed to the upper layer!&amp;nbsp;The status of the confirm tells you eg. if the delivery was successful or not&amp;nbsp;or if there was any other problem. (and this issue is indepenedt of the fact that we are communicating wireless). And confirm is responsible to free the allocated memory by the lower layer, so it is very important to be called everytime by the lower layer.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;It seems to me that problem only occurs in the mesh version! My tree network (the same application) works perfectly (the AF_DataRequest is alwalys confirmed by the BeeAppDataConfirm).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;2.&lt;/DIV&gt;&lt;DIV&gt;But tell me one other thing please! Have you watched your mesh network via a protocol analyzer? I have an application where every router sends a message to the coordinator in every sec. I have experienced lots of frame retries, the routers are sending&amp;nbsp;most of the&amp;nbsp;frames 2-3-4 times. Have you experienced the same?&amp;nbsp;And this does not occur in the tree network (same application, same positions for the routers).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Aug 2008 20:27:24 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181673#M13268</guid>
      <dc:creator>zoz</dc:creator>
      <dc:date>2008-08-27T20:27:24Z</dc:date>
    </item>
    <item>
      <title>Re: AF_DataRequest - BeeAppDataConfirm - sometimes no confirm</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181674#M13269</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;1.&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;I think I &lt;EM&gt;did&lt;/EM&gt; misunderstand...&amp;nbsp; I thought you meant confirmed with a "pConfirm-&amp;gt;status == gSuccess_c".&amp;nbsp; But apparently you mean any confirm.&amp;nbsp; I guess it would be ok to "&lt;STRONG&gt;expect&lt;/STRONG&gt;" a confirm (not a success) from every request.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;2.&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;I have watched the protocol analyzer, but my networks&amp;nbsp;are small (1 coordinator and 1 to 3 end devices), so I have not seen this router issue you are experiencing.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;One more thing you could try, is to qualify "missed confirms" with a counter (to allow for a few missing confirms).&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;Sorry I could not help more,&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;- Ware&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 03 Sep 2008 00:40:39 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181674#M13269</guid>
      <dc:creator>Ware</dc:creator>
      <dc:date>2008-09-03T00:40:39Z</dc:date>
    </item>
    <item>
      <title>Re: AF_DataRequest - BeeAppDataConfirm - sometimes no confirm</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181675#M13270</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi folks,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Im having quite the same problem it seems. I use BeeStack 2.0.0 on SRB boards from Freescale (tried also on our own designs as well). Sending messages in a tree network is OK, but mesh works weird sometimes. I wrote a service &lt;FONT face="verdana,geneva"&gt;request to&lt;/FONT&gt; Freescale about it so i copy the whole text to check if any of you might add some extra info on this issue, so:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;"I have been experiencing problems with Beestack 2.0.0 ZigBee mesh network. I have built a testbed with a Coordinator and 5 Routers. Each router sends a message to the Coordinator (0x0000) periodically (1000msec) using AF_DataRequest. The timing trigger has been provided by Beestack platform timer modul.&lt;/FONT&gt;&lt;/P&gt;&lt;FONT color="#000000" face="Consolas"&gt;&amp;nbsp;&lt;/FONT&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;Network builds up correctly and im getting those messages from the routers (in a Sniffer).&lt;/FONT&gt;&lt;/P&gt;&lt;FONT color="#000000" face="Consolas"&gt;&amp;nbsp;&lt;/FONT&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;Topology:&lt;/FONT&gt;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;Coordinator has Router1&lt;/FONT&gt;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000"&gt;&lt;FONT face="Consolas"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;Router1 has Router2&lt;/FONT&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000"&gt;&lt;FONT face="Consolas"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt; Router2 has Router 3&lt;/FONT&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000"&gt;&lt;FONT face="Consolas"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&lt;/SPAN&gt; Router3 has Router4 and Router5&lt;/FONT&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;FONT color="#000000" face="Consolas"&gt;&amp;nbsp;&lt;/FONT&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;When I disconnect my Coordinator, after getting a RouteError message from Route1, BeeAppDataConfirm() is not called for the message sent by AF_DataRequest in Router2!&lt;/FONT&gt;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;This causes that the allocated memory is not being set free by memory management! After a couple of messages, it can cause an overflow and runtime error by writing to PortA (and sometimes to Reset)."&lt;/FONT&gt;&lt;/P&gt;&lt;P class="MsoPlainText"&gt;&lt;FONT color="#000000" face="Consolas"&gt;&amp;nbsp;&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;This seems to be BeeStack's issue, because as zoz previously said, every&amp;nbsp;.REQUEST&amp;nbsp;has to be&amp;nbsp;followed by a .CONFIRM!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If anyone has any suggestion please let me know!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks very much,&lt;/P&gt;&lt;P&gt;Adam&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 23 Mar 2009 23:34:52 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181675#M13270</guid>
      <dc:creator>AdamSch</dc:creator>
      <dc:date>2009-03-23T23:34:52Z</dc:date>
    </item>
    <item>
      <title>Re: AF_DataRequest - BeeAppDataConfirm - sometimes no confirm</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181676#M13271</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have the very same problem myself.&lt;/P&gt;&lt;P&gt;Is there anyone having a suggestion on how to solve this?&lt;/P&gt;&lt;P&gt;(Using BeeStack 1.0.5)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;/Fredrik&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 11 Dec 2009 22:01:18 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/AF-DataRequest-BeeAppDataConfirm-sometimes-no-confirm/m-p/181676#M13271</guid>
      <dc:creator>freves</dc:creator>
      <dc:date>2009-12-11T22:01:18Z</dc:date>
    </item>
  </channel>
</rss>

