Hi Peter
you are right, issue may be caused by mismatch between
VCCQ =1.8V eMMC I/O power supply interface and i.MX6
I/O interface powered by NVCC_NANDF= 3.3V.
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thank you.
Can't we switch this NVCC_NANDF 3.3V to 1.8V low voltage using u-boot or any other way. Because this problem cause conflicts all the 1.8V supply by over riding it to 2.3V. (EMMC VCCQ give 2.3V output due to above level mismatch)
Do you have any idea to overcome this problem rather than changing all the hardware design ?
Regards,
Peter.
you should program pmic so it produced NVCC_NANDF 1.8V,
preferably using pmic otp fuses option. Overdriving emmc may
cause its reliability issues (this may be discussed with emmc vendor).
Best regards
igor
Hi igorpadykov
Thank you for your prompt reply.
"You should program pmic so it produced NVCC_NANDF 1.8V,
preferably using pmic otp fuses option"
Could you please explain how to do this ? Is this related to some u-boot configuration files ? How can I prefer pmic otp fuses option ? Ho do I program pmic ? I need to know more details on this.
Regards,
Peter.
Hi Peter
please refer to AN4536 MMPF0100 OTP Programming Instructions
https://cache.nxp.com/docs/en/application-note/AN4536.pdf
Best regards
igor
The document provided by igorpadykov gives the hardware details required to OTP-program this part. It looks very complicated to me. You need an external connector and a 9.5V supply
You would be better off programming them in an external fixture before installing them on the board. Maybe you can do this with a "KITPFPGMEVME" kit as detailed in AN4536.
It would be better for you if you could order these part from your distributor to be pre-programmed so they match the way you need them to work.
But there's another question. You should only get the "voltage conflict" if the MPU is driving the "SD4_DATAn" and the three clock/control pins HIGH to 3.3V levels. If these pins are initialised to open-circuit or driven LOW then there shouldn't be any voltage conflict. You should then have enough time for U-Boot to reprogram the regulator over its serial port to switch it to 1.8V. Then after a long enough time (for the voltage to drop to 1.8V) you can enable the SD4 pins to go active.
if this is to work you'll have to check the POR (reset) values for all the SD4 pins to see if they default to floating, or at least have a high-value (100k or so) pullup resistor. According to the manual they seem to default to "GPIOI7".
Then they may get reprogrammed by the INTERNAL boot code in the i.MX6, depending on the boot mode strapping and fuses. Read through the "System Boot" chapter. Are you booting from "Expansion Device" (meaning the eMMC)? If you are then you can't fix this from U-Boot as it doesn't get in charge until later.
Then it loads U-Boot, including the big block of config data (DCD I think) that reprograms the pins (and other things in the CPU) so it is set up prior to even loading and starting the boot.
Then that Boot defaults the pins the way it wants them, then any "drivers" inside the boot may have another go at them. They may change again prior to loading the Kernel.
Which may then change them again in the startup code and/or the Device Tree.
So somewhere in that sequence you have to reprogram the PMIC before any of the SD4 pins drive high.
Why not change the hardware to drive the CPU's NVCC_NANDF pins from the EMMC's VCCQ supply? Maybe your design is that point where you want to avoid a hardware change.
Good luck.
Tom
Hi Tom,
Really appreciate your explanation regarding this matter !!!
For your understanding I'll explain the problem again.
A basic rule of electronic design is that you simply can't supply voltages to pins on a chip that are outside of the power supply range. There are a few cases where you can disobey this, but they are few and documented. Youe design isn't one of those. It is simply an invalid design to have the CPU I/O running from 3.3V while the eMMC is running from 1.8V.
The chips have "protection diodes" connected from the pins to ground and power to divert currents from pins that are too high or low. So the CPU is driving 3.3V into the DQ4 lines, and the current is going through those protection diodes into the 1.8V power supply on the eMMC chip. That is called an "injection current". Chips have "injection current limits" that you aren't allowed to exceed. You don't know what currents you're "injecting" and Micron doesn't document what they are in the short Data Sheet I've just read.
Type "integrated circuit current injection limits" into Google and read the "Chapter 1 BASIC CONCEPTS IN EMC FOR ICS - ResearchGate" article.
I've just read the data sheet for that chip. Without going into sufficient detail it says.that Vcc is 3.3V, and that Vccq can be either 1.8V or 3.3V. It doesn't give any details on why one is better than the other. I'm pretty sure it is so you can interface the chip to controllers that are either 3.3V I/O or 1.8V I/O ones.
I think you should change Vccq to 3.3V. That would solve the problem most easily. That would guarantee you're not exceeding injection or voltage limits at any time when the board is starting up.
How can you get U-Boot to reduce the voltage? If it doesn't have a command or module that can control the PMIC then you'll have to write one. If it does have a module you'll have to find some documentation or read the code to find out hos it works. If it isn't done for you, you'll have to read the PMIC Data Sheet and work out how to control it through its registers.
When you said you "disconnected 1.8V" do you mean you left the power input floating and not connected to anything? Or did you connect it to the 3.3V supply instead? You can't leave it floating, that's an invalid design. Connecting it to 3.3V is probably the right thing to do.
Tom
Hi @Tom Evans
Thank you for your prompt reply.
1)
"A basic rule of electronic design is that you simply can't supply voltages to pins on a chip that are outside of the power supply range. There are a few cases where you can disobey this, but they are few and documented. Youe design isn't one of those. It is simply an invalid design to have the CPU I/O running from 3.3V while the eMMC is running from 1.8V."
We can provide NVCC_NANDF up to 1.65V to 3.6V range according to NXP IMAX6 documentations. EMMC has dual supply and that was 1.8V and 3.3V. That is my mistake I thought EMMC I/O will control from VCC and I didn't think about VCCQ supply. VCCQ is the I/O supply of the emmc interface and VCC supply is the NAND interface of the EMMC.
2)
"When you said you "disconnected 1.8V" do you mean you left the power input floating and not connected to anything? Or did you connect it to the 3.3V supply instead? You can't leave it floating, that's an invalid design. Connecting it to 3.3V is probably the right thing to do."
I left it floating and it still working properly. Any comment on that ? How it will happen ? Yeh I know it is invalid and I'm still in prototype stage of this hardware design and it has been corrected in next designs.
Regards,
Peter.
> I left it floating and it still working properly. Any comment on that ?
Yes, Simple basic electronics. There are diodes in there. Read the following, it details it well enough.
How does the Reference Design provide 1.8V to the CPU I/O pins? Have you changed to a different PMIC to the one they're using? Why do something different, that adds work. There's another problem with making your design different to the Reference Design (Nitrogen), assuming you have. If you change from their 1.8V to 3.3V for the eMMC I/O then you may have to change the CPU's Drive Strength settings on those pins to match. The pin settings are very flexible, but very complicated. You should be able to find the section in the Reference Manual that details this - Chapter 36 "IOMUX", and there are about 720 PAGES detailing this! I said it was complicated...
I would expect the "Hardware Development Guide" would tell you about this, but it doesn't seem to even mention this interface at all:
IMX6DQ6SDLHDG.pdf
There should be documentation on the customisation of U-Boot and any extra i.MX6 and PMIC commands that have been added for your use. And any code changes that have been made for that platform. Is there any?
My experience with earlier Freescale chips is that they need different drive settings for different voltages. So if you change the voltage you may need to change the settings. You should first real all the documentation on the CPU and the development board to see if they answer this question. If they don't then you may have to ask here. That assumes that the pins have been set up properly already for that voltage, and they may not have been. They may still be at "chip reset default", and that may not be optimal.
Igor may respond here with details on this.
Tom
Hi Peter
Tom right, different drive settings for different voltages may be needed, in linux this is pad settings in dts file, like
pinctrl_usdhc2: usdhc2grp.. in linux-imx6/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_4.1.15_1.0.0_ga/arch/arm/boot/dts/im...
drive strength, DSE field is described for example in sect.36.4.461 Pad Control Register (IOMUXC_SW_PAD_CTL_PAD_SD2_DATA3)
i.MX6DQ Reference Manual
http://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf
Best regards
igor
That example gives the "Drive Strength" as being one of 33, 40, 50, 60, 90, 130 or 260 ohms.
The customer would probably like to know what value is appropriate for the eMcc interface at 3.3V and what is appropriate at 1.8V. And this may depend on the clock speed.
As well, is there a command in the U-Boot in that development kit that allows the PMIC voltages to be changed? Otherwise, are there any compile-time changes needed for this? Does that U-Boot support that PMIC?
Tom