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.

C6747 NDK 2.0 Bug? Keep Timeout message and stops responding

 We occassionally see this in the NDK 2.0 with the 6747. There is a printf (to StdOut) of "Keep Timeout" and the stack stops responding. The router also stops seeing the link as active. Not having access to the stack source it is not clear why and how this happens. Even if it is a network eror why would the entire stack stop working?

Anyone else see this or have any insight? Thanks.

  • Edmund

    Seems like this question has not been addressed in a while. I have forwarded the post to some experts  to see if they can provide additional suggestions/insights.

    I hope you are familiar with this page

    http://processors.wiki.ti.com/index.php/Before_asking_for_NDK_support

    I thought the stack source is available , looking at these weblinks

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html

    Regards

    Mukul

     

  • Thanks for the response, but this one was solved. It was because of assumptions in the ethernet driver for the 6747 provided and taking over one fixed set of interrupts with no regards for other functions. I modified the ethernet driver and interrupt management and this was resolved. Also I found the source was released in a later "release" of same NDK that I had missed.

    HOWEVER I am still trying to get an answer about the NDK 2.0 release breaking DHCP function, which I have seen multiple times on these boards with no answer.

    Can you please help with the NDK 2.0 and DHCP problem? Thanks.

  • Edmund
    Do you have a separate post on that?

    Regards

    Mukul

  • Look:

     

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6182/23212.aspx#23212

     

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6143/23013.aspx#23013

     

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/38602/134881.aspx#134881

  • Edmund

    Thanks for pointing out the multiple links on this. Still working on finding the right experts to address the issue you have at hand. Talking to Prathap , who has supported some queries on NDK issues in the past, I wanted to make sure that you have tried some suggestions that have been made in the past to work through similarly sounding issues

    http://processors.wiki.ti.com/index.php/Network_Developers_Kit_FAQ#Q:_Why_does_the_DHCP_client_seems_to_give_up_after_a_certain_period_of_time_if_the_Ethernet_cable_is_disconnected_when_the_NDK_boots_up.3F

    http://processors.wiki.ti.com/index.php/Network_Developers_Kit_FAQ#Q:_What_are_the_numbers_shown_in_the_Service_report_messages_for_the_DHCP.3F

    http://processors.wiki.ti.com/index.php/Network_Developers_Kit_FAQ#Q:_Why_doesn.27t_my_pre-production_DM648_EVM_work_with_NDK.3F

     If these don't work then would recommend to have a point to point connection ie the EVM connected to a standalone PC. On the PC install and run the DHCP server software.In this way, you are in control of DHCP server configuration and hence assigning the IP address. This would help further isolate any network related issues (if any)

    Please let us know if any of the above helps (assuming you have not tried it already)?

    Regards
    Mukul

  • Thank you for the references, but I have checked all of these, and none apply. The network cable is plugged in and active, I can communicate, but DHCP fails. I also have the DHCP task restart running. I get Fault 2, which means no one replied, but its not true, because I directly connect to a computer with DHCP server, running. It sees the request and replies, but the NDK does not see the reply and times out and tries again. The recv() function fails with -1. This is all on a 6747, and it is not an external memory issue.

    As you can see by my post this issue with NDK 2.0 has been raised multiple times, and works with 1.9x version.

  • Hi there:

    Still waiting for any kind of response on this or my tech support request. What is going on? It have been quite a while now.

    Thanks.

  • Hi Edmund --

    A customer had a similar problem with DHCP that we found root cause of yesterday.  This was using evmDM648.   Problem was the the tx/rx interrupts were not configured correctly.  We saw this with the standard hello world example with some changes.

    Are you running on the evm6747 board?  Or custom hardware?   Would it be possible for you to zip up your project files along with the prebuild .out file for us to take a look?

    Thanks,
    -Karl-

  • Our project is rather large, but this DHCP does not work even with the client example provided. Also keep in mind all other functions work perfectly, which make it not likely to be an interrupt issue.

    Can you give me some insight into what the interrupt issues were?

  • Sorry if you already stated as much, but can you please clarify what the issue with DHCP is?   Does it not work at all?   Does it boot and get DHCP but the refresh doesn't work?  Or does DHCP not work at all?  If DHCP is not working, then how are you getting IP address?   Are you hard coding the address?   Can you please clarify what "other functions work perfectly" means?  Can you ping the board and such?

    If this is failing with the client example on a TI EVM, then we should be able to reproduce.  Please confirm that you see this problem with the client example on the TI evm6747.

    Did you update the client example?  Or are you using the example and driver exactly as shipped with NDK 2.0?

    The problem with DHCP on the evmDM648 related to the ethernet interrupts not being plugged for the given example.   The NDK boots and everything looks fine.  The broadcast goes out asking for an IP address, but the NDK never receives response since the event combiner wasn't configured correctly.    On C6x, 12 interrupts can route directly to the core, or you can route them to event combiner and output the event combiner to one of the 12 lines.   This is necessary if you have more than 12 interrupt sources.   If you group them at event combiner, you need to plug one of the 12 interrupts to service the event combiner.  The evmDM648 example that customer was running didn't do the last step.

    Thanks,
    -Karl-

  • First: there are only two interrupts used in NDK 2.0 ethernet driver for 6747. They are both patched directly at HWI level in original code (in original unmodified client example).

    If I use DHCP configuration it will never get an IP from any DHCP server (I have tried three different servers). If I set to fixed IP and router the example functions perfectly. This is all in the original client code. As I have mentioned earlier in this thread the DHCP client forms and sends the request, the DHCP server does see the request and replies, but the DHCP client recv() fails with -1 (never sees the response).

    In fixed mode all other functions work, but in the unmodified client and in my code. The only difference in my code is that I turn off a lot of the services, and move the interrupt handler from direct patch to event combiner to coexist with other components. Again in BOTH the unmodified client and in my code I send/recv packets, can run the server tests, ping, etc, so the interrupts MUST be working.

    Am I missing something? It seems pretty straightforward. BTW as I posted here before I have seen multiple reports of DHCP issues on various platforms with NDK 2.0.

    Can you confirm that YOU can get the DHCP to work on the EVM6747 and if yes with what DHCP server?

  • I now have my hands on an evm6747 board.  But now I have meetings ;-(   I'll try to get to this later today.  If not, Monday.

    -Karl-

  • I was able to run standard client app for the evm6747 board and DHCP worked fine.

    I've attached the .out file that I used.   6712.client.zip

    Can you try running this on your board?   I have no idea what type of DHCP server we have.  Let me know if the attached works for you.  If not, I can try to find out more about DHCP service we have (and if there are any options in the source code) tomorrow.

    Here is the output.

    [C674X_0] 
    [C674X_0] TCP/IP Stack Example Client
    [C674X_0] Using MAC Address: 00-0e-99-02-f2-ea
    [C674X_0]  EMAC should be up and running 
    [C674X_0] EMAC has been started successfully
    [C674X_0] Registeration of the EMAC Successful
    [C674X_0] Service Status: DHCPC    : Enabled  :          : 000
    [C674X_0] Service Status: Telnet   : Enabled  :          : 000
    [C674X_0] Service Status: HTTP     : Enabled  :          : 000
    [C674X_0] Service Status: DHCPC    : Enabled  : Running  : 000
    [C674X_0] Link Status: 100Mb/s Full Duplex on PHY 1
    [C674X_0] Network Added: If-1:146.252.161.72
    [C674X_0] Service Status: DHCPC    : Enabled  : Running  : 017
    [C674X_0] Raw Eth Task Started ... 
    [C674X_0] Raw Eth Task Ended ...

  • Thank you, I ran your client binary and have the same results as my build. For this test I used a MacOS X machine as the DHCP server (which works for pretty much everything else I have tried, it is unix). The Mac sees the requests as follows and responds:


    10/5/10 2:43:22 PM bootpd[12696] DHCP DISCOVER [en0]: 1,0:1:2:3:4:5 <tidsp>


    And as I said before I have tried this with other DHCP servers with same result. And again everything else works.
    This is the output on DSP:


    TCP/IP Stack Example Client
    Using MAC Address: 00-00-00-00-00-00
    Since EFUSE MAC address is Zero we use th MAC Address = 00-01-02-03-04-05
     EMAC should be up and running  
    EMAC has been started successfully
    Registeration of the EMAC Successful
    Service Status: DHCPC    : Enabled  :          : 000
    Service Status: Telnet   : Enabled  :          : 000
    Service Status: HTTP     : Enabled  :          : 000
    Service Status: DHCPC    : Enabled  : Running  : 000
    Link Status: 100Mb/s Full Duplex on PHY 1
    Service Status: DHCPC    : Enabled  : Fault    : 002
    Service Status: DHCPC    : Disabled :          : 000
    Service Status: DHCPC    : Enabled  :          : 000
    Service Status: DHCPC    : Enabled  : Running  : 000
    Service Status: DHCPC    : Enabled  : Fault    : 002
    Service Status: DHCPC    : Disabled :          : 000
    Service Status: DHCPC    : Enabled  :          : 000
    Service Status: DHCPC    : Enabled  : Running  : 000

  • My 6747 board has a non-zero MAC address in the FLASH/ROM.   Yours seems to have 0-0-0-0-0-0.  Did you change your FLASH/ROM?  Or, maybe you somehow have a board without an MAC address.  Not sure how this could happen.

    Thinking that maybe the DHCP servers don't like the 00-01-02-03-04-05 MAC address, I tried to reproduce your problem by hacking the HwPktOpen() function in ethdriver.c forcing "i=6" in the code so that I would also use the funny 00-01-02-03-04-05 emac address.  Our DHCP server happily took this and gave me an IP address.

    I then hacked the code to force the MAC address to be the same as the one in ROM for my board.   Can you try doing same to see if maybe the issue is that your DCHP servers don't like that 00-01-02-03-04-05 address?  Search for the for loop below and insert the hack (begin/end hack) as shown.

     

        /*  Check if EMAC_getConfig had returned a valid MAC address to use. If not,
         *  use the default generated above.
         */
        for( i=0; (i<6) && (!(bMacAddr[i])); i++ );

        /* begin hack */
        i = 6;
        addrCfg->Addr[0] = 0x00;
        addrCfg->Addr[1] = 0x0e;
        addrCfg->Addr[2] = 0x99;
        addrCfg->Addr[3] = 0x02;
        addrCfg->Addr[4] = 0xf2;
        addrCfg->Addr[5] = 0xea;
        /* end hack */


        if( i==6 )
        {
            mmCopy( (void *)&pPDI->bMacAddr[0], (void *)&addrCfg->Addr[0], 6 );
            printf("Since EFUSE MAC address is Zero we use th MAC Address = %02x-%02x-%02x-%02x-%02x-%02x\n",
                   pPDI->bMacAddr[0],pPDI->bMacAddr[1],pPDI->bMacAddr[2],pPDI->bMacAddr[3],pPDI->bMacAddr[4],pPDI->bMacAddr[5]);
        }

  • FYI I have tried with various MAC addresses, including ones assigned to us and other ones I stole from inactive NIC cards. Its not the MAC address. And the fact that your binary acts the same means there are no build/interrupt issues.

    What DHCP server are you using? Have you tried with another?

    I will point out there are other posts with issues with DHCP on the NDK (non 6747) around the boards, and although I understand one was an interrupt issue it doesn't seem like I am the only one.

    Also in terms of troubleshooting: what could possibly be causing this, except for an issue with the NDK not correctly receiving the non IP response from DHCP server? As I posted before the recv() fails with -1.

    Thanks.

  • Hi Edmund --

    Since I am on corporate LAN and have no idea where DHCP server is or even who to ask,  I just went and purchased a NETGEER Router (N150 Wireless Router -- WNR1000).  $49 bucks at Staples.

    I powered on the router and did not change any default settings.

    I connected cable from my evm6747 board (ethernet port1) to port 4 of the router.  

    I loaded and ran client.out (same app I sent you).

    The router's DHCP server gives me an IP address as shown below.

    TCP/IP Stack Example Client
    Using MAC Address: 00-0e-99-02-f2-ea
     EMAC should be up and running 
    EMAC has been started successfully
    Registeration of the EMAC Successful
    Service Status: DHCPC    : Enabled  :          : 000
    Service Status: Telnet   : Enabled  :          : 000
    Service Status: HTTP     : Enabled  :          : 000
    Service Status: DHCPC    : Enabled  : Running  : 000
    Link Status: 100Mb/s Full Duplex on PHY 1
    Network Added: If-1:192.168.1.3
    Service Status: DHCPC    : Enabled  : Running  : 017
    Raw Eth Task Started ... 
    Raw Eth Task Ended ...

    I then update the app to force the funny 00-01-02-03-04-05 MAC address (hard code i=6) in the driver.  And I also get an IP address (ends with '4' this time which makes sense since the lease for '3' is in use)

    TCP/IP Stack Example Client
    Using MAC Address: 00-0e-99-02-f2-ea
    Since EFUSE MAC address is Zero we use th MAC Address = 00-01-02-03-04-05
     EMAC should be up and running 
    EMAC has been started successfully
    Registeration of the EMAC Successful
    Service Status: DHCPC    : Enabled  :          : 000
    Service Status: Telnet   : Enabled  :          : 000
    Service Status: HTTP     : Enabled  :          : 000
    Service Status: DHCPC    : Enabled  : Running  : 000
    Link Status: 100Mb/s Full Duplex on PHY 1
    Network Added: If-1:192.168.1.4
    Service Status: DHCPC    : Enabled  : Running  : 017
    Raw Eth Task Started ... 
    Raw Eth Task Ended ... 

     

    I have no idea what could be wrong with your setup.

    Note that NDK 2.0.0 comes with complete source code.  Maybe you can instrument the DHCP code or use C debugger to see if you can narrow it down.  You should be able to add those source files to your project and build for debug profile and then put b/p's in the code.

    Questions:

    (1)  Are you using a standard TI EVM board?  Or custom board?  I am using a TI evmOMAPL137 board.  The DSP side should be same as evm6747.

    (2)  Do you have another board that you can try?

    (3)  Maybe this is somehow .gel file related.  Can you try the attached .gel file to see if that fixes anything?

    8512.evmomapl137_dsp.zip