Hi,
I'm learning to use the configuration tool (and everything else) and I would like to route both the SEMC and USDHC2. They compete for pin [D6] GPIO_EMC_38.
I suppose I should give priority to the SEMC. Does that mean I can not use the USDHC2, which needs the pin for its VSELECT function?
Is there a workaround for this case, i.e. use a GPIO configured as Output for USDHC2's VSELECT, and somehow inform the driver to use that particular pin for what appears to be a simple function, or maybe I can leave the eMMC chip in it's 3.3V power-on default?
USDHC1 also conflicts with the SEMC's clock, is it really that I must choose between using SDRAM or using MMC's?
Please advise, thanks!
Solved! Go to Solution.
Hi @axelrietschin ,
Yes, USDHC2_VSELECT and SEMC_DM1 both are mux to GPIO_EMC_38 only. VSELECT functionality can be replaced with a GPIO, VSELECT is optional for system implementation and it requires a control circuit to change the voltage.
As you can see in the NVCC_SD section of the EVK schematics when the VSELECT pin is high it will turn on the transistor and the 234K resistor in parallel will be activated. As a result we will have NVCC_SD with 1.8V. This same behavior could be implemented with a GPIO as well.
And as I can see, SEMC_CLK doesn't conflict with any of USDHC1 pin.
Regards,
Jing
Hi @axelrietschin ,
Yes, USDHC2_VSELECT and SEMC_DM1 both are mux to GPIO_EMC_38 only. VSELECT functionality can be replaced with a GPIO, VSELECT is optional for system implementation and it requires a control circuit to change the voltage.
As you can see in the NVCC_SD section of the EVK schematics when the VSELECT pin is high it will turn on the transistor and the 234K resistor in parallel will be activated. As a result we will have NVCC_SD with 1.8V. This same behavior could be implemented with a GPIO as well.
And as I can see, SEMC_CLK doesn't conflict with any of USDHC1 pin.
Regards,
Jing
Awesome, thanks!