Dear TI Support TeamI have just checked the AM3359 ICE Schematic (Rev. A2) and I have tried to follow the Pin assignment with the Pin Mux Utility (Version 2.2.1.0). Now I have seen the the ICE is using the ZCZ package and connects PRUTH0_RXD1 signal to pin V5. But Pin V5 is not a PR1 MII0 RXD1 pin according to the Pin Mux Utility and according to the Datasheet (sprs717b). PR1 MII0 RXD1 should connect to U3?With ZCE package V5 would be ok according to the datasheet.Can you tell me what's wrong and what's right?
Good catch! But be assured that the ICE schematics are ok in that sense. We have tested this with our EtherCAT slave implementation.
The explanation why will be a bit lengthy... sorry.
Actually there is an additional mux internal to the PRUSS. That allows to use the above seen pins as MII0 RXDn instead of their 'normal' chip level pin-mux assignment. Details on this will be in future TRM updates. If you like to see how this is configured by software have a look at the code that comes with the industrial SDK.
For customer applications it will be possible to use the pin-mux in the normal way and configure PRUSS accordingly with an API function.
Unfortunately the additional muxing is not reflected in the pin-mux tool. I am not sure if there is a plan to ever implement that. So for now we need to document that in a better way. We have started a wiki for ICE on the external forum and I think this point needs to be added there too.
Regards.
Wow that was fast. I'm impressed! You must have an interrupt line and DMA to the E2E ;-)
Thanks a lot for the answer. That helped.
Best regards
Hello Frank,
We are designing a platform with ethercat, muxed GPMC and some other peripherasl: SPIs, USBs, CAN, uarts and so on.
I am really interested on the posibility that you pointed out, of using different signals of the PRU instead of the'normal' chip level pin-mux assignment. I would like to use the "additional mux internal to the PRUSS" as done in the ICE with the PRUETH0_RXD0-RXD3 lines.
I would like to route PR1_MDIO_DATA and PR1_MDIO_MDCLK and if possible PR1_MII1_TXEN and PR1_MII1_RXLINK to the U5, V5, R5, R6 pins. This way, I will we able to use de CSx muxed with the signals mentiones before and give the ethercat fuctionality to the board
Thanks for the help
BR
Hi Benny,
we will have to wait for the official docs update but as far as I can see the signals you want are not covered by the internal PRU mux. So you need to use the default pin mux for them and find another solution for your CSx needs.
Thanks Frank for your support.
Where can I check the signals that are internal PRU pin muxing unit (It does not matter if it is not an official doc).
Do you have the time schedule for the release date of this doc?
sorry for the long delay here. The latest plan for updated PRUSS docs is to have a new docs package as part of BeagleBone by end of this month.
I just found by chance that at least the PRUSS internal pin-mux is already documented in the TRM (to my surprise).
See chapter 4.4 in SPRUH73z.
No clue why no one told me...
I do not find out the doc on the web....
Can you send the link?
Thanks Frank.
Sorry, my fault. There was a typo in my file name and it should have been SPRUH73c. Unfortunately the doc just got updated to 'd' version and the PRU section is much shorter now. Assuming this will go into another doc in the future.
Hi Frank,
I found the document that describe about the PRUSS internal pin-mux.
am335xPruReferenceGuide.pdf
- 4 PRU-ICSS Internal Pinmux Overview
There is it in the following link.
https://github.com/beagleboard/am335x_pru_package
Is this document available for other than beaglebone?
Best regards,
Daisuke
Daisuke-san,
the doc you mentioned is relevant for all AM335x which contain the PRU-ICSS. This is not board dependent. In the past this section was part of the TRM.
Obviously your system level and PRU internal pin mux configuration must match the board schematics. But that is software...
Thank you for the reply.
Is there the reason why pr1_mii0_rxd[3:0] were not used for ICE?
The ICE pin-mux was based on IDK pin-mux. There we had to use the internal pin-mux trick to free up some PWM pins on the system level. Otherwise we couldn't have done the motor control application. At least as far as I can remember...
On ICE we could have changed but we just kept it that way.
Our customer is going to design their circuit in the near future.And that circuit design will be based on ICE.