- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
-
- NXP Tech Blogs
- Home
- :
- General Purpose Microcontrollers
- :
- Kinetis Microcontrollers
- :
- Re: PTA9 and PTA10 on K60 Microcontroller
PTA9 and PTA10 on K60 Microcontroller
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
PTA9 and PTA10 on K60 Microcontroller are having dual functionality of MII signls and also Trace Signals for JTAG. If I Want to use K60 as MII MAC and also I want to provide full JTAG functionality how I can do that as the Pin has Multiplexed Signals.
Kindly Can anyone clarify me.
Regards
Arun
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arun
Trace requires a certain amount of signals and so means sacrificing some ports to be able to use it.
In the case of PTA9 and PTA10 these are multiplexed with MII0_RXD2 and MII0_RXD3 (as well as FTM functions). If the Ethernet PHY is used in RMII mode (rather than MII mode) these pins are not needed and so can be allocated to the trace interface.
Supposedly freescale put the trace pins to overlap with more obscure peripheral functions so that trace can be used in as many cases as possible - since using RMII Ethernet PHY mode would also allows this it offers the designer the opportunity to decide on the RMII mode in case trace is a requirement (if MII0_RXD0 were to be multiplexed instead there would be no option to use trace together with Ethernet!).
However it is a compromise and so, if all peripheral port signals are required in a design, trace would not be possible without disabling these pins (and these functions in the application). In some cases it may be possible to still use a trace port together with a SW version that doesn't use all of its normal peripheral functions but instead ensures that all trace signals are configured for the trace connector. Whether, in this case, trace makes sense depends on what is being monitored/debugged.
Regards
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Arun
Trace requires a certain amount of signals and so means sacrificing some ports to be able to use it.
In the case of PTA9 and PTA10 these are multiplexed with MII0_RXD2 and MII0_RXD3 (as well as FTM functions). If the Ethernet PHY is used in RMII mode (rather than MII mode) these pins are not needed and so can be allocated to the trace interface.
Supposedly freescale put the trace pins to overlap with more obscure peripheral functions so that trace can be used in as many cases as possible - since using RMII Ethernet PHY mode would also allows this it offers the designer the opportunity to decide on the RMII mode in case trace is a requirement (if MII0_RXD0 were to be multiplexed instead there would be no option to use trace together with Ethernet!).
However it is a compromise and so, if all peripheral port signals are required in a design, trace would not be possible without disabling these pins (and these functions in the application). In some cases it may be possible to still use a trace port together with a SW version that doesn't use all of its normal peripheral functions but instead ensures that all trace signals are configured for the trace connector. Whether, in this case, trace makes sense depends on what is being monitored/debugged.
Regards
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then it means I have to use Etherenet PHY in RMII mode only if I want use trace functionality. Also since RMII mode MAC clock is internally tied to OSCERCLK, I have to use only 50MHz crystal source for EXTAL pin, not 25MHz. Am I correct? Also same crystal clock source should be used to drive both microcontroller and PHY tranceiver?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Yes, the circuits is used like that in the tower kit.
Regards
Mark
