This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/PINMUXTOOL: Generated files feature request

Part Number: PINMUXTOOL

Tool/software: TI-RTOS

Hello,

We need an option for TI PinMux that will allow invalid IO set errors for pin selections for particular peripheral signals to be ignored or converted to warnings. I am currently working with the TI PinMux tool to generate PDK board files for our custom design, based upon TI's AM572x EVM, and pin settings that we've validated internally are not valid according to TI's provided IO sets. This is only a problem because the PinMux tool will not write the pin settings with errors to the generated PDK board files. Adding an option to have TI PinMux write these pin settings to the PDK board files despite not being valid as per TI's IO sets would save us a lot of time and effort.

Thanks,

Matt McKee

  • The PMT team have been notified. They will respond here.
  • Matt,

    How did you validate a non TI standard IOSet? Can you please elaborate? Which module also? These iosets have been validated and extensively characterized by TI design team to meet specific timing criteria. We do not recommend violating the ioset restrictions, simply said it will ruin your timing and iodelay in the long run.

    Thanks
    Alex
  • I cannot elaborate much as I was not part of that validation process, but the modules that have options that TI considers invalid are as follows: KBD, VIN3A, and VOUT2.

    Is it possible to have PinMuxTool generate entries for the conflicted pins by editing the source for the PinMuxTool? I would greatly appreciate any suggestions on creating complete and correct board source files for our board.

    Thanks,

    Matt

  • Matt,

    It is not about changing the tool, the tool works as intended because configuring the pins outside IOSET spec is a nono. Not to mention VINs and VOUTs get even deeper because the manual delay modes that you need to configure are tightly coupled with their iosets. How are you planning to meet the timing and delay requirements to ensure proper operation of the device? See below excerpt form DM:

    Why did you not follow the DM? Did you have a schematic design restriction or something?

    Thanks

    Alex