AM3358: EtherCAT Slave support

Thanks for your post.

AM3357 and AM3359 have EtherCAT slave firmware embedded...that is the reason...while others do not.

Here is a good source of info: processors.wiki.ti.com/.../FAQ_Sitara_Industrial

Thanks for your response, however, I don't understand the answer as the PRU firmware itself is not embedded: it is loaded onto the PRUs as a separate/independent binary. We are currently using this binary on a half dozen of our deployed products based on the AM3357, but for a new project are considering the AM3358. The TI documentation is coy about why the TI EtherCAT PRU binary won't run on the AM3358/AM3356. For example, processors.wiki.ti.com/.../FAQ_Sitara_Industrial poses the FAQ question of "Can we use any AM335x to support EtherCAT slave or POWERLINK". The answer to this question is "Both of these protocols specifically require an AM3357 or AM3359 device."

OK, that FAQ appears to answer the question, but.... why?

If it is a legal/licensing restriction, then we could (theoretically) develop our own PRU code which implements the full EtherCAT functionality comparable to the binary provided by TI. If it is due to a technical limitation (e.g. some PRU silicon required for packet forwarding has been eliminated to limit max current draw on processors that have the 3D graphics subsystem or some such scenario), then it would be impossible for anyone to craft their own PRU code that required use of this PRU capability.

Is there perchance some sort of efuse that is burned on the 3356/3358 that is checked by the TI-provided PRU EtherCAT binary that inhibits its execution strictly based on legal/licensing grounds for those processors?

Thanks,
Darrin

Thanks Biser. So if I understand you correctly, the PRUs on the AM3358 do not include same silicon as the AM3357? (e.g. it is impossible for AM3358 PRUs to implement EtherCAT functionality regardless of the PRU code's company of origin). I only ask for confirmation because Table 3-1 in the datasheet again does not specify whether the difference between the support capabilities is due to a technical limitation or legal limitation (or other?)

Is there any PRU-specific documentation that outlines the deficiency in the AM3358 PRUs? In other words, I am concerned that code (of any nature) that we may write that runs on the AM3357 PRUs may not run on the AM3358 PRUs due to the PRUs being different in an unspecified manner. Any guidance would be appreciated.

Thanks,
Darrin

Thank you - that would be great. I understand that EtherCAT will only work on those 2 models, but I am trying to understand the origin of that restriction as we have some intentions of developing some PRU code that will need to work on both our existing 3357 designs as well as our 3358/3352 designs currently under investigation. If the EtherCAT restriction is simply due to some sort of legal agreement and the PRUs of all the models are otherwise identical, then fine. But it would be really important for us to know if the reason has a technical origin of the PRUs having core differences.

Regards,
Darrin

Thank you Frank.  That answers the question of how they are the same (but yet different!) across the families.  I agree that we have no intentions of developing EtherCAT ESC PRU code, but my greater concern was of a general nature that code we are looking at implementing in the PRUs may (or may not) work across all families depending on the origin of the ESC limitation.  As I understand it, therefore the PRUs are functionally the same, but differentiated for ESC legal/royalty reasons.

Regards,

Darrin

Agreed - this was our intention (starting from the 3352). Thanks for your recommendations!

Regards,
Darrin