Which vmmc-supply and vqmmc-supply should I choose for WiFi/Bluetooth SDIO module?

Hello. I am working on a custom board that was designed with the reference of the Xavier NX P3509_A01_Concept_schematics.pdf. Although this board supports the Xavier NX, we are currently using the Nano with it.

The board has an on-board WiFi/Bluetooth Module. It connects to the Nano with the SDIO interface. Because the board was designed using the Xavier NX Schematics, the power tree is the same.

P3509_A01 : 19.5V (VDD_DCIN) -> TPS53015 (VDD_5V_SYS) -> TPS53015 (VDD_3V3_SYS) -> TLV70018 (VDD_1V8) -> GS7116S5-ADJ-R (3V3_AO)

Custom Board: 24V (VDD_DCIN) -> TPS53015 (VDD_5V_SYS) -> TPS53015 (VDD_3V3_SYS) -> LDL212 (3V3_AO)

The WiFi/Bluetooth Module is powered using VDD_3V3_SYS. While VDD_1V8 is also supplied to it. It uses the VDD_1V8 as a supply for its SDIO signals.

Right now the card is not initialising. I have enabled the MMC logs which floods the dmesg. I am using the UART debug to monitor the bootlogs.

[    3.803188] mmc1: SDHCI controller on sdhci-tegra.2 [sdhci-tegra.2] using ADMA 64-bit with 64 bit addr
[    3.803209] mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    3.810362] mmc1: mmc_rescan_try_freq: trying to init card at 300000 Hz
[    3.871230] mmc1: mmc_rescan_try_freq: trying to init card at 200000 Hz
[    3.920555] mmc1: mmc_rescan_try_freq: trying to init card at 100000 Hz

The above messages are seen in the bootlogs.

I have also tried unbinding and rebinding the sdhci driver. This allows me to get the dmesg logs and mmc tracing logs. I am attaching the bootlogs, dmesg and mmc tracing logs with my following post because of the one link for new user limit.

I have also made the necessary changes to the device tree as suggested by the vendor. Although I am confused about the supplies to be used for vmmc-supply and vqmmc-supply. Right now, I have created two dummy regulators with reference of the regulators in the Xavier NX tegra194-fixed-regulator-p3509-0000-a00.dtsi file.

Xavier NX Board:

hdr40_vdd_3v3: p3509_vdd_3v3_cvb: regulator@101 {
	compatible = "regulator-fixed";
	reg = <101>;
	regulator-name = "vdd-3v3-cvb";
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
};

p3509_vdd_1v8_cvb: regulator@102 {
	compatible = "regulator-fixed";
	reg = <102>;
	regulator-name = "vdd-1v8-cvb";
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
};

Custom Board:

dummy_regulator_3v3: regulator@11 {
	compatible = "regulator-fixed";
	reg = <11>;
	regulator-name = "dummy_regulator_3v3";
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
};
dummy_regulator_1v8: regulator@12 {
	compatible = "regulator-fixed";
	reg = <12>;
	regulator-name = "dummy_regulator_1v8";
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
};

Please remember these are dummy regulators for the VDD_3V3_SYS and VDD_1V8. I am also attaching the device tree from runtime taken from /proc/device-tree. You can find the sdhci@700b0400 node in it.
proc_device-tree.dts (287.8 KB)

Can someone please look at this and suggest any changes if required? Also, I am not sure whether to use the nvidia,vmmc-always-on and nvidia,vqmmc-always-on properties.

Any input is appreciated.

Thanks and Regards,
Abhijit

These are the bootlogs, trace logs and dmesg logs.
dmesg_logs_on_rebinding_sdhci2.txt (9.7 KB)
mmc1_tracing_logs_on_rebinding_sdhci2.txt (12.1 KB)
bootlogs.txt (57.3 KB)

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

Hi @kayccc I still need some help with this.

I have since my last post managed to get the WiFi/Bluetooth module get detected on SDIO. It actually turned out that there was a resistor missing on the board. Also, made a couple of changes to the device tree. After this the SDIO card gets detected and both WiFi and Bluetooth are functional. But on some boots / reboots the module doesn’t get initialised.

When I look at cat /sys/kernel/debug/mmc1/ios/ it shows:

