ICE & EtherCAT slave source

p.s. also, are there any methods to redirect stdout (i.e. printf) to either com port or jtag console?

Mathew,

actually the TI_ESC_DEBUG code is for internal use and should have been removed. Can you explain why you need to dig that deep?

As we are releasing the EtherCAT PRU firmware only as object code you have no chance to change anything on the low level. All issues related to EtherCAT in that sense need to be reported to TI.

Obviously you can fully debug the stack if you have access to the ETG source code. There is nothing special in our applications related to that. All CCS tools and support fully applies. For printf() style outputs you have several means:

- CCS CIO support

- Sys/Bios System_printf()

- direct programming of HW UARTs on AM335x via Starterware (see the examples). One of the UARTs connects to USB so you get this as virtual COM port on your PC. The other one is on an extension connector. See the schematics of ICE for this.

Any questions should be routed to the correct forums ideally (Sys/Bios and CCS have their own ones...). Also you migth try the search options as standard questions are usually already answered somewhere.

Regards.

Thanks for the reply Frank,

We're currently trialing the use of EtherCAT as a spacecraft communication system (actually trialling your processor to fly as well, but thats a seperate issue). The reasons for digging the depths of the hardware stack are:

 - being able to extract diagnostics at a very low level

- introducing failures into the device.

Ultimately we're interested in how the overall EtherCAT system copes with single point failures - hence using the ICE boards as reconfigurable slaves we can 'screw up' on command, in a variety of different ways. From an implementation/stack point of view, this needs to be engaged as close to the physical layer as possible.

We're all signed up with ETG and have the stack code. The one thing I'm struggling with at the moment is how the ETG stack has been applied within the am3359 processor. For example where is the division between central core and PRUSS? Any extra info/docs you may have on this would be appreciated as we're going well above and beyond the typical documented application.

thanks

Mat

The outcome of this EtherCAT work will be published through the UK Space Agency, so we'll all get some good publicity out of this (if it goes well!)

With regards to the PRU/firmware. After having a hunt around, this is definitely something I'm going to need to get into. However, within the firmware directory of the ecat_appl project, there are two header files (ecat_frame_handler_bin.h and ecat_host_interface_bin.h) - both contain a load of hex instructions with the comment "This file is generated by the PDSP assembler". Would it be possible to obtain the original sources for these files? The whole reason for going with the TI platform for this trial was to get into the guts of the system, rather than being stuck with ASIC implementations which never put a foot wrong (until they reach space and get some electrons bounced through them).

 I'm guessing that we've probably reached the limit of discussion within the forum here. Happy to take this further under NDA or other restrictions as necessary.

Mat

Mathew,

as far as I am aware we are not allowed to give out the source due to legal agreements with Beckhoff, the owner of EtherCAT IP and patents. Even an NDA won't help.

Even if you are going to offer me a test seat to the moon (won't refuse this..) I am sorry but I can't help.

Regards.

no worries Frank, will take this up with Beckhoff.

On a completely unrelated subject, do you know how much pain it'd be to get Linux operational on the ICE boards, then run up the EtherCAT slave app as a linux application?

Mathew Maher said:

no worries Frank, will take this up with Beckhoff.

Have fun...

Now related to Linux it would be good to understand why you want to do that! We use an RTOS for some reason. Even a good RT-Linux has task latency in the 50-80us range on the 550MHz device. If you think about EtherCAT cycle times close to the minimum (31.25us) this won't work well...

If you only want to run EtherCAT cycle times in the range >1ms and you have no hard real time or DC requirements it might work.

We would estimate porting Linux to ICE to 1-2 weeks max. BeagleBone is very close from the hardware. There are others with similar requests here but for us that is not a priority currently.

Regards.

we would never deploy on linux, but for early-stage trials and prototyping, it could be very useful.

As far as real-time EtherCAT response goes, we're screwed of the ICE boards anyway. EtherCAT takes out the two Ethernet ports, leaving a slow USB/Serial connection (or slow JTAG) to perform all the high-level application and debug stuff. This serial port is the response-time killer, not the O/S.  Linux offers a lot in the way of rapid hacking and debugging ability. Also offer POSIX-compliance for prototyping later posix-O/S on the processor.

Have a good evening

Mat

HI Frank, i'm hoping that you see this since this is a very old thread.

I have an applicaiton in mind that works very well on the Beaglebone, running under linux.       The 'star' topology of ethernet for the application makes for expensive infrastructure requriing to be installed in quite challenging environments.       I would like to use Ethercat, and layer on top of it, ethernet over ethercat..  The daisy chain/loop topology would be a 'killer' feature for us.      I dont' need the RT performance, can accept some jitter and latency..  the vast majority of the data would be be udp packets in one direction (towards the slave ).. Only a small amoutn of data is required coming back for configuraiton ( via HTTP ) and some simple diagnostics

Irrespective of it being a good idea or not, is an ethercat interface on a linux based ARM3359 viable?

I investigating trying to build a beagle cape based on the PHY sections of the ICE, but unfortunately 4 of the required pins don't make it to the headers....

Hello Andrew,

I'm sure you mean EtherCAT slave here. Technically, it is viable to run Linux and EtherCAT slave on ICE platform. The challenge would be support from TI for this configuration. We were using Linux for Profibus slave solution on AM1810 in the past but a lot of customers prefer a low footprint, less complex and a highly real-time kernel for slave protocols. For this reason, TI is recommending Sys/BIOS or other 3P RTOS for Industrial protocols especially for slave versions.

As you might know already, we do have EtherCAT slave on Sys/BIOS OS on ICE platform. We have Linux SDK on other AM335x platforms like TMDSSK3358. If you can use these two components and do porting from Sys/BIOS to Linux yourself, that should work. This would require more effort from you with limited support from TI. It is a challenge for TI to support all the different configurations and I hope you understand the challenge.

Good luck and thanks for considering TI solutions. Would be interested to know more about your product. You can contact me at gurrapu@ti.com

Thanks,

-Srik

Andrew,

It's worth noting that EtherCAT is not Ethernet - it can get flippin' complicated to implement (even using supplied applications) and the end result would be functionally limited. Unless you need the specific functionality of EtherCAT (i.e. RT operation, etc), personally I would advise against it (been there, tried that).

If you need Ethernet, but in a ring topology, then perhaps a simpler solution would be to implement the ring using CAT5 cross-over cables between each device, then use the existing Linux networking functionality to perform simple routing between each port. Although you will end up chewing up processor power doing this, if the network traffic is light UDP, then this should be acceptable.

Also note that the AM3359 chips have a silicon bug which limits the functionality from the 2nd MII port. The silicon errata documents this better than I can.

Mat

Well aware of the differences between Ethercat and Ethernet..    

Yes, you could route traffic between ports i guess,  the networking required to pull this off, could get quite scary..    Sticking 10 devices in a loop like this would be a nightmare to configure and well beyond the capablity of most end users..   

You could also contemplate switching the packets, but stacking switches endlessly is not a great idea either.

The topology of ethercat is so appealing to our application that it is still well worth pursuing.

Thanks up for the errata, i'll go and read up pon that.

>Also note that the AM3359 chips have a silicon bug which limits the functionality from the 2nd MII port. The silicon errata documents this better than I can.

This bug is fixed in AM335x PG2.0.and beyond