elodg
-
Posts
343 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by elodg
-
-
It look like you board flow interfaces are not picked up. Dig further.
-
If you open the synthesized design and navigate to the InputBuffer cell of dvi2rgb you will probably see the input tied to a constant, which causes placement to complain. Check the block design where the TMDS port of IP is tied to. It must go to a top-level port and it has to be constrained to a pin. If you are using board flow and it connects to a board interface, it should be set. Check the top-level wrapper vhd to confirm the top-level ports are generated for the HDMI/DVI input.
-
Yeah, ISE is no good as it does not work on Win 10. It last worked on Win 7, but that is outdated as well. You need to go with Vivado.
OPTION#1 Vivado 2021.1 can pull in the board catalog form XilinxBoardStore, which is has the Zedboard defined. Just click Refresh.
The XilinxBoardStore lists it under avnet.com as vendor:
OPTION#2: You can install our board files using the steps from https://digilent.com/reference/vivado/installing-vivado/2018.2?s[]=vivado&s[]=init&s[]=tcl#installing_digilent_board_files.
-
We do not support non-Petalinux flows. However, I am attaching the final dts that results from the Petalinux build of https://github.com/Digilent/Genesys-ZU-OS/tree/3eg/oob%2Frelease%2Fv2.1. Do as you please.system-top.dts.pp
-
There are two separate issues related to flash device support on Xilinx platforms: Vivado support and software support. It seems that you are looking for the former, while this whole thread is about the latter. Vivado support is documented for each version in ug908, Appendix E: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2021_1/ug908-vivado-programming-debugging.pdf#_OPENTOPIC_TOC_PROCESSING_d114e38049. It refers to the capability of Vivado hardware manager to be able to erase and program the memory device. There are no steps involved, Xilinx either supports it or not. I added a note to the reference manual about the minimum requirement for the Vivado version that supports the Macronix part.
What others were discussing in this thread is flash support in software running on the FPGA device using the xilifs library. This is an open-source library that Xilinx includes in their Vitis tools and has a seperate list of supported devices. This we can edit and extend, which the documentation is referring to.
-
I would recommend using Michael's step-by-step guide (which is also in https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start) and editing the files in-place if you are not comfortable with versioning tools and patching sources.
-
Will update this thread when we have a conclusion.
-
Current consumption is not limited by the FPGA. Furthermore, thermal dissipation coefficients are board-dependent. Vivado has no way of knowing what the limitations of the board are.
The board was designed with a 2.6 A current limit because that is what it can safely dissipate. All the power components are sized accordingly. You should refer to the board reference manual for power supply limitations: https://reference.digilentinc.com/programmable-logic/arty-z7/reference-manual#power_supplies, not the individual datasheet of the on-board regulator. We do not recommend you changing the current limit in TPS65400RGZ and drawing more current than the designed maximum. It will void your warranty.
-
I am sorry to hear about your troubles. Unfortunately, we only tested (m)SATA with 2019.1 and it looks to me that Xilinx changed the GTR calibration procedure in the FSBL since then. I suggest using 2019.1 with the Genesys-ZU-OOB-os/hw repos, which is the supported version.
In the mean time we will investigate how the GTR link training changes affect SATA in 2020.1.
May I ask what other issues needed fixing in the devicetree?
-
FMC modules are inserted in series into the JTAG chain. FMC modules must make sure to insert a device there or loop TDI back to TDO if JTAG is not used.
According to the schematic jtag signals go to a header:
https://www.xilinx.com/support/documentation/boards_and_kits/xtp078.pdfJust short the TDI and TDO pins on the module with a jumper.
-
If you are on external power already, then you are hitting most probably the current limit of one of the power supplies. Since it sounds like you are increasing the frequency of the programmable logic, most probably the VCCINT supply (1.0V) is getting limited. Since power consumption is project-dependent, do a power analysis in Vivado with the implemented project. However, only very complex designs should be hitting the 2.6A current limit on the 1.0V rail. Your project might not even meet timing constraints anymore with high logic utilization and high operating frequency. In other words, you might be having functional problems too with your project, apart from the current limit.
-
You are most probably hitting the USB port power limit (you did not specify how you are powering the board). The Arty-Z7 RM applies to the PYNQ-Z1 as well: https://reference.digilentinc.com/programmable-logic/arty-z7/reference-manual#power_supplies.
-
On 1/12/2021 at 5:29 PM, malexander said:
I was able to get the SREC bootloader working on a Cmod A7 - 35T that has the Macronix flash using Vivado 2019.1. To get this to work you have to include the Xilinx QSPI controller in your Microblaze block design and in the IP configuration either select "Standard" for the mode (SPI x1 mode) or if you select "QUAD" then make sure to select "Macronix" for Slave Device.
Once you are in SDK and have created the SREC bootloader project (and associated BSP) you need to open "bootloader.c" from the sources and scroll down until you find the call to "XIsf_Initialize". Double click the function name to highlight it, right click and select "Open Declaration". Once you have "xilisf.c" open do the following:
1. Somewhere near the top of xilisf.c add the following:
#define XISF_MACRONIX_DEV_MX25L3233F 0x2016 /**< Device ID for MX25L3233F */
2. In xilisf.c find the definition for IntelStmDevices[] and add the following:
{XISF_MANUFACTURER_ID_MACRONIX, XISF_MACRONIX_DEV_MX25L3233F,
XISF_BYTES256_PER_PAGE, XISF_PAGES256_PER_SECTOR,
XISF_NUM_OF_SECTORS64},3. Save xilisf.c, which should rebuild the project.
Once you've completed the above steps you need to go through the process of generating a download.bit that has integrated the bootloader elf with the bitstream, program that to the flash at offset 0, and then program your application SREC to the flash at the appropriate offset. I placed my SREC at offset 0x00180000 (same offset I set in blconfig.h of the srec bootloader project) since my bitstream was only ~1100KB. You may need to use a different offset depending on the size of your bitstream+bootloader elf combination.
I suggest that anyone who is unfamiliar with the SREC bootloader process follow the guide linked below but select "Macronix" for the Slave Device and perform the xilisf.c modifications.
https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start
Thanks
MichaelA quick note here. The source files that need editing are part of a library (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841939/xilisf) compiled into a bsp/domain. By navigating to the source files in SDK/Vitis, the local copy of the library's source files are opened. Any modification is done on this local copy and built into the static library (and application) upon build. However, when the source files of the bsp/domain are re-generated (context menu, Regenerate BSP sources), the changes are overwritten from the originals in the Xilinx install directory. Take care this does not happen.
A more permanent solution is forking the library repository (https://github.com/Xilinx/embeddedsw) editing the sources there and including a path to the modified repository in SDK/Vitis Xilinx->Repositories->Global.
-
1. Table 8 from the datasheet shows how pins HSx_P and HSx_N can be swapped by the level translator: http://www.meticom.com/resources/Datasheets/MC20901-V1_08.pdf. It has been done for easier routing in layout.
2. LPx_LANE1 and LPx_CLK and uni-directional because the MC20901 can only do low-power reverse communication on either channel A or E, but only on a single channel. This is a transmission mode part of the MIPI D-PHY spec. The decision was made to make LANE0 the one supporting this mode. This is described in https://reference.digilentinc.com/reference/add-ons/fmc-pcam-adapter/reference-manual?s[]=fmc&s[]=pcam#low-power_reverse_communicationbus_turn-around_bta. Our Pcam 5C does not support low-power reverse com, but some other sensors might.
The direction of communication is opposite of what you described. IC10 with DIR to GND transmits from B to A, or Pcam to FMC. -
Quote
[Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timing violations.
Is a known issue in our D-PHY IP.
QuoteI'm getting no error but still not able to get the image on the screen or the menu on the terminal.
If you are getting nothing on the terminal I suspect you messed up something in the Vivado project while porting to 7010. I do not want to sidetrack you, but you could try the latest version of the project (2020.1), which has a 7010 port too: https://github.com/Digilent/Zybo-Z7-SW/tree/10/Pcam-5c/next.
It uses a new project structure and versioning rules. Read this: https://reference.digilentinc.com/reference/programmable-logic/documents/git#vitis_sw_workspaces
-
I sent a PM to @manboy and @Paul Chang on this matter.
-
Frustratingly, I could never find the equation that worked consistently across resolutions for the HS values the camera uses. The sensor datasheet is not exactly verbose on the matter. Xilinx MIPI DPHY IP support is expected together with UltraScale+ support in a month or so. You can try setting a large value in the sensor for HS_ZERO, and try increasing HS_SETTLE in D-PHY Rx until it works.
-
You are on the right track. The settings that control the timing of the low-power high-speed transition need to match between the transmitter and receiver. It is easier if you scope it, triggering on an LP-10 state and measuring the time it takes for the sensor to switch to high-speed.
The following registers control the camera timing:
//MIPI timing // [5]=0 T_LPX global timing select=auto pclk2x {0x4805, 0x10},//Default=0x10 //T_HS_ZERO = MIN HS ZERO + T_UI*MIN HS ZERO_UI //MIN HS ZERO H (ns) {0x4818, 0x00},//Default=0x00 //MIN HS ZERO L (ns) {0x4819, 0xFF},//Default=0x96 //MIN HS ZERO_UI {0x482A, 0x05},//Default=0x05 //T_HS_PREPARE = MIN HS PREPARE + T_UI*MIN HS PREPARE_UI //MIN HS PREPARE H (ns) {0x4826, 0x00},//Default=0x00 //MIN HS PREPARE L (ns) {0x4827, 0x32},//Default=0x32 //MIN HS PREPARE_UI {0x4831, 0x04},//Default=0x04We will get to publishing a Xilinx MIPI IP demo project eventually.
-
@hendog82, give us some info on your setup. What Petalinux version are you using and what kernel and apps recipes you configured for ptp?
-
The schematic can be found on this page: https://reference.digilentinc.com/reference/programmable-logic/cora-z7/start.
The USB OTG Controller in the Zynq and the USB3320 PHY are versatile and support all USB roles, which is why you see it working.
Your concern must be with the VBUS pin that can be supplied by the host or the OTG-A device. The power switch/current limiter NCP380 on the Cora Z7 is controlled by the USB PHY and ultimately by the driver running on the Zynq. Make sure VBUS power control CPEN of the PHY is inactive.
The second concern is the amount of capacitance on the on VBUS. The Cora Z7 has a 150uF cap on VBUS (reference manual erroneously says the contrary) which is required for a host, but not allowed for a device. A device with big load capacitance can cause the current limit of the host to kick in during a hot-plug or power-cycle event. It is out-of-spec and functionality is not guaranteed.
-
$ git clone https://github.com/Digilent/Zybo-Z7-20-pcam-5c.git $ git checkout v2018.2-2 $ git submodule init $ git submodule update $ python digilent-vivado-scripts/git_vivado.py checkoutThis will re-create the Vivado project for the block design sources. Documentation for the scripts here: https://github.com/Digilent/digilent-vivado-scripts/blob/7b4d88aaa3c2c760167b2c563942f56e4a4cfce1/README.md.
-
This is a bug in Vivado which does not properly re-generate all the sources for the IP when it's re-customized. Resetting output products, clearing cache does not help. One possible workaround is to export bd to a tcl, delete the block design and source the tcl to re-create it from scratch.
However, I already gave another possible way of doing this: checking out the source files and using the Python digilent-vivado-scripts to re-create the project. This workflow seems to work, as opposed to using the generated project from release.
I created a commit to disable the debug module in future releases, as it makes more sense for the majority of our users. This will be picked up only in the next release cycle.
-
$ git worktree add ../Zybo-Z7-20-pcam-5c_2018_2 v2018.2-2 $ cd ../Zybo-Z7-20-pcam-5c_2018_2/ $ git submodule init $ git submodule update $ python digilent-vivado-scripts/git_vivado.py checkout Warning: Files and directories contained in C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj may be overwritten. Do you wish to continue? Y/N? Y Checking out project Zybo-Z7-20-pcam-5c_2018_2.xpr from repo Zybo-Z7-20-pcam-5c_2018_2 ****** Vivado v2018.2 (64-bit) **** SW Build 2258646 on Thu Jun 14 20:03:12 MDT 2018 **** IP Build 2256618 on Thu Jun 14 22:10:49 MDT 2018 ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved. Sourcing tcl script 'C:/Users/rogyorge/AppData/Roaming/Xilinx/Vivado/Vivado_init.tcl' INFO: [Common 17-1463] Init.tcl in C:/Users/rogyorge/AppData/Roaming/Xilinx/Vivado/init.tcl is not used. Vivado_init.tcl is already sourced. source C:/git/Zybo-Z7-20-pcam-5c_2018_2/digilent-vivado-scripts/digilent_vivado_checkout.tcl -notrace INFO: Creating new project "Zybo-Z7-20-pcam-5c_2018_2" in C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj create_project: Time (s): cpu = 00:00:02 ; elapsed = 00:00:05 . Memory (MB): peak = 350.289 ; gain = 119.281 INFO: Capturing board information from C:/git/Zybo-Z7-20-pcam-5c_2018_2/project_info.tcl INFO: Configuring project IP handling properties INFO: Setting IP repository paths INFO: Refreshing IP repositories INFO: [IP_Flow 19-234] Refreshing IP repositories INFO: [IP_Flow 19-1700] Loaded user IP repository 'c:/git/Zybo-Z7-20-pcam-5c_2018_2/repo'. INFO: [IP_Flow 19-2313] Loaded Vivado IP repository 'C:/Xilinx/Vivado/2018.2/data/ip'. update_ip_catalog: Time (s): cpu = 00:00:04 ; elapsed = 00:00:08 . Memory (MB): peak = 408.137 ; gain = 57.848 INFO: Adding HDL sources INFO: Adding XCI IP sources INFO: Adding constraints INFO: Rebuilding block design from script INFO: [BD_TCL-3] Currently there is no design <system> in project, so creating one... Wrote : <C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj/Zybo-Z7-20-pcam-5c_2018_2.srcs/sources_1/bd/system/system.bd> INFO: [BD_TCL-4] Making design <system> as current_bd_design. INFO: [BD_TCL-5] Currently the variable <design_name> is equal to "system". INFO: [BD_TCL-6] Checking if the following IPs exist in the project's IP catalog: digilentinc.com:user:AXI_BayerToRGB:1.0 digilentinc.com:user:AXI_GammaCorrection:1.0 digilentinc.com:ip:MIPI_CSI_2_RX:1.1 digilentinc.com:ip:MIPI_D_PHY_RX:1.3 xilinx.com:ip:axi_vdma:6.3 xilinx.com:ip:clk_wiz:6.0 xilinx.com:ip:processing_system7:5.5 digilentinc.com:ip:rgb2dvi:1.4 xilinx.com:ip:proc_sys_reset:5.0 xilinx.com:ip:v_axi4s_vid_out:4.0 xilinx.com:ip:v_tc:6.1 xilinx.com:ip:xlconcat:2.1 . INFO: [BD_TCL-6] Checking if the following modules exist in the project's sources: DVIClocking . INFO: [IP_Flow 19-234] Refreshing IP repositories INFO: [IP_Flow 19-1700] Loaded user IP repository 'c:/git/Zybo-Z7-20-pcam-5c_2018_2/repo'. create_bd_cell: Time (s): cpu = 00:00:05 ; elapsed = 00:00:06 . Memory (MB): peak = 639.629 ; gain = 153.918 CRITICAL WARNING: [PSU-1] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_0 has negative value -0.073 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-2] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_1 has negative value -0.034 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-3] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_2 has negative value -0.03 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-4] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_3 has negative value -0.082 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-1] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_0 has negative value -0.073 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-2] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_1 has negative value -0.034 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-3] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_2 has negative value -0.03 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-4] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_3 has negative value -0.082 . PS DDR interfaces might fail when entering negative DQS skew values. WARNING: [BD 41-1731] Type mismatch between connected pins: /DVIClocking_0/SerialClk(undef) and /rgb2dvi_0/SerialClk(clk) WARNING: [BD 41-1731] Type mismatch between connected pins: /DVIClocking_0/PixelClk(undef) and /rgb2dvi_0/PixelClk(clk) WARNING: [BD 41-1731] Type mismatch between connected pins: /DVIClocking_0/PixelClk(undef) and /rst_vid_clk_dyn/slowest_sync_clk(clk) WARNING: [BD 41-1731] Type mismatch between connected pins: /DVIClocking_0/PixelClk(undef) and /v_axi4s_vid_out_0/vid_io_out_clk(clk) WARNING: [BD 41-1731] Type mismatch between connected pins: /DVIClocking_0/PixelClk(undef) and /vtg/clk(clk) WARNING: [BD 41-1731] Type mismatch between connected pins: /DVIClocking_0/PixelClk5X(undef) and /video_dynclk/pxl_clk_5x(clk) WARNING: [BD 41-1731] Type mismatch between connected pins: /rgb2dvi_0/aRst_n(rst) and /v_axi4s_vid_out_0/locked(undef) Wrote : <C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj/Zybo-Z7-20-pcam-5c_2018_2.srcs/sources_1/bd/system/system.bd> WARNING: [Coretcl 2-176] No IPs found WARNING: [BD 41-721] Attempt to set value '50000000' on disabled parameter 'C_S_AXI_LITE_FREQ_HZ' of cell '/MIPI_D_PHY_RX_0' is ignored WARNING: [BD 41-721] Attempt to set value '200000000' on disabled parameter 'kRefClkFreqHz' of cell '/MIPI_D_PHY_RX_0' is ignored CRITICAL WARNING: [PSU-1] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_0 has negative value -0.073 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-2] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_1 has negative value -0.034 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-3] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_2 has negative value -0.03 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-4] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_3 has negative value -0.082 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-1] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_0 has negative value -0.073 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-2] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_1 has negative value -0.034 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-3] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_2 has negative value -0.03 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-4] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_3 has negative value -0.082 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-1] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_0 has negative value -0.073 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-2] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_1 has negative value -0.034 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-3] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_2 has negative value -0.03 . PS DDR interfaces might fail when entering negative DQS skew values. CRITICAL WARNING: [PSU-4] Parameter : PCW_UIPARAM_DDR_DQS_TO_CLK_DELAY_3 has negative value -0.082 . PS DDR interfaces might fail when entering negative DQS skew values. INFO: [digilentinc.com:ip:MIPI_CSI_2_RX:1.1-17] /MIPI_CSI_2_RX_0Verified that video_aclk frequency can handle RxByteClkHS frequency. AXI-Stream bandwidth 600000000 Pix/s >= PPI bandwidth 134400000.0 Pix/s INFO: [digilentinc.com:ip:MIPI_D_PHY_RX:1.3-17] /MIPI_D_PHY_RX_0FREQ_HZ of 50000000 propagated into CONFIG.C_S_AXI_LITE_FREQ_HZ INFO: [digilentinc.com:ip:MIPI_D_PHY_RX:1.3-17] /MIPI_D_PHY_RX_0FREQ_HZ of 200000000 propagated into CONFIG.kRefClkFreqHz INFO: [digilentinc.com:ip:MIPI_D_PHY_RX:1.3-17] /MIPI_D_PHY_RX_0FREQ_HZ of 84000000 propagated onto RxByteClkHS Wrote : <C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj/Zybo-Z7-20-pcam-5c_2018_2.srcs/sources_1/bd/system/system.bd> VHDL Output written to : C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj/Zybo-Z7-20-pcam-5c_2018_2.srcs/sources_1/bd/system/synth/system.vhd VHDL Output written to : C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj/Zybo-Z7-20-pcam-5c_2018_2.srcs/sources_1/bd/system/sim/system.vhd VHDL Output written to : C:/git/Zybo-Z7-20-pcam-5c_2018_2/proj/Zybo-Z7-20-pcam-5c_2018_2.srcs/sources_1/bd/system/hdl/system_wrapper.vhd make_wrapper: Time (s): cpu = 00:00:05 ; elapsed = 00:00:06 . Memory (MB): peak = 841.781 ; gain = 97.035 INFO: Configuring synth_1 run INFO: Setting current synthesis run INFO: Configuring impl_1 run INFO: Setting current implementation run INFO: Project created: Zybo-Z7-20-pcam-5c_2018_2 INFO: Exiting Vivado INFO: [Common 17-206] Exiting Vivado at Fri Nov 29 11:46:17 2019...
Opened in Vivado proj/*.xpr, unticked CSI-2 Debug module and Generated Bitstream successfully.
-
1. I think it is either a failed project upgrade or the submodule commit being out of sync with the main repo. This should not happen in the 2018.2 release, which is why I recommend you try it.
2. Of course, that was the whole point of your question.
Zedboard PROG J17 USB port damaged
in FPGA
Posted
You tore some SMD pads from the top layer, those cannot be repaired. However, the outward row of 4 pads are shield, so two will have to suffice. The inward smaller torn pads are floating (1 and 4) so they don't have to be connected to anything. The two smaller pads with solder on are the differential pair (2 and 3) and must be connected. Pad 5 is ground and must be connected too. Good luck!