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.

TMS320C6678: Questions about the NIMU_emacExample Project

Part Number: TMS320C6678

While running NUMU_emacExample_EVMC6678C66BiosExampleProject i ran into a few curios circumstances. I was using a separate microcontroller to send UDP packets to the evm and I wasn't seeing any response back. Looking further through the code, I noticed that the dtask_udp_hello function in udpHello.c never gets called even though the daemon is created in the NetworkOpen function inside helloWorld.c.

So I suppose my general questions would be:

  1. Do I need to call dtak_udp_hello from somewhere explicitly?
  2. Is there a way to call dtak_udp_hello from somewhere explicitly without using a daemon?
  3. Is there any other initiation I should be doing that the project didn't provide?
  4. When does NC_NetStart (in helloWorld.c) return? (Just curious since it seems that it's the function that starts everything off)

I'm using pdk_c667x_2_0_4 which the example was built from. I didn't change any of the project settings or code apart from adding printf's to see what the DSP was up to.

Also, yes my network settings are correct. Wireshark shows that my packets from the microcontroller are properly configured (IP addresses and port numbers).

  • Hi Zeke,

    I've forwarded this to the SW experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Hi,

    If you use the example as it is, you should see an IP address 192.168.1.4 assigned to this 6678 EVM. You can use "helloworld" or "testudp" applications under ndk_2_24_xx_xx\packages\ti\ndk\winapps. Set a breakpoint at dtask_udp_hello always hit. I am not sure what tool you used to test the UDP, make sure it sends the packets to 192.168.1.4 UDP port 7, it should work as well.

    Regards, Eric
  • Hi Eric,

    I added a breakpoint to dtask_udp_hello as you suggested and it never hits it even after letting it run for about 10 minutes. Would you mind answering the 4 questions that I asked in the original post?

    Thank you.
  • Bump #2 for visibility.

  • Hi,

    I verified the observation then I made the suggestion yesterday. I don't know why it didn't work for you. Just run the code as it is, you should have the breakpoint hit.

    Attached the out file

    NIMU_emacExample.zip

    Attached the screenshoot without setting a breakpoint:

    Attached the screenshoot with breakpoint hit:

    Regards, Eric

  • Eric,

    I really appreciate your help, but the .out file still didn't work on my device. I have a screenshot of the debugger view.

    As you can tell I had to change the IP to the 169.254.61.x subnet because of IT restrictions, but other than that everything else was kept the same. I was able to add a breakpoint to verify that the daemon was being set, but I wasn't able to jump into the udpHello.c file to add the breakpoint to dtask_udp_hello(). I did, however capture the network with Wireshark and I've included what it saw going on.

    And here's the screenshot of the winapp command being run. As you can tell, I run it a few times and all of them timed out.

    Basically, as soon as I hit the play button in CCS I ran the winapp tool because I know the NIMU project can timeout if it doesn't get a response right away. I'm really disappointed that it didn't run.

    I inherited my workspace from a colleague and thought that there could be some interference with Processor SDK's so I cleared it all out and did a fresh install of CCSv6 and Processor SDK version 3.02.00.05. I rebuilt the projects in the pdk folder and tried running it with the same effect, dtask_udp_hello() never gets hit. To make sure I got everything right I've attached my .out file and my zipped project file. Again, the only thing that's changed is the IP to run on the 169.254.61.x subnet. Please let me know if you're able to run the .out file on your hardware to see if I'm having some hardware issues.

    NIMU_emacExampleProject.zip

    NIMU_emacExample.out.zip

    Thank you for your help,

    Zeke


    EDIT:

    I figured out how to add the breakpoint to dtask_udp_hello() to your .out file but it still doesn't hit. The weird part is that I can see the LED on the RJ45 plug blink when it receives the ARP packets. That means the packets are getting to the hardware but it's not making it's way through the RTOS to the application. Is there any low-level way to check packet reception (such as through NETCTRL)? Do you have any raw ethernet socket examples for this eval board, or any that can be ported?

    I appreciate any help.

  • Bump #3 for visibility.
  • Hi,

    I tried your .out file and it worked perfectly on my network. So you have either network or EVM HW issue need to fix.

    Also attached wireshark capture.

    16925461net.pcapng

    Regards, Eric

  • Eric,

    I just tried my code out with another c6678 EVM with both static IP and DHCP with the same results. Wireshark didn't read anything coming out of the DSP when it should have been sending DHCP requests, and would not respond to ARP packets when using static IP.

    Again I refer back to my original post, is there any other configuration I should be setting to get the project to run (such as switch settings)? Does the PCIE switch need to be set to ON even though I'm using the RJ45 port? Are there any #pragma config statements that should be added? Basically, are there any particular settings that need to be set that could affect the behavior of the ethernet?

    I'm using:
    CCS 6.2.0.00050
    Compiler TI v8.1.1
    Processor SDK RTOS C667x 3.2.0.5
    TMDSEVM6778LE Rev. 3B
    Spectrum Digital XDS560v2 Pro Trace Emulator

    Seeing that the breakpoint on dtask_udp_hello() never hit on either board and I can see the EVM is receiving packets through the blinking light on the connector, I'm inclined to say that it's a software issue.

    Any help or information would really be appreciated,
    Zeke
  • Bump #4 for visibility.
  • I found the issue. I wasn't loading the GEL file properly when running the code. The way I previously did it was: I would hit the debug icon, load the GEL, then hit play. The error in this is that the GEL gets loaded AFTER connecting the target core(s). So now the new process that works is: launch the target configuration, load the GEL, connect the cores, load the program, then hit play. I believe that would fall under "Is there any other initiation I should be doing that the project didn't provide".

    Thanks for your help,
    Zeke