# cat /sys/kernel/debug/mmc1/ios                                                                                                                                                       
clock:          0 Hz
actual clock:   99221 Hz
vdd:            0 (invalid)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     0 (off)
bus width:      0 (1 bits)
timing spec:    0 (legacy)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

If I then go ahead and unbind and bind the sdhci2 driver, the module gets detected.

WiFi and Bluetooth and both functional and cat /sys/kernel/debug/mmc1/ios/ shows:

root@b2qt-jetson-nano-emmc:~# cat /sys/kernel/debug/mmc1/ios
clock:          204000000 Hz
actual clock:   204000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

These are my results from multiple restarts and cold boots:

Reboot 1: SDIO Card not initialised. Rebind: Success.
Reboot 2: SDIO Card not initialised. Rebind: Success.
Reboot 3: SDIO Card not initialised. Rebind: Success.
Reboot 4: SDIO Card not initialised. Rebind: Success.
Reboot 5: SDIO Card not initialised. Rebind: Success.
Reboot 6: SDIO Card not initialised. Rebind: Success.
Reboot 7: SDIO Card not initialised. Rebind: Success.
Reboot 8: SDIO Card initialised. Rebind: Success.
Reboot 9: SDIO Card initialised. Rebind: Success.
Reboot 10: SDIO Card not initialised. Rebind: Success.

Cold boot 1: SDIO Card initialised. Rebind: Success.
Cold boot 2: SDIO Card not initialised. Rebind: Success.
Cold boot 3: SDIO Card initialised. Rebind: Success.
Cold boot 4: SDIO Card not initialised. Rebind: Success.
Cold boot 5: SDIO Card not initialised. Rebind: Success.
Cold boot 6: SDIO Card not initialised. Rebind: Success.
Cold boot 7: SDIO Card initialised. Rebind: Success.
Cold boot 8: SDIO Card not initialised. Rebind: Success.
Cold boot 9: SDIO Card not initialised. Rebind: Success.
Cold boot 10: SDIO Card initialised. Rebind: Success.

Attaching the device tree from /proc/device-tree/ with this post. What can be the cause of the module not getting initialised randomly?

proc_working-device-tree.dts (287.8 KB)

Please attach full dmesg when the error happened.

Hi @WayneWWW,

Please find the attached bootlogs from the UART debug port. Because I have the CONFIG_MMC_DEBUG=y, the dmesg overflows with mmc0 messages from the emmc.

If the bootlogs are not enough and you need the dmesg, I will disable the CONFIG_MMC_DEBUG and rebuild the OS to give you the dmesg output. Please let me know.

init_failure_bootlogs.txt (58.7 KB)

Thanks and Regards,
Abhijit

please also attach your schematic.

Hi @WayneWWW ,

As the schematic is a confidential file, I will share it via a direct message.

Thanks and Regards,
Abhijit

Hi @abhijit.kambli ,
I checked the SDIO circuit of schematic you sent to us. Some suggestions as below,
1). According to Jetson_Nano design guide, there is no pull-up request on SDIO interface. So, R297, R298, R299, R300, R301, R302 can be No suff.
2). I don’t see WIFI_EN signal for WIFI Module. Is it WIFI_CTRL signal ?
3). On Jetson_Nano mudule, SDMMC3 is routing to based board for SDIO application. Pleaes make sure you configure proper pinmux for it.
4). Please try to measure power sequence of SDIO interface including 3V3_WIFI_MCD, VDD_1V8, WIFI_EN, WIFI_WAKEUP , SD_CLK signals when system boot and reboot. To see if the power sequency is matched with WIFI module requirement.

Thanks,

Hi @pepan ,

1). According to Jetson_Nano design guide, there is no pull-up request on SDIO interface. So, R297, R298, R299, R300, R301, R302 can be No suff.

We have removed the R301. But the rest of the Resistors you mentioned are required as per the WiFi Module Documentation. Will having the other resistors cause an issue?

2). I don’t see WIFI_EN signal for WIFI Module. Is it WIFI_CTRL signal ?

I think its the PMIC_ENABLE (Enables Input for All Regulators). This signal needs to go high with or after the VBAT and VIO.

