AM335x pin mux mcasp set violation

Mike,

There is a related note in Chapter 7 of the Data Manual:

SPRS717G, Chapter 7 said:

The AM335x device contains many peripheral interfaces. In order to reduce package size and lower overall system cost while maintaining maximum functionality, many of the AM335x terminals can multiplex up to eight signal functions. Although there are many combinations of pin multiplexing that are possible, only a certain number of sets, called IO Sets, are valid due to timing limitations. These valid IO Sets were carefully chosen to provide many possible application scenarios for the user.

Texas Instruments has developed a Windows-based application called Pin Mux Utility that helps a system designer select the appropriate pin-multiplexing configuration for their AM335x-based product design. The Pin Mux Utility provides a way to select valid IO Sets of specific peripheral interfaces to ensure the pin multiplexing configuration selected for a design only uses valid IO Sets supported by the AM335x device.

You can see all the valid IO sets by looking at a "peripheral view", e.g. if you right-click on McASP0 and select "View Pins" it will open a new window showing all the McASP0 pins on the device.  There is a dropbox at the top with all the available IO Sets.  You choose one and select "Apply IO Set" to see the corresponding pins.

I've been looking at your specific scenario.  The easiest fix in my opinion will actually be if you switch from McASP0 to McASP1:

• B12: mcasp1_aclkx_mux2
• C13: mcasp1_fsx_mux2
• D13: mcasp1_axr0_mux2

I spent some time trying to keep it on McASP0, but I kept running into secondary conflicts which were forcing me to try and move UARTs, PWMs, SPIs, etc.  If you can migrate to McASP1 as I've outlined here that will at least be a single well contained change.  Admittedly it's not ideal since you'll have to make some corresponding software modifications (i.e. beyond pin mux), but this was the best I could see.

Hopefully this gives you a better understanding of the issue.  Perhaps there's a different configuration that will be more optimal for your needs.

I've attached my corresponding dat file for the tool so you can see precisely what I changed.

Mike Worster said:

Now the two differences I see are that you have a "axr0" instead of a "axr2", and you have all three options with the same mux suffix ("mux2" instead of the mixed "mux1" and "mux3")

Are one of these two differences the reason you're not getting a Set Violation? (I'm guessing the mux2). Is there anywhere in the specs or data sheets that would have pointed this out to me?

There's not any hard rule at play here.  I imagine you noticed there were groups of signals.  Here's a screenshot to demonstrate:

When the device was designed it was primarily intended that you would use all signals from the same group (i.e. one of the 3 circled sets I show in the screenshot).  However, we still wanted to offer some additional flexibility but that involves additional timing validations and test time for all the various permutations.  So we can't offer every possible permutation.  And that's where the IO Sets come into play.  Someone in TI defined various sets of pins that are mixing between these sets.  Usually the IO Sets were defined to avoid conflicts with some other peripheral.

So I can't tell you a specific rule for avoiding conflicts.  All the data is contained in the pin mux tool, i.e. the way to see all possible IO Sets is to do what I described previously in terms of applying an IO Set and then stepping through them.

Mike Worster said:

2)  I see in the peripheral view (thanks for that btw, I didn't know it was there) there are about 12 mcaspX pins set for each IO Set. Are there more pins required for operation, or is this just a typical Audio subsystem pin configuration? I believe based on our hardware we do not require all of these pins.

The IO Set violation doesn't relate to a minimum number of pins.  It relates simply to mixing pins between the different groupings.  In the case where you're cherry picking a pin here and a pin there it makes sure that you're using a validated combination.

Exactly right.  More than likely it would work, but we couldn't guarantee that to be the case over all process, voltage, and temperature.