Forums

Thanks for that. I think "a bit more complex" is quite an understatement. This never-ending and uncontrolled explosion in complexity will, I fear, lead eventually to a train wreck...but that's another story. I am under no delusion that the low-level parts of my code will need to be rewritten; I have got used to having to do that over the years as the C6000 has evolved (DMA -> EDMA -> EDMA3 -> ???, for example, forever adding more features but never addressing the fundamental flaws).

I am now fairly certain that the PA LLD offers me nothing. I have two types of packet coming in from the host to ONE core; no other cores need access to this Ethernet device. As my reading of the various documents suggests that I am going to be forced to double-copy the data (please correct me if I'm wrong) those two types of packet can be combined into one, so classification is a null operation. Also, no load balancing or checksum verification is necessary - if a dedicated point-to-point link is unreliable there's not much point in continuing.

I have looked at the example you suggested and it should be a useful starting point - and much easier to follow when all the *(volatile unsigned int)(base_expression+offset) clutter is replaced with structure accesses!

I would be grateful if you could show me how you would remove the PA LLD from the example.

So, all I need is to be able to write one type of packet to one host address and read one type of packet back (on interrupts).

To understand how the Ethernet is used, I have tried running the example C:\ti\pdk_C6678_1_0_0_21\packages\ti\drv\pa\example\emacExample.

This builds and runs, but generates no observable activity on the Ethernet. It detects no errors during setup and then sends out 10 packets. It then loops forever waiting to receive something - although I'm not surprised nothing comes in.

The Readme file is confusing. It starts: "In order for the example to work successfully, i.e. to be able to send/receive data packets from the wire  the following configuration needs to be done in the simulator:". However, at the end of that file it says: "The deafult test configuration is for silicon only."

I have tried several changes (changing port numbers, MAC addresses, etc.) but nothing makes the Ethernet twitch.

Is this example for the simulator only? Should it work on the real silicon?  Should it put packets on the Ethernet? Is there another example that does put packets on the Ethernet?

but

After a deafening silence on this thread, I have managed to get the example to run. This was by removing all TI software, downloading again, and reinstalling from scratch.

Once the example was running in loopback mode, I tried making it exchange packets with a PC program. The PC sees the correct packets coming from the DSP, but no packets being sent to the DSP are received. Wireshark shows all packets on the wire.

The code of the example has explicit MAC address and other assumptions built into it in several places, and I suspect that one or more is lurking somewhere and causing input packets to be rejected. The complexity of the device makes it extremely difficult to trace everything to see where the packet may be being discarded (if it is being received at all).

Has anyone else managed to get this example to do anything except work in loopback mode? What it the complete list of things that need to be changed to achieve this?

Hey...

I have exactly the same problem....! Did you get your project running?

Hi,

After a lot of messing around I got some cut-down code from TI and managed to massage it into something that was useful to me.

If you would like a copy of the project I ended up with and the corresponding host program (probably too big to post here) drop me an email (psr@3L.com) and I'll send it to you.