3). On Jetson_Nano mudule, SDMMC3 is routing to based board for SDIO application. Pleaes make sure you configure proper pinmux for it.

Is this the correct setting?

I am working on the Power Sequencing right now. Will soon posts the results for the same.

Thanks and Regards,
Abhijit

Hi @pepan ,

Please take a look at these scope images.

Yellow (Channel 1) is the PMIC_EN signal (Enables Input for All Regulators).
Green (Channel 2) is the 1V8 power rail connected to VIO_SD.
Blue (Channel 3) is the 3V3 power rail connected to VBAT.
Pink (Channel 4) is the SD_CLK signal.

Scope when module is initialised:

Scope when module is not initialised:

SD_CLK when module is initialised:

The SD_CLK seems to stay low when the module is not initialised. If initialised it is high. You can see that the frequency is 205.61 MHz.

What could be the reason that the clock stay low at times?

Thanks and Regards,
Abhijit

Hi @pepan @WayneWWW @kayccc ,

In addition to the above scope images, please also check the following dmesg output.

Earlier I some messages were lost. But now I have increased the Kernel log buffer size to 2097152 bytes. I have also changed LOG_LINE_MAX in printk.c:

-#define LOG_LINE_MAX		(2048 - PREFIX_MAX)
+#define LOG_LINE_MAX		(8192 - PREFIX_MAX)

Now I can read the whole dmesg from system startup.

I am attaching two dmesg files, one for where the card gets initialised, and one for where it doesn’t get initialised. CONFIG_MMC_DEBUG is enabled and the mmc1 logs are for the WiFi/BLE module.

Please let me know if you have any questions.

Thanks and Regards,
Abhijit

full_dmesg_initialised.txt (1.3 MB)
full_dmesg_not_initialised.txt (1.2 MB)

Hi @abhijit.kambli ,
Sorry for late reply.
After looking at power sequence you measured, there are couple things noticed from HW prespectives,
1). According to Signal Voltage Switch Swqurnce of SD Specification as attached captured shown, the SD_CLK seems has been changed signaling level from 3.3V to 1.8V successfully by HOST starts the voltage switch protocal. However, the SD_CLK is only around 0.8V signaling level. Could you please remove all pull-up resistors and then re-meaure SC_CLK / SD_CMD/ SD_DAT on SD bus to compare original one (stuffing all pull-up resistors) if signaling level of SD bus become normal to 1.8V or not ?
Please be noted Jetson nano shall have internal pull up resistors on SD bus by pinmux setting.


2). According to step (5) above, it states The card’s 1.8V voltage regulator shall be stable within 5ms of SD_CLK going low. Comparing to the waveforms between module is initialized and Not initialized, you can see PMIC_EN signal (Yellow (Channel 1)) toggles many times after SD_CLK going low with around 20s long. That seems cause All Regulators on the card are not very stable. Could you try to not toggle PMIC_EN signal many times ? And Could you try to enable PMIC_EN signal as earier as possible to meet the requirement ?

1 Like

Hi @pepan,

The info shared above explains several things.

This issue was occurring because of the USB_PRT_PWR3 (from USB 3.0 hub) pin being connected to the PMIC_EN of WiFi/BLE module. When USB_PRT_PWR3 is isolated from the PMIC_EN by demounting the diode connecting them, the initialisation issue is solved. The PMIC_EN stays stable through the initialisation sequence. It seems like the USB hub toggles the USB_PRT_PWR3 line multiple times during reboot or cold boot.

This is the power sequence after demounting the D26:

Yellow (Channel 1) is the PMIC_EN signal.
Green (Channel 2) is the 3V3 power rail for VIO and VBAT (Card Power).
Blue (Channel 3) is the 1V8 power rail for VIO_SD (IO lines).
Pink (Channel 4) is the SD_CLK signal.

We tried reboots and cold boots many times and the card was initialised at SDR104 every time. So we have a 100% initialisation rate.

Thanks a lot for the help.

Regards,
Abhijit.

1 Like

Hi @abhijit.kambli ,
Sounds good. Thank you for update. I believe this ticket can be closed.

Regards,

1 Like

Hi @pepan ,

Please go ahead and close the ticket.

Thanks and Regards,
Abhijit.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.