• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 213 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC2530: ZED - HAL_ASSERT fails in 'MAC_INTERNAL_API void macCspTxRequestAckTimeoutCallback(void)' (mac_csp_tx.c)

CC2530: ZED communication stuck after 4 data requests without ACK

Mario DW
Genius 3145 points
Part Number: CC2530


Context:

The ZED in the current setup is reporting attributes every 15 minutes 

As shown in the tshark textual output below, it stopped communicating after 4 Data Requests without any reply.

 4452 2021-07-28 17:46:48.645186       0x6d99 ▒~F~R 0x0000       ZigBee HA 53 ZCL: Report Attributes, Seq: 36
 4453 2021-07-28 17:46:48.649397       0x6d99 ▒~F~R 0x0000       ZigBee HA 53 ZCL: Report Attributes, Seq: 36
 4454 2021-07-28 17:46:48.649883              ▒~F~R              IEEE 802.15.4 5 Ack
 4455 2021-07-28 17:46:48.659148       0x6d99 ▒~F~R 0x0000       ZigBee HA 57 ZCL: Report Attributes, Seq: 37
 4456 2021-07-28 17:46:48.659613              ▒~F~R              IEEE 802.15.4 5 Ack
 4457 2021-07-28 17:46:48.764898       0x6d99 ▒~F~R 0x0000       IEEE 802.15.4 12 Data Request
 4458 2021-07-28 17:46:48.765380              ▒~F~R              IEEE 802.15.4 5 Ack
 4459 2021-07-28 17:46:48.774518       0x0000 ▒~F~R 0x6d99       ZigBee HA 50 ZCL: Default Response, Seq: 36
 4460 2021-07-28 17:46:48.775004              ▒~F~R              IEEE 802.15.4 5 Ack
 4461 2021-07-28 17:46:48.779152       0x0000 ▒~F~R 0x6d99       ZigBee HA 50 ZCL: Default Response, Seq: 36
 4462 2021-07-28 17:46:48.782151       0x0000 ▒~F~R 0x6d99       ZigBee HA 50 ZCL: Default Response, Seq: 36
 4463 2021-07-28 17:46:48.786292       0x0000 ▒~F~R 0x6d99       ZigBee HA 50 ZCL: Default Response, Seq: 36
 4464 2021-07-28 17:46:48.880523       0x6d99 ▒~F~R 0x0000       IEEE 802.15.4 12 Data Request
 4465 2021-07-28 17:46:48.881003              ▒~F~R              IEEE 802.15.4 5 Ack

[... data requests with ACK every 7 seconds]

 4867 2021-07-28 17:56:02.541925       0x6d99 ▒~F~R 0x0000       IEEE 802.15.4 12 Data Request
 4868 2021-07-28 17:56:02.543695       0x6d99 ▒~F~R 0x0000       IEEE 802.15.4 12 Data Request
 4869 2021-07-28 17:56:02.546554       0x6d99 ▒~F~R 0x0000       IEEE 802.15.4 12 Data Request
 4870 2021-07-28 17:56:02.549504       0x6d99 ▒~F~R 0x0000       IEEE 802.15.4 12 Data Request
 
 [.. End of communication from the 6d99 for over 10 days].
 [The expected next "Report Attributes" is at baout 18:01]

Currently I am just logging this, I am suspecting another memory related issue, and pointers to  which parts of teh code to look at are interesting.

  • 0
    Genius 3145 points

    I filtered the tshark output to check the sequence numbers.

    It seems that generally the ZED makes four Data Requests with the same sequence number, all are ACKed by the coordinator.

    Below is some filtered informations (time, sequence, ack) of the one prior to the failing Data Requests and the failing ones.

    [Data Requests, repeated 4 times, 4x ACK]	

    Arrival Time: Jul 28, 2021 17:55:55.526790000 CEST
    Sequence Number: 30
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:55:55.527275000 CEST
IEEE 802.15.4 Ack, Sequence Number: 30
    Sequence Number: 30
    Arrival Time: Jul 28, 2021 17:55:55.530234000 CEST
    Sequence Number: 30
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:55:55.530651000 CEST
IEEE 802.15.4 Ack, Sequence Number: 30
    Sequence Number: 30
    Arrival Time: Jul 28, 2021 17:55:55.533887000 CEST
    Sequence Number: 30
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:55:55.533936000 CEST
IEEE 802.15.4 Ack, Sequence Number: 30
    Sequence Number: 30
    Arrival Time: Jul 28, 2021 17:55:55.538172000 CEST
    Sequence Number: 30
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:55:55.538665000 CEST
IEEE 802.15.4 Ack, Sequence Number: 30
    Sequence Number: 30
    Arrival Time: Jul 28, 2021 17:55:57.752946000 CEST
    
[Data Requests, repeated 4 times, no ack]	
	
    Arrival Time: Jul 28, 2021 17:56:02.541925000 CEST
    Sequence Number: 31
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:56:02.543695000 CEST
    Sequence Number: 31
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:56:02.546554000 CEST
    Sequence Number: 31
    Source: 0x6d99
    Arrival Time: Jul 28, 2021 17:56:02.549504000 CEST
    Sequence Number: 31
    Source: 0x6d99

  • 0 in reply to Mario DW
    TI__Guru**** 219907 points

    Hi Mario,

    How long must the ZED operate before this behavior occurs?  It is odd that the ZED is sending MAC retries although it is receiving MAC ACKs from the ZC.  It then attempts a NWK retry by incrementing the sequence number but the lack of response from the ZC could indicate that the Frame Counter has not been incremented as well.  Do you have a sniffer log of this behavior?  If it suspects that its parent has been lost, the ZED should enter an orphan state and begin sending a Beacon Request to rejoin the existing network.

    Regards,
    Ryan