• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 1777 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.

NDK stops responding for a period

Barry Andrews
Genius 3460 points

I have a TI-RTOS applicatio running on Stellaris LM3S9D2 processor.

NDK is 2_22_01_14

BIOS is 6_34_04_22

XDC Tools 3_24_06_63

Compiled under CCS using ARM compiler 6.0.6

I have TCP, UDP and PPP protocols enabled on the IP stack.

The applications runs and I don't get any network errors but after around 70 pings it stops responding for a few minutes, then will start responding again.  Does similar with TCP connections, I can connect and disconnect 10 - 15 times but then won't connect again but after 4 or 5 minutes (haven't timed exactly) I can ping again and connect again.

I would like some advice as to where I can start looking to determine what is happening and why.

It is like as though memory is used up at a quicker rate than it is freed.

The longer I wait before trying the pings again the more I will get back before it stops responding again, same with TCP connections.

 

  • 0
    TI__Mastermind 20480 points

    Barry,

    how are you observing this behavior? Have you tried to use wireshark?

  • 0 in reply to Tom Kopriva
    Genius 3460 points

    Hello Tom

     

    Thanks for the reply.  I haven't delved into the low level yet, just observed that I am unable to connect using a TCP client and that pings stop.  Wait a while and its ok.  Looks like it may be an issue in my version of NDK as I went back to earlier project with basically same code and it works fine .

    Working version uses compiler V5.01 TI-RTOS _1_0_1_74 NDK_2_21_01_38 Stelarisware_9107

    Failing version uses compiler V5.06 TI-RTOS_1_1_0_25 and NDK_2_22_03_20 StellarisWare_9453e.

    Working version has additional tasks but I have commented all those out to give me basically same code as failing version  I now have a DHCP problem with the failing code - just returns error 002, I saw a post which said there was an NDK issue with the DHCP in the version I am using.

    I went to get latest TI-RTOS 1.10.00.23 and found LM3S no longer supported and Stellaris no longer recommended for new design (Our supplier had said nothing about this so was a bit of a shock).  Not good when I am in the middle of new design and was evaluating the IP stack and seing how it can integrate with our requirements.  And no equivalent part in new Tiva family.  TI web page say patch for LM3S coming out this month, no mention as to what they are actually fixing and when in September.

    So at the moment I am assuming is a fault in my versions of BIOS/NDK and I am trying to figure out if we can wait for TI to release data on the new Tiva with Ethernet (TM4C129?) or if I have to go elsewhere.

    There are only sprinklings of information about the new Tiva on web with no firm dates and no specs.  I need to get the product ready by first quarter next year so no time to spare.  Was already into firmware testing / development now have to go back to device evaluation stage.

     

  • 0 in reply to Barry Andrews
    TI__Mastermind 20480 points

    Barry,

    Are you using a stock TI-RTOS (tcpEcho) example?

    TI-RTOS 1.1.0.25 ships a version of NDK within the products subdirectory; which happens to be NDK 2.22.1.14. For TI-RTOS examples, checking the NDK product in the CCS project properities' RTSC tab will have no effect.

    From the sounds of it, your application might be running out of memory. Can you see if the the calls socket() are successful? In the NDK, there's memory utility (NDK Users' Guid 3.5.6 Memory Management Reports) that you can use.

    Between TI-RTOS versions 1.0.1 and 1.1.0 the EMAC ethernet driver for the NDK didn't change much. You might be to see if the Logs are from the EMAC driver differ in any way. These logs will be not generated if you're using the NonInstrumented library.

    While the target is "stalled", can you halt the target and check ROV and see if something is being blocked when it should be or if you're popping a task stack by any chance?

  • 0 in reply to Tom Kopriva
    Genius 3460 points

    Thanks, will try what you suggest once I sort out why the DHCP has stopped working on this version.

     

    Service Status: DHCPC : Enabled : : 000

    Service Status: DHCPC : Enabled : Running : 000

    Service Status: DHCPC : Enabled : Fault : 002

  • 0 in reply to Barry Andrews
    Genius 3460 points

    I think my issues with DHCP may relate to upgrading TI-RTOS to V 1.10 and then uninstalling.

    My NDK is checked in Other repositries as:

    ${COM_TI_RTSC_TIRTOS_INSTALL_DIR}/products/ndk_2_22_03_20/packages

    I will try re installing 1.1.0.25 and see if this fixes my problem

    What was the latest version of TI-RTOS which supported Stellaris? and where can I download it from.

     

  • 0 in reply to Barry Andrews
    TI__Mastermind 20480 points

    Hi Barry,

    The latest version supporting LM3 (Stellaris) is TI-RTOS 1.01.00.25.

    As long as you have TI-RTOS 1.01 selected in the RTSC tab, you should be pulling in the correct NDK.

    You can look at the log to see which one you actually pulling in:

    "C:\\TI\\ccsv5.3.0.00090\\ccsv5\\utils\\bin\\gmake" -k all
    'Building file: ../tcpEcho.cfg'
    'Invoking: XDCtools'
    "C:/TI/ccsv5.3.0.00090/xdctools_3_24_05_48/xs" --xdcpath="C:/TI/tirtos_1_01_00_25/packages;C:/TI/tirtos_1_01_00_25/products/bios_6_34_04_22/packages;C:/TI/tirtos_1_01_00_25/products/ipc_1_25_02_12/packages;C:/TI/tirtos_1_01_00_25/products/ndk_2_22_01_14/packages;C:/TI/tirtos_1_01_00_25/products/uia_1_02_00_07/packages;C:/TI/tirtos_1_01_00_25/products/xdctools_3_24_06_63/packages;C:/TI/ccsv5.3.0.00090/ccsv5/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.M3 -p ti.platforms.stellaris:LM3S9D96 -r release -c "C:/TI/ccsv5.3.0.00090/ccsv5/tools/compiler/arm_5.0.1" --compileOptions "-g --optimize_with_debug" "../tcpEcho.cfg"
    making package.mak (because of package.bld) ...
    generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
    configuring tcpEcho.xem3 from package/cfg/tcpEcho_pem3.cfg ...
    remark: No frequency info found for CPU timestamp.  See ti.uia.runtime.LogSync module for help on how to provide this info for System Analyzer.
    clem3 package/cfg/tcpEcho_pem3.c ...
    'Finished building: ../tcpEcho.cfg'

    .
    .
    .

    Have you been able to view the Logs in the EMAC driver? You'll need to use the instrumented EMAC library.

    var EMAC = xdc.useModule('ti.drivers.EMAC');
    EMAC.libType = EMAC.LibType_Instrumented;
    Main.common$.diags_USER1 = Diags.ALWAYS_ON;

    The EMAC ROV module you can see the statistics if you dropped any packets. Although, I'd recommend to use Wireshark to see what's going on the network. It might reveal some extra noise on the network.

    In what application are you seeing the periodic unresponsiveness? Would it possible for you to send us a small CCS project that demonstrates this behavior? Will it show in the provided tcpEcho example? Can you try the tcpEcho example and see if you're getting the same DHCP error?

  • 0 in reply to Tom Kopriva
    Genius 3460 points

    Hello Tom

    Thanks for the information., got me thinking about the included libraries etc.

    My project is based on the TCP ECHO example but this was from the older mcusdk rather than ti-rtos.

    I started project again from the clean example and removed all MCU-SDK references and made sure only the TI-RTOS libraries were included.  The code now has no issue with HDLC and also doesn't have the issue with TCP connections stopping responding nor pings not responding.

    However I now have an issue with PPP.

    If I include PPP library (which I need so I can talk to 3G modem) I get the following linker error when I call hdlcNew in my code:

    IFSetPad C:\ti\tirtos_1_01_00_25\products\ndk_2_22_01_14\packages\ti\ndk\tools\hdlc\lib\hdlc.aem3<hdlc.oem3>

  • 0 in reply to Barry Andrews
    Genius 3460 points

    Jusst an update to my compiler error,  it is a bug.  The function isn't being built into the NDK libraries because the definition for the function IFSetPad() is surrounded by an #ifdef that's not true (in ti/ndk/stack/res/if.c):

    #ifndef _INCLUDE_NIMU_CODE

    I fixed by puting a copy of if.c into my project and removing the #ifndef

  • 0 in reply to Barry Andrews
    TI__Mastermind 20480 points

    Barry,

    a bug was filed for the #ifndef. Thanks!

    SDOCM00103777: NDK (NIMU enabled code) has references to code that's compiled out by #ifndef INCLUDE_NIMU_CODE