Is it possible to operate the SDIO at 1.8V rather than 3.3V for the Apalis TK1 on the Apalis Evaluation Carrier board?
Yes, just make sure to remove the 3.3 volt pull-up resistors first.
Great, thanks for your quick response. Looking back at the Apalis TK1 datasheet and referencing the Evaluation Board schematic, in order to use MMC1 at 1.8V, I need to:
- Remove all relevant pull-up resistors as you said. (R46, R47, R48, R49, R50, R51, R52, R53, R54, R55)
- Enable TK1 Internal pull-up
- Configure LDO1 to 1.8V via LDO output voltage register of the PMIC.
Do you know of any relevant documentation for configuring the LDO output voltage register of the PMIC within the OpenEmbedded BSP for TK1?
Also, can you provide direction for configuring internal pull-ups on TK1 as the TK1 isn’t included in the Device Tree Customization page?
Thanks!
- Remove all relevant pull-up resistors as you said. (R46, R47, R48, R49, R50, R51, R52, R53, R54, R55)
Yes, exactly.
- Enable TK1 Internal pull-up
This is really already taken care of.
- Configure LDO1 to 1.8V via LDO output voltage register of the PMIC.
This is also already taken care of.
Great, thanks!
You are very welcome.
I now see this article (High performance, low power Embedded Computing Systems | Toradex Developer Center) where it says that I should remove R46 to R54 in order to operate in UHS mode. I had already removed R55 in addition to these. R55 was the 3.3V pull-up on C/D. Will this cause me a problem when attempting to operate in UHS mode? My understanding is that it should not be a problem because of the TK1 internal pullup.
The article I reference above also says that I need to activate UHS mode using the following command:
- fw_setenv defargs ‘core_edp_mv=1300 usb_high_speed=1 mmc_uhs=1’
I have done this but I am not able to get my UHS mode device to work. My regular HS mode SD Card still works even with these modifications.
Am I missing anything in regards to configuring to work in UHS mode?
The specific kernel error messages that I am seeing when I plug in my UHS mode device are here:
[ 3853.397178] sdhci-tegra sdhci-tegra.0: Found T2T coeffs data
[ 3853.413032] sdhci-tegra sdhci-tegra.0: 200MHz tap hole coeffs found
[ 3856.502509] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3856.515882] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3856.522684] mmc1: error -22 whilst initialising SDIO card
[ 3859.735119] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3859.742478] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3859.749108] mmc1: error -22 whilst initialising SDIO card
[ 3863.030047] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3863.036675] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3863.043377] mmc1: error -22 whilst initialising SDIO card
[ 3866.235007] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3866.242152] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3866.249107] mmc1: error -22 whilst initialising SDIO card
[ 3869.448131] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3869.455508] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3869.463560] mmc1: error -22 whilst initialising SDIO card
[ 3872.678081] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3872.684811] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3872.692576] mmc1: error -22 whilst initialising SDIO card
[ 3875.970715] sdhci-tegra sdhci-tegra.0: All tap values(0-255) failed
[ 3875.977663] sdhci-tegra sdhci-tegra.0: Failed to get tap win -22
[ 3875.983971] mmc1: error -22 whilst initialising SDIO card
I now see this article (High performance, low power Embedded Computing Systems | Toradex Developer Center) where it says that I should remove R46 to R54 in order to operate in UHS mode. I had already removed R55 in addition to these. R55 was the 3.3V pull-up on C/D. Will this cause me a problem when attempting to operate in UHS mode? My understanding is that it should not be a problem because of the TK1 internal pullup.
I would also not think so. However this rather being a hardware question I will also forward it to our hardware engineers to comment on.
The article I reference above also says that I need to activate UHS mode using the following command:
fw_setenv defargs ‘core_edp_mv=1300 usb_high_speed=1 mmc_uhs=1’
I have done this but I am not able to get my UHS mode device to work. My regular HS mode SD Card still works even with these modifications.
No, above mmc_uhs=1 is only applicable to Apalis T30.
Am I missing anything in regards to configuring to work in UHS mode?
No, but assuming you are trying this with some SDIO device of unknown compatibility I suggest trying it with a regular SD or micro-SD card first.
I double checked with our carrier board hardware engineer and the reason for him to recommend leaving the 3.3V pull-up on the C/D pin is to make sure the card detect is not left floating. However it having a weak software enabled pull-up enabled should also be Ok and in your case the card detection does not seem to be an issue as otherwise the tuning process would not even be starting. One could also e.g. check the C/D interrupts to make sure it is stable (e.g. cat /proc/interrupts | grep GPIO | grep mmc). I really recommend trying a regular UHS-I card first.
Thanks. I had the same thought regarding trying a regular UHS SD card first. I have one on order that will arrive today.
Are there any specific BSP/software modifications that need to be made for the TK1 as the above article was referencing the T30? I believe that your previous response is saying that I don’t need to and even the mmc_uhs=1 is only applicable to the T30. I just wanted to confirm.
It really should work just fine out-of-the-box. However if one does not remove them command/data signal pull-ups one is operating outside any specs but at least most UHS-I cards I have tried mostly worked anyway. With SDIO cards it may be more tricky and also depends on whatever driver being used.
The UHS-I card works. So I need to dive a little deeper into why my SDIO Wifi device is failing to initialize. I thought that the initialization with the sdhci-tegra driver would have worked the same and the device specific drivers would be used later for controlling the device. I will dive a little deeper tomorrow or Thursday.
Thanks.
As mentioned before SDIO devices at times are rather pecky about specific configuration of clocking (e.g. continuousness and frequency thereof) plus may require further out-of-band signals (e.g. reset) being applied in a certain timed sequence. What exact device are you talking about? And what BSP version are you trying this with (as we fixed certain issues over time and integrated backports)?
I’m using a Laird 60 Series Radio. And the OpenEmbedded Linux BSP based on the L4T R21.5 kernel.
Interestingly, when I plug the device into the unmodified MMC2, the initialization gets beyond the tap value stage of initialization (which is where I show it failing above) but then fails on a cmd CRC error. This might be expected since this port still has the pull-ups to 3.3V so would be out of spec as you said before. But I did not expect it to behave differently on MMC2 vs MMC1…
I suggest you updating to our latest 2.7b5 based on L4T 21.6. BTW: What exact module hardware version are you trying this with?
We’re using the Laird ST60-2230C.
I am using the latest 2.7b5. I didn’t realize that was L4T 21.6 rather than 21.5.
I was wrong, I am actually currently using 2.7b4. So I will upgrade to 2.7b5 tomorrow evening when I am able to work on this again to see if that makes a difference.
Do any of the SDIO Wifi devices that you have already tested with the TK1 operate in 1.8V mode or do they operate at 3.3V?
Any recommendations if we decide to switch away from the Laird ST60-2230C?
I am going to re-post the Wifi recommendation question as a different topic since my initial question in this thread has been resolved. Thanks.
Your are very welcome.