• Content Count

  • Joined

  • Last visited

About mjdbishop

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Digilent Thank you for the reply. I had not appreciated, from the documentation, that the GPIO pins were bi-directional with unified direction/OE control. However, I have been driving the GPIO OEs with 0's, consequently the data pattern presented should have been output. So, what you have intimated leaves me where I started - drive the AC0..7 bits appropriately e.g. 110001zz [0..7] and the outputs don't obey. Hence the original question, how do I trace the (output) signals, which on the components involved will come down to probing resistor pads and suchlike. The test setup is USB cable for control and power, and 3v3 strapped to Vref. All sitting on the bench. Further information and diagnostic suggestions would be most welcome Best Regards Martin
  2. Hi Jon Many thanks - cable now working Many Thanks Martin
  3. Hi Digilent Read and digested the forgoing. But, can't get the GPIO012 pins to wiggle on an SMT2. Whether my understanding is correct and how to diagnose the issue are the questions. JTAG on AD0..3, JTAG OEs on AD5..7 work fine and the software stack does lots of solid JTAG through the user friendly D2XX dll. Current requirement is to use the three GPIO lines for "USB" resets, e.g. GPIO2 => PS_Rst_n for Xilinx tools. Understand that the mapping from AD0..7 to the GPIO pins is Gpio0/Gpio1/OE0_n/OE1_n/OE2_n/Gpio2/X/X. Test results. SMT2 module on the bench powered from a bench supply, 3v3 @ 60mA. No discernable output from the GPIO pins however I poke it; e.g. 110001zz which should output 111, or 000000zz which should output 000. An FT232H module wiggles its AC0..7 pins as directed. The high byte wiggling is commanded by MPSSE 82x commands Ordinarily the schematics would be consulted for places to probe and the FT2232H outputs probed. That is inhibited by the compound effect of the abscence of schematics / layout and the 2232s QFN package - basically I need to know where to trace the signals. Or, perhaps it's user error ... Both further information and diagnostic suggestions would be most welcome Best Regards Martin
  4. Hi Digilent I also have bricked an HS2 cable, with FTPROG - I shall spare you the excuse Assistance apreciated VMTiA Martin
  5. mjdbishop

    ZYBO lwIP Implementation

    I have Lwip running OK on bare metal using SDK 2016.3. With SDK 2016.2 and 2014.4 LwIp would only run meaningfully if the cache was disabled see https://forums.xilinx.com/t5/Welcome-Join/Zybo-lwip-echo-server-failed/m-p/735344#M41600 Another issue is the WARNING message emitted by the Xilinx adapter regarding the RealTek PHY see https://forums.xilinx.com/t5/Welcome-Join/LWIP-PHY-initialisation-sequence-Warning/m-p/732708 It would be a good thing if Digilent / RealTek / Xilinx did the necessary V&V to address both the message and any potential issue I have not suceeded in getting iperf to work with the Xapp1026 code. Possibly finger trouble, also I note that the pdf was upissued on 21st inst. For me not a priority - although knowledge of success with SDK 2016.3 and iperf3 might stiffen my fingertips. Also, I have been unable to find any documentation of iperf messages / internals, beyond the code. However, ping telnet UDP Tx & Rx (at 6 Mby/s of RTP stream) all work and I have observed (on wiresharc) useful (44 Mby/s) quantities of TCP hurled at iperf by a Zybo, but no progress reports from iperf. In summary LWIP probably works to a first order, except for Xapp1026 & iperf. Assistance in resolving the WARNING issues in particular would be appreciated Martin