baywil

Since the JP2 jumper only disconnects the FTDI output from C18, it has no effect on the hard-wired reset button. That button, will still be connected to C18 as well as the RST pin in the shield. If FPGA internal logic is able to force C18 low, it would effect the RST pin in the shield and reset the Ethernet board. C18 is connected to "reset" in the block diagram properties but, I'm unsure how to access it from Vitis.

I have an Arduino Ethernet shield board attached to an Arty S7-50. The Ethernet board goes stupid after running for awhile and refuses commands - has to be power reset and I would like ArtyS7 to handle it. The Spartan S7 has a reset input on pin C18 (CK_RST) that connects to the power button on the Arty S7. The Arty S7 manual shows that pin C18 is also driven by the FTDI FT2232 USB-UART bridge via JP2. According to the Arty S7 manual, the RST pin on the shield connector J8 (which I would like to bounce) is "Connected to the red "RESET" button and a Digital I/O of the FPGA. When JP2 is shorted, it is also connected to the DTR signal of the FTDI USB-UART bridge." 1. Maybe I could reset the Ethernet board by bouncing the DTR signal on the FTDI bridge? I'm not sure how to directly access the FTDI. The manual says "The red reset button labeled “RESET” generates a high output when at rest and a low output when pressed. The RESET button is intended to be used in Microblaze designs to reset the processor, but you can also use it as a general purpose push button." 2. If the reset button could also be used for general purposes, there must be some way to disconnect it from RESET. How would I program this button for general purposes? (I don't have it defined in Vivado) Maybe C18 could be tied to a GPIO pin (via the Vivaldo block diagram) to pull it low to cause a reset. I realize that if this did work, it would reset the ArtyS7 as well as the Ethernet board. 3. Has anyone ever done anything like this to C18 CK_RST? An idea I saw mentioned for the Ethernet board was to disconnect its RST pin from the connector (J8 counterpart) and wire it to one of the digital GPIO lines in the shield connector. 4. This could allow ArtyS7 to control the Ethernet board reset via GPIO. Has anyone ever done this? Any thoughts would be appreciated! Thanks!

Thank you, Arthur! Your analyzer image made me realize I was sampling at 20Khz (visible in one of the earlier images) while I had set the SPI out clock to 50Mhz/16. I was able to set the data width of the SPI IP to 32 bits and sample the data at 8Mhz. I added the XSP_CLK_ACTIVE_LOW_OPTION flag (I completely missed this) and set Saleae accordingly and it worked. A couple things I am unclear on: 1. In the capture below, the bytes are sent out in reverse order they are stored in buffer. I had to reverse buffer to get DEADBEEF in the last image. It looks like XSpi_Transfer() does a XSpi_WriteReg() to XSP_DTR_OFFSET in buffer's native order. I guess this means DTR sends the data to FIFO MSB? 2. In the last image, I captured a DE8DBEEF - obviously some bits fell out? This could be my analyzer or not using interrupts? Just curious. Thanks again for all your help! Bill

