Hello,
I’m attempting to use Flash.sh (nvflash) to program the bootloader onto a custom TK1 design, I believe I have the TK1 powered to the correct state, but I’m never able to detect the TK1 as a USB Device either when running NVFlash, or with “lsusb”. Here is the command that I am running:
sudo ./flash.sh /bootloader/ardbeg/uboot.bin jetson-tk1 mmcblk0p1
USB device not found
If I connect the TK1 Dev Card and run the same command, I’m able to detect the TK1 as a USB device and program the bootloader.
I believe that the AS3722 power sequencer has powered up everything that should be powered ON in Reset Recovery mode on the Dev Card, here is a comparison between our module and the Dev Card in Reset Recovery Mode:
Tegra K1 Pin TK1 Dev Card Voltage TK1 Module Voltage
CLK_32K_IN 1.8V @ 32.68KHz 1.8V @ 32.68KHz
CLK_32K_OUT 0.0V 0.0V
SYS_RESET_N 1.81V 2.093V
VDD_RTC 1.05V 1.048V
VPP_FUSE 0.0V 0.0V
CORE_PWR_REQ 1.81V 1.79V
+1.05V_LPO_VDD_RTC 1.051V 1.048V
+VDD_CORE 1.10V 1.101
+1.8V_VDDIO 1.81V 1.7995
+1.35V_LP0 1.35V 1.3564
+1.05V_RUN_AVDD 1.051V 1.0465
I’m able to see that the Tegra K1 is outputting a clock to the EMMC memory at pin G31 (SDMMC4_CLK), so it does seem like the K1 is powered ON and attempting to use it’s EMMC interface.
I’m able to detect the Tegra K1 on the JTAG Chain, what functionality does access to the JTAG port on the Tegra K1 give? Am I able to read registers to determine the status of the TK1?
A few questions I have:
• Are there any output signals from the Tegra K1 that clearly indicate that is Powered ON and in Reset Recovery Mode? I do see a reduction of current on the DC supply powering the module when I put the board in Reset Recovery Mode, I took this as a good indication that it is in Reset Recovery Mode.
• After the AS3722 has powered up successfully, is programming the bootloader using FLASH the next step in the bringup process for the Tegra K1?
• How do I communicate with the TK1 over JTAG? I have the BSDL file, is there a suggested application?
Thanks in advance for any advice/suggestions you can provide!
Jeff
What is the function of the Board ID ROM? Does the board ID ROM need to be programmed to recognize the TK1 as a USB device? I haven’t been able to find much info on this in the NVidia documentation
I have not built a custom TK1 board so I don’t know much about this chip, but I have seen others with the same difficulty…the chip is involved in flash and has been the cause of others in the past having problems flashing.
I have Push buttons connected to GPIO_PI1 (FORCE_RECOVERY_L) and to XRES_IN of the AS3722, this matches what I see in the TK1 Dev Card schematic. I then hold the Recovery PB, then press and hold the Reset for a minimum of 2 seconds, and then release the Reset PB followed by the Recovery PB.
After doing this I can see on my DC supply that my card is using less current than when the card is not in Recovery Mode, so I took this as a good indication that I was successfully putting it in recovery mode.
Are there any outputs from the TK1 that indicate that its in Recovery Mode?
Thanks! I think it must be involved in flashing the bootloader, because if I remove the Board ID ROM from the TK1 Dev Card I’m no longer able to program the bootloader. I am still able to detect the TK1 Dev Card as a USB Device using lsusb, and do not get the same “USB device not detected error” that I’m seeing on my custom board, so I don’t think that’s the issue that I’m seeing (yet)
I’m keeping the Recover PB pressed for probably 1 second after releasing the Reset PB.
I’m using USB0 on the TK1 so I believe I’m using the correct USB controller, but I do have a USB LAN controller connected to USB1, could this be affecting the boot cycle?
FYI, the micro USB OTG connector is in host mode at all times when Jetson isn’t in recovery mode. Your non-Jetson host connected to Jetson via the provided micro-B will never see anything about this Jetson in lsusb until Jetson enters recovery mode (this is when the connector enters device mode instead). Even if flash won’t work for other reasons, seeing the board show up on the host via lsusb is proof of recovery mode.
Sorry about the formatting, I can’t figure out how to upload tables of data, but I’ve done a ball-to-ball comparison between the Tegra K1 Dev Card, and my custom TK1 design. Here are all the pins where I saw a difference in voltage:
TK1 Pin Pin Number Dev Card State Custom TK1 State Notes
SDMMC3_CD_N V24 1.786 NC
KB_COL4 AF28 1.789 NC
KB_COL5 AA27 1.814 NC
KB_ROW7 Y30 0.900 NC
JTAG_TDI H5 1.81 0.0
AVDD_LVDS0_PLL AF1 3.31 1.816
UART2_RXD L9 1.81 0.0
GPIO_PB0 U4 1.81 0.0
GPIO_PG5 AA3 1.81 2.5Vpk/pk @ 2.9MHz
GPIO_PI3 V7 1.81 0.0
GPIO_PK1 R3 0.0 NC
GPIO_PK2 Y1 1.81 2.5
GPIO_PK4 T1 1.81 NC
GPIO_PK7 V5 0.0 1.796
GEN2_I2C_SCL Y2 3.31 1.796
GEN2_I2C_SDA AA2 3.31 1.426
PEX_L1_CLKREQ_N AJ30 0.0 3.32
PEX_L0_RST_N AJ29 0.0 3.31
Still trying to work through this issue, does anyone know if pin K31 - VDDIO_AUDIO is required for startup?
Currently I have this pin not connected on my design, so I don’t have access to this to connect +1.8V, but it is listed in the startup process of the Design Guide. Unfortunately the Jetson TK1 Dev Card has this pin connected directly to +1.8V, so there is no way for me to remove the voltage from the Dev Card to attempt to cause it to fail.
Our design also leaves VDDIO_CAM disconnected, so this is another potential issue.
Was wondering if anyone has any experience/success with a design where VDDIO_AUDIO or VDDIO_CAM were left NC
Thanks
Was able to determine the problem. My schematic mistakenly had two nets for +3.3V_LPO, one named +3.3V_LPO, the other named +3.3V_LP0, which had no source and was connected to AVDD_USB. Thanks to everyone who chimed in to help!