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.

[C6742, NDK] no CRC issue with NDK

Other Parts Discussed in Thread: TMS320C6472

Hi,

One of my customer has a trouble with NDK on C6472 .

・NDK     2.21.00.32
・SYS/BIOS 6.33.01.25
・CCS    5.1.0.09000
・XDCtools 3.23.0.32
・Code Generation Tools Versions
 64xx+: Code Generation Tools 7.3.1
・TCP/IP with 260Mbp speed

Issue:
In the above environment, C6472 sometimes get stuck, i mean C6472 keeps returning packets with zero-ed CRC.
Please note DSP is still running when the issue happened.

I would like to ask you whether you have the same experiments with NDK.
If you had, I would like to know your ideas to debug NDK further more. Unfortunately, I'm NDK newbie...

Best Regards,
Kawada

  • Kawada,

    How are you validating this is a issue? Are you using MCSDK package? If not, please try with MCSDK. Right now, I do not have C6472 based board or EVM to check your issue. I can suggest you try to use latest MCSDK.
    Multicore Software Development Kits:
    http://focus.ti.com/docs/toolsw/folders/print/bioslinuxmcsdk.html  or http://www.ti.com/tool/bioslinuxmcsdk

    The EVM comes with disks containing the MCSDK software and CCS. You can start with these or go to the MCSDK software download site listed above to check for the latest updates and version. The BIOS-MCSDK release download will also have pointers to applicable CCS and compiler release versions as well. Please review the release notes and software manifest before downloading and/or installing the software.

    This release supports the Texas Instruments TMS320C6472  high performance DSP and the EVM supported by the software is TMDSEVM6472.

  • Hello Pubesh,

    Thanks for your reply (again).

    Actually, I just hard my customer's status (they seem to confirm CRC is 0 by using ethernet analyzer) and asked you if you have same experience or not.
    My customer is going to their mass production, so as you know, it is difficult to change their platform to MCSDK at this time.
    I believe they are just using NDK package with SYS/BIOS.
    I can't find related bug fixes in newer NDK release note. So we will have to narrow down the problem on their environment.
    Now I would like to know whether this error can happen in EMAC hardware level if something erroneous configuration is existing in EMAC registers/descriptors.
    Do you have any idea ?

    Best Regards,
    kawada
  • Kawada,
    As of now I do not have the C6472 device based board or EVM to validated your issue. But I will check with the team and let you know the details.

  • Kawada, We need more details of your issue to understand clearly.
    You can find there is TCP/IP checksum.
    Are you saying about FCS (Frame Check Sequence)?
    The issue is that C6472 can’t generate packets with CRC or C6472 can’t handle packet received with CRC?
    What is Ethernet analyzer? Wireshark? Do you have any packet capture showing the problem?
  • Hi Pubesh,

    Thanks for your reply. I will need to confirm the details about your queries. After clarifying your questions, I'll let you know. 
    According to customer's reports, I think the problem is happening when transferring the data from C6472. I was assuming they were using NDK and related EMAC driver "as is", but actually, it seems that they are customizing your delivered emac_drv.c.
    (Sorry to give you the confusions about this) I'll confirm the details of their customization also.

    At this time, I suggested the followings:
    I briefly checked the EMAC source code and I understood that NDK control finally went to emac_send() in emac_drv.c when transferring data via EMAC.

    The latest code seems to be delivered from the following link:

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/01_00_00_08/index_FDS.html

    <mcsdk_install_dir>\pdk_c64x_1_00_00_06\packages\ti\drv\emac\src\emac_drv.c

    EMAC_DRV_ERR_E
    emac_send
    (
    Uint32 port_num,
    EMAC_PKT_DESC_T* p_pkt_desc
    )
    {
    EMAC_Pkt* csl_send_pkt;
    Uint32 i;

    if (port_num >= MAX_NUM_EMAC_PORTS)
    {
    emac_debug_print(("emac_send core %d wrong port number %d\n",
    EMAC_CORE_NUM, port_num));
    return EMAC_DRV_RESULT_INVALID_PORT;
    }

    if (p_pkt_desc==NULL)
    {
    emac_debug_print(("emac_send core %d port %d packet descriptor is NULL\n",
    EMAC_CORE_NUM, port_num));
    return EMAC_DRV_RESULT_SEND_ERR;
    }

    csl_send_pkt = emac_queue_pop( port_num, &EMAC_TX_QUEUE(port_num) );

    if( csl_send_pkt )
    {
    memcpy ((void *)csl_send_pkt, (void *)p_pkt_desc, sizeof(EMAC_Pkt));

    Emac_osalEnterSingleCoreCriticalSection(port_num);
    i = EMAC_sendPacket((Handle)EMAC_COMM_DEV(port_num), csl_send_pkt);
    Emac_osalExitSingleCoreCriticalSection(port_num);

    if( i )
    {
    emac_debug_print(("EMAC_sendPacket() core %d port %d returned error %08x\n",
    EMAC_CORE_NUM, port_num, i));
    EMAC_CSL_ERROR(port_num)++;

    /* Free the packet as the packet did not go on the wire*/
    EMAC_FREE_PKT(port_num, p_pkt_desc);

    emac_queue_push( port_num, &EMAC_TX_QUEUE(port_num), csl_send_pkt );

    return EMAC_DRV_RESULT_SEND_ERR;
    }

    /* Packet has been transmitted */
    return EMAC_DRV_RESULT_OK;
    }
    else
    {
    emac_debug_print(("emac_send core %d port %d TX queue is empty\n",
    EMAC_CORE_NUM, port_num));
    /* Free the packet as the packet did not go on the wire. */
    EMAC_FREE_PKT(port_num, p_pkt_desc);
    return EMAC_DRV_RESULT_SEND_ERR;
    }
    }

    As you see, the control can go to this function (If my understanding is correct) when returning the packets to host. And I can see some conditions to fail this API, i.e., failing to get a descriptor from free list or failing to push the descriptor to EMAC_sendPacket(). We are asking whether they are failing at this API in their application. Also, I suggested them to increase the number of descriptors to push free list at initialization phase in their system.

    If they did not fail at this API, I think they could check whether there were erroneous configurations at the descriptors or not .

    Anyway, I'll report you the details about this issue later.

    Best Regards,
    Kawada

  • Kawada,
    Do you have any updates? if not, this discussion of thread can helpful for future readers, If you verified this thread.
  • Hi Pubesh,

    Sorry for the delayed response. Unfortunately, I have not heard the details from our customers.
    What I got is the problem had been disappeared when changing from TCP to UDP....
    But I think they still need to confirm the root cause. I'll update you once I got any updates on this issue.
    Thanks for your patience.

    Best Regards,
    Kawada
  • Kawada,
    Glad to hear, there is no issue on the UDP data send over the network. Let us know if they need further discussion on this.
    And also update the details how it was disappeared, so that the future readers can get help from this thread, if they will get similar issue.