"device" is an instance of XSpi - I just didn't include the declaration. Your example worked out of the box with a few exceptions. I've included modified versions for both 4 and 1 byte XSpi_Transfer(). 1. MOSI data out didn't match what was in buffer[4] and every run provided completely different MOSI data.This caused me to second guessed my constraints file so, I tested two different port assignments: set_property -dict { PACKAGE_PIN H16 IOSTANDARD LVCMOS33 } [get_ports { spi_ss_io }]; #IO_L22P_T3_A17_15 Sch=ck_io10_ss set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { spi_io0_o }]; #IO_L22N_T3_A16_15 Sch=ck_io11_mosi set_property -dict { PACKAGE_PIN K14 IOSTANDARD LVCMOS33 } [get_ports { spi_io0_i }]; #IO_L23P_T3_FOE_B_15 Sch=ck_io12_miso set_property -dict { PACKAGE_PIN G16 IOSTANDARD LVCMOS33 } [get_ports { spi_sck_io }]; #IO_L14P_T2_SRCC_15 Sch=ck_io13_sck and set_property -dict { PACKAGE_PIN H16 IOSTANDARD LVCMOS33 } [get_ports { spi_ss_io }]; #IO_L22P_T3_A17_15 Sch=ck_io10_ss set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { spi_io0_io }]; #IO_L22N_T3_A16_15 Sch=ck_io11_mosi set_property -dict { PACKAGE_PIN K14 IOSTANDARD LVCMOS33 } [get_ports { spi_io1_io }]; #IO_L23P_T3_FOE_B_15 Sch=ck_io12_miso set_property -dict { PACKAGE_PIN G16 IOSTANDARD LVCMOS33 } [get_ports { spi_sck_io }]; #IO_L14P_T2_SRCC_15 Sch=ck_io13_sck These changes had no impact as you'll see in the attached images. 2. It appears that at least 300 bytes have to be written via XSpi_Transfer() before any MOSI data is observed. I tried the entire buffer[4] 75 times as well as buffer[0] (0xDE) 300 times - any less than those attempts yields no MOSI output. I am open to the possibility that this is a PulseView/Saleae analyzer issue as well not displaying the correct SPI decoder data except that the MOSI data is on the D4 line of the analyzer. Do you have a device connected to your MOSI output (I don't)? Does your MOSI data match what is in buffer[4]?

I simplified the TX loop to send just one byte hundreds of times and printed out the registers with SPI enabled and disabled. The Transmit FIFO Occupancy register increases when SPI System Enable is disabled, otherwise it does not but, no MOSI data observed. I hope this sheds more light...

Thanks, Arthur! I've attached screenshots of what I describe below. In Vivado, I changed the QSPI ext_spi_clk (ext_spi_clk.png) to 50Mhz via a new clk output on the clock wizard (clk_wiz.png). I set the QSPI frequency ratio to 16:1 as you suggested (qspi_cfg.png). In Vitis, I tried inhibiting the master while populating the TX FIFO then enabling the master (loop_code.png). No MOSI output but the TX occupancy logging showed that the TX bytes were added (output.png). They just never get sent out. Alternately, if I just hammer the TX with data while master is enabled, **EVENTUALLY** I see some MOSI data out but, it's not what was written to DTR (0us_delay.png). (filenames are not posted but images appear in the order I listed)

Pardon the hairball of info here but, I've been banging my head for 2 weeks now so maybe I can't see the forest for the trees...my problem is that I can't see MOSI data on the 6-pin J7 connector (Arduino/chipKIT Shield connector). I have a Rev E. board and added a Quad-SPI IP in Vivado 2023. The QSPI s_axi_aclk and ext_spi_clk lines are connected to clk_out1 of the Clocking Wizzard at 100Mhz (via auto-connect). The QSPI's Frequency Ratio is set to 4:1 so, I think that means the QSPI is running at 25Mhz? I read the IP has a limit of 50Mhz. I obtained Arty-S7-50-Master.xdc from Digilent's GitHub repo and in Vivado added it to Constraints in the block design. The only mods I made to it was to uncomment and modify the following: set_property -dict { PACKAGE_PIN H16 IOSTANDARD LVCMOS33 } [get_ports { spi_ss_io }]; #IO_L22P_T3_A17_15 Sch=ck_io10_ss set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { spi_io0_io }]; #IO_L22N_T3_A16_15 Sch=ck_io11_mosi set_property -dict { PACKAGE_PIN K14 IOSTANDARD LVCMOS33 } [get_ports { spi_io1_io }]; #IO_L23P_T3_FOE_B_15 Sch=ck_io12_miso set_property -dict { PACKAGE_PIN G16 IOSTANDARD LVCMOS33 } [get_ports { spi_sck_io }]; #IO_L14P_T2_SRCC_15 Sch=ck_io13_sck I generated a test_bench.vhd for the block design using Xilinx TCL Store Design Utilities https://support.xilinx.com/s/article/64983?language=en_US . I was able to modify the generated testbench and toggle the QSPI's spi_io0_o (MOSI ) via the test bench in simulation, viewing it in PulseView using Saleae Logic analyzer. So, I thought I was good. I created a Vivado-maintained HDL wrapper, generated a bitstream, and exported the wrapper. In Vitis I imported the hardware wrapper and tried both xspi_low_level_example.c and xspi_intr_example.c from Xilinx/Vitis/2023.1/data/embeddedsw/XilinxProcessorIPLib/drivers/spi_v4_10/examples. Both used loopback so, I removed that flag before running them. Both perform a XSpi_SelfTest() which was successful. When I run the examples, I can watch the SPI control and status registers update so, I know I'm talking to the hardware. The closest I came to seeing MOSI data was (in desperation) creating a loop to write hundreds of bytes to the TX data register and I was finally able to see MOSI data in the analyzer although it wasn't the same bytes written to TX so, a problem for sure. This was the short version of my failures. I can attach pictures of settings and provide further details upon request. I'm hoping that a SPI guru out there can push me in the right direction as I believe I've missed something basic.