zigbee mac problem(mc13224)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

zigbee mac problem(mc13224)

Jump to solution
670 Views
zhangyuxin
Contributor I

,i use mc13224V

to design a product,but in that project ,i meet a problem:mac

will have no response to my application at some time.

1、my software is base on :beestack ARM7 MAC Codebase

2.2.0 stack.

2、my test environment is :

one endpoint (A)、

two coordinator: coord (B) (panid is 0x30)

coord (C) (panid is 0x4E21)

endpoint A send data (19 bytes) to coord B every 10ms(wait

10ms after one packet is send),and coord B send data(19

bytes)to coord C every 10 ms((wait 10ms after one packet is

send) at the same time.

then after a few min,coord B's MAC is dead ,endpoint A can't

send data to coord B any more,and coord C can't recive any

data from coord B.

in coord B,my app software is run well ,because i set a watch

dog (11 sec timeout)in app,and the app will feed the dog every

6 sec,app run will,but i can't get the mac's response when

endpoint A sends data to coord B.but if i reset the Coord

B,everything will be ok!

i don't kown why,i have try everything i can do ,but still can't

solve this problem,can you give me a help? thanks a lot!

Labels (1)
  • RF

0 Kudos
1 Solution
460 Views
AlanCollins
Contributor V

Dear Yu Xin.

     Here are my suggestions:

  1. MAC stack does not implement NWK layer. The Demo applications developed on top of the MAC stack, use the concept of "coordinator" and "end device" to enable the two types of devices defined in 802.15.4: full functional device (FFD) and Reduced functional device (RFD). These devices have different capabilities at MAC layer. The demos apps should be used as reference to build your own implementation. If you re-use the demo apps, you need to perform several changes depending on your application requirements. The demo implements the coordinator to create a PAN ID and grant association to other devices. End device requests association permision, and gets NWK address to be able to communicate to others inside the network. These mechanism should be reviewed carefully by the user, to decide the best way to use the demo apps. If you are using 2 coordinators and 1 end device, you need to be careful that there are no problems with the implemented concepts.
  2. Please remember the radio is half-duplex: it can perform both TX and RX, but not at the same time. You have 1 coordinator attending messages from 2 different devices at rates of 10ms. This coordinator also needs to answer back the MAC ACK. You need to review carefully if what you are doing will be supported by the demo application. IF the demo you are using get that data from Serial COM (Uart) and then sends it OTA, you will need to follow crucial timings by the UART com too. The demo apps are designed to be typematic (one byte at the time), so if you are sending big packets from a script, this will also generate problems. The UART buffering system might be the one that crashes. You will need to implement a sort of handshake.
  3. Have you tried using ZigBee? They already implement robust network on top of the MAC layer.


I hope this helps.

Best Regards,

Alan Collins


     

View solution in original post

0 Kudos
1 Reply
461 Views
AlanCollins
Contributor V

Dear Yu Xin.

     Here are my suggestions:

  1. MAC stack does not implement NWK layer. The Demo applications developed on top of the MAC stack, use the concept of "coordinator" and "end device" to enable the two types of devices defined in 802.15.4: full functional device (FFD) and Reduced functional device (RFD). These devices have different capabilities at MAC layer. The demos apps should be used as reference to build your own implementation. If you re-use the demo apps, you need to perform several changes depending on your application requirements. The demo implements the coordinator to create a PAN ID and grant association to other devices. End device requests association permision, and gets NWK address to be able to communicate to others inside the network. These mechanism should be reviewed carefully by the user, to decide the best way to use the demo apps. If you are using 2 coordinators and 1 end device, you need to be careful that there are no problems with the implemented concepts.
  2. Please remember the radio is half-duplex: it can perform both TX and RX, but not at the same time. You have 1 coordinator attending messages from 2 different devices at rates of 10ms. This coordinator also needs to answer back the MAC ACK. You need to review carefully if what you are doing will be supported by the demo application. IF the demo you are using get that data from Serial COM (Uart) and then sends it OTA, you will need to follow crucial timings by the UART com too. The demo apps are designed to be typematic (one byte at the time), so if you are sending big packets from a script, this will also generate problems. The UART buffering system might be the one that crashes. You will need to implement a sort of handshake.
  3. Have you tried using ZigBee? They already implement robust network on top of the MAC layer.


I hope this helps.

Best Regards,

Alan Collins


     

0 Kudos