• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 56 subscribers
  • Views 224 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

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

Mario DW
Genius 3145 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Hi

Several devices we are testing get stuck after a while. (ZED device with latest ZStack 3.0.2 on CC2530).

I have the HAL_ASSERT function set to the infinite loop to detect such cases.

I was able to reproduce a device getting stuck, allowing me to confirm that at least in this case HAL_ASSERT is called.

Symbols is 0, so pMacPib->ackWaitDuration is 0.

This is where it happens - the screenshot shows a memory dump of the MacPib as well as the variable in the watch window and variables preceding that location:

"TheHeap" starts at 0x0FD2

pMacPib points to 0x0A27 where macPib is mapped:

           macPib                  00000A27        MAC_MlmeResetReq (mac_beacon)

All things being equal, I performed a reset, and added a breakpoint at this location to get an idea of the expected memory and variables contents.
I had to trigger a manual break to get the following:

We can see that there is no callback for the random seed that macChipVersion isn't 0, suggesting that this part of the memory has been corrupted.

I further checked the preceding variables and I would only suspect           dmaCfg                  000005FE

Relative segment, address: XDATA 000005FE - 00000A0B (0x40e bytes), align: 

The normal value for dmaCfg.uartCB is 0x105F (@0x0AEA which is the application's call back function but that is not the value when the assert is failing.

This calls for a potential bug in the DMA transmision?

Related question:

Looking at the uartDMACfg_t definition, I see " uint16 rxBuf[HAL_UART_DMA_RX_MAX];" .
Is there any need for the rxBuffer being expressed as uint16, so taking up twice the HAL_UART_DMA_RX_MAX space?  Memory being scarce (especially in the ZNP), this could help free some.

Note: I suppose that this  uint16 type for the rxBuf is (unfortunately) related to how the DMA hardware probably works...

  • 0
    Genius 3145 points

    Extra info: under normal conditions, the TX buffers are barely filled with data (no more than 32 bytes - packets are sent and acked).
    We can see from the screen shot that the last TX memory locations are not 0.
    A mysterious overwrite.

    The Rx buffer is filled with 0x2700 int16 bytes.

    So in case of a renewed failure, I can check those values.

  • 0 in reply to Mario DW
    Guru 735455 points

    Try to refer to Z-Stack 3.0.2 Known Issues and Fixes to patch everything to Z-Stack 3.0.2 to test again.

  • 0 in reply to YiKai Chen
    Genius 3145 points

    I was missing only item #24 .  I do not think that matters here.

  • 0 in reply to Mario DW
    Guru 735455 points

    any thought about this issue?

  • 0
    TI__Guru**** 202256 points

    Hello Mario,

    I have little experience with the DMA driver on this platform, does the issue persist if HAL_UART_ISR is used instead?  rxbuf points to the buffer location/destination address and is thus uint16_t, please refer to the hal_dma.h file as well.  Is there a way to replicate this issue with out-of-box firmware, and have you tried clearing the buffer if it exceeds 0x1FFF?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    I have not been able to observe this during debug yet, I got another issue triggering a false assertion as well.

    We have the following fields in dmaCfg - given the size, I do not believe that rxBuf to be a list of pointers to buffers.

    uint16 rxBuf[HAL_UART_DMA_RX_MAX];
uint8 txBuf[2][HAL_UART_DMA_TX_MAX];

    I'll post more if the same issue repeats.

  • 0
    Genius 3145 points

    While trying to reproduce this issue, I found another assertion exception that I reported in https://e2e.ti.com/p/addpost?rt=1011245 .

  • +1 in reply to Mario DW
    Genius 3145 points

    I've examined the sniffer log from June 20th, related to the observation made in this issue.
    It turns out that the opensource platform that I was using sent an empty Write Attributes request (i.e., no attributes).  The ZED continued to make Data Requests for about 70 minutes after that, but there were no Reports or other comunications.

    As the OSAL memory functions were not instrumentd, the effect of the buffer overflow was likely delayed.

    So I am concluding that this issue is fixed by fixing the related issue.https://e2e.ti.com/p/addpost?rt=1011245 .

    This is the last "Write Attributes" that was sen tto the ZED:

    Frame 6088: 48 bytes on wire (384 bits), 48 bytes captured (384 bits)
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jun 20, 2021 16:29:30.416864000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1624199370.416864000 seconds
    [Time delta from previous captured frame: 0.007867000 seconds]
    [Time delta from previous displayed frame: 0.008510000 seconds]
    [Time since reference or first frame: 5755.053823000 seconds]
    Frame Number: 6088
    Frame Length: 48 bytes (384 bits)
    Capture Length: 48 bytes (384 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zcl]
IEEE 802.15.4 Data, Dst: 0xb80f, Src: 0x0000
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 243
    Destination PAN: 0x880a
    Destination: 0xb80f
    Source: 0x0000
    Frame Check Sequence (TI CC24xx format): FCS OK
        RSSI: 30dB
        FCS Valid: True
        LQI Correlation Value: 108
ZigBee Network Layer Data, Dst: 0xb80f, Src: 0x0000
    Frame Control Field: 0x0208, Frame Type: Data, Discover Route: Suppress, Security Data
        .... .... .... ..00 = Frame Type: Data (0x0)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 00.. .... = Discover Route: Suppress (0x0)
        .... ...0 .... .... = Multicast: False
        .... ..1. .... .... = Security: True
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0xb80f
    Source: 0x0000
    Radius: 30
    Sequence Number: 132
    ZigBee Security Header
        Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
            ...0 1... = Key Id: Network Key (0x1)
            ..1. .... = Extended Nonce: True
        Frame Counter: 482178
        Extended Source: TexasIns_00:01:6a:41:0c (00:12:4b:00:01:6a:41:0c)
        Key Sequence Number: 0
        Message Integrity Code: de59243f
        [Key: d232aca2c434309bd0e0dae5c074315c]
        [Key Origin: 4761]
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .1.. .... = Acknowledgement Request: True
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: Power Configuration (0x0001)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 40
ZigBee Cluster Library Frame, Command: Write Attributes, Seq: 97
    Frame Control Field: Profile-wide (0x00)
        .... ..00 = Frame Type: Profile-wide (0x0)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
        ...0 .... = Disable Default Response: False
    Sequence Number: 97
    Command: Write Attributes (0x02)