AF_DataRequest - BeeAppDataConfirm - sometimes no confirm

[zoz]

 I am using BeeStack 2.0. mesh nwk, SRB boards.

"For each AF_DataRequest(), there is exactly one data confirm. The data confirm comes back to the application in the function BeeAppDataConfirm()."  states the BeeStack SW Reference Manual.

1. Sometimes I experience that there is not any 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 my app stops working properly if there is no confirm.

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.

3. But if I use this watchdog function and I set the flag I will experience memory management problems after a while.

4. I am using SRB boards and I after (2.) sometimes my app freezes totally and the LED5 turns off (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?

How can I use AD_DataRequest if I cannot be sure that a confirm would come?

[Ware]

zoz,

I am using BeeStack 2.0 mesh nwk also...  but I believe these are issues for any BeeStack version.

1. Sometimes the message doesn't make it....  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).

2, 3, and 4 Sound very dangerous -> 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).

Conclusion:

  Don't "expect" a confirm.

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 re-send the data you need (with another AF_DataRequest() call).

Hope this helps,

 - Ware

Message Edited by Ware on 2008-08-27 08:29 AM

Message Edited by Ware on 2008-08-27 08:31 AM

[zoz]

1.

I think you have misunderstood the problem.  A request to the lower layer must be alwalys confirmed to the upper layer! The status of the confirm tells you eg. if the delivery was successful or not 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.

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).

2.

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 most of the frames 2-3-4 times. Have you experienced the same? And this does not occur in the tree network (same application, same positions for the routers).

[Ware]

1. 

I think I did misunderstand...  I thought you meant confirmed with a "pConfirm->status == gSuccess_c".  But apparently you mean any confirm.  I guess it would be ok to "expect" a confirm (not a success) from every request.

2. 

I have watched the protocol analyzer, but my networks are small (1 coordinator and 1 to 3 end devices), so I have not seen this router issue you are experiencing.

One more thing you could try, is to qualify "missed confirms" with a counter (to allow for a few missing confirms).

Sorry I could not help more,

 - Ware

[AdamSch]

Hi folks,

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 request to Freescale about it so i copy the whole text to check if any of you might add some extra info on this issue, so:

"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.

 

Network builds up correctly and im getting those messages from the routers (in a Sniffer).

 

Topology:

Coordinator has Router1

 Router1 has Router2

  Router2 has Router 3

   Router3 has Router4 and Router5

 

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!

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)."

This seems to be BeeStack's issue, because as zoz previously said, every .REQUEST has to be followed by a .CONFIRM!

If anyone has any suggestion please let me know!

Thanks very much,

Adam

[freves]

Hi,

I have the very same problem myself.

Is there anyone having a suggestion on how to solve this?

(Using BeeStack 1.0.5)

/Fredrik