engrpetero

OK - so I won't go that route (for now at least, heeding your comments). The Xilinx AXI QSPI seems like it should work. The IP seems pretty mature (I know that seeming mature is no guarantee). I'll keep plugging away with it. I can't even get the standard SPI working (much less the Quad SPI) to do anything useful. When debugging with Vitis, and monitoring with the Digital Discovery or even a voltmeter, I never even see the CS line go LOW. Hopefully, I stumble on a solution to it soon. Good and bad about the communications IP I've interacted with from Xilinx is that their examples almost always have a LOOPBACK mode. That's good because presumably that doesn't require any*other* hardware to demonstrate that something works. Bad because it ALSO doesn't require any*other* hardware to demonstrate that something works. I wish they included, perhaps with commented out lines, the things needed to make it work no in loopback mode. I figure SOMEONE has spent a good bit of time writing those drivers. They must have a very good feel for how they should work. A little more effort on their part would make it much easier for users as well. I've studied and stepped through the example code A LOT. But it also took an (unreasonably) long time to update the Xilinx drivers for the UARTs to use them the way I intended. The graphical display I've got (from Newhaven Displays) does have some example code (arduino (which I never use), FT90, and an MSVC app that includes an emulator). It is intended for SPI comm and so it does have a reduced but still more than functional enough set of features for the way I'll be using it.

I remain puzzled at why my AXI QSPI block doesn't seem to work. I appreciate the effort Xilinx put into developing the driver files for much of their IP blocks and in general, I understand and like the parallel structure they seem to use across them, but I think they've often made them unnecessarily complicated, and the documentation could certainly be improved. My debugging efforts have yet to actually see data transferred on the SPI bus. So I figured I'd take a step in a different direction and use one of the SPI blocks from the Zynq IP to see an actual working SPI implementation. If I enable SPI 0, for example, there are a few options for the pins that can be used. Looking at the Zybo-10 schematic, the MIO 16..21 (ENET 0), 28..33 (USB 0), and 40..45 (SD 0) pins are all connected directly to the mentioned peripherals, so they don't seem to be able to be used for my test purpose. That leaves EMIO as the only available option. But... I don't know how to route EMIO to output ports in the Vivado design. If this is even possible, does anyone have a doc or example they could point me to, please?

That sounds reasonable. I was playing with many different items still learning how best to use the DD. Thanks @attila.

With the DD still connected, I closed the Waveforms workspace and the voltage returned to 3.3V. I reopened the workspace and the voltage went back to 2.88V. I closed the Protocol and Logic panels that were in the workspace and reopened them. Voltage stayed at 3.3V. I saved the workspace, closed it, reopened it. Voltage stayed at 3.3V. It *seems* to be working now but now sure how it ever got in the 2.88V 'state' to begin with (or what might make it happen again).

yes. and I have a black wire from the DD pin to the right of pin 27 connected to pmod pin 5. I've tried it with Voltage Output (VIO) on and off both. Still ways 2.88V. When I turn on Voltage Output (VIO), I do see 3.3V on the DD red wires...

I never thanked you for the reply, @artvvb. Certainly appreciate it.

I'm still working on correctly interfacing the DD to the Zybo and using the AXI QSPI driver. Some unexpected behavior I'm hoping someone has an idea about. I am using pmod JD for the desired signals (so from the QSPI outputs being monitored from the DD, CS is on pmod pin 2, SCLK is on pin 8, MISO is on pin 9, MOSI is on pin 10). ##Pmod Header JD set_property -dict { PACKAGE_PIN T14 IOSTANDARD LVCMOS33 } [get_ports { DSPL_SPI_2 }]; #IO_L5P_T0_34 Sch=jd_p[1] set_property -dict { PACKAGE_PIN T15 IOSTANDARD LVCMOS33 } [get_ports { DSPL_CS[0] }]; #IO_L5N_T0_34 Sch=jd_n[1] // Chip Select for 420 char display set_property -dict { PACKAGE_PIN P14 IOSTANDARD LVCMOS33 } [get_ports { TS_INT }]; #IO_L6P_T0_34 Sch=jd_p[2] // Touch screen interrupt for graphical display set_property -dict { PACKAGE_PIN R14 IOSTANDARD LVCMOS33 } [get_ports { DSPL_GPIO_OUT[0] }]; #IO_L6N_T0_VREF_34 Sch=jd_n[2] // Reset for 4x20 char display set_property -dict { PACKAGE_PIN U14 IOSTANDARD LVCMOS33 } [get_ports { DSPL_SPI_3 }]; #IO_L11P_T1_SRCC_34 Sch=jd_p[3] set_property -dict { PACKAGE_PIN U15 IOSTANDARD LVCMOS33 } [get_ports { DSPL_SPI_CLK }]; #IO_L11N_T1_SRCC_34 Sch=jd_n[3] set_property -dict { PACKAGE_PIN V17 IOSTANDARD LVCMOS33 } [get_ports { DSPL_SPI_0_MISO }]; #IO_L21P_T3_DQS_34 Sch=jd_p[4] set_property -dict { PACKAGE_PIN V18 IOSTANDARD LVCMOS33 } [get_ports { DSPL_SPI_1_MOSI }]; #IO_L21N_T3_DQS_34 Sch=jd_n[4] From the DD, I have input 24 monitoring CS, 25 monitoring SCLK, 26 monitoring MOSI, 27 monitoring MISO. I'm also using a voltmeter and stepping through code using the VITIS debugger. First issue, when I do not have the DD connected, the pmod pin 2 (CS) is high (3.3V) as expected. When I connect the DD, pmod pin 2 measures 2.8V, not 3.3. This without the debugger even running. Any idea why this is happening (or something I've done wrong on the Protocol setup)? I figure until I see the CS pin low using a voltmeter, I don't need to bother with the DD for debugging.

Well, heck, I missed that. Works now. Thanks @attila. :-)

I have been using the Waveforms Protocol panel to successfully send SPI messages using the Digital DIscovery device. For now, I Execute two long sets of bytes (an example of the second set of bytes is shown in the pic below). In playing with the scripting, I'm trying to do the same thing but by sending many sets of three-byte-blocks instead of just that one long DQ0 line above. The simple script is shown below. FWIW, the content in DQ0 above is the second set of Write's in the script after the wait statement. Anyway, I don't get the same result when I execute/Run this simple script. Any assistance with the solution? clear() // clear the output window print ("Starting script..."); print("Lowering chip select."); Protocol.SPI.Start(); print("Peforming the init sequence from the NewHaven user manual."); Protocol.SPI.Write (8, 0xF8, 0x50, 0x40); // Function set (extended command set) Protocol.SPI.Write (8, 0xF8, 0x80, 0xE0); // Function selection A Protocol.SPI.Write (8, 0xFA, 0x00, 0x00); // Disable internal VDD regulator (2.8V I/O) <--3.3VIO Protocol.SPI.Write (8, 0xF8, 0x10, 0x40); // Function set (fundamental command set) Protocol.SPI.Write (8, 0xF8, 0xF0, 0x00); // Display on, cursor on, blink on Protocol.SPI.Write (8, 0xF8, 0x50, 0x40); // Function set (extended command set) Protocol.SPI.Write (8, 0xF8, 0x90, 0xE0); // OLED command set enabled Protocol.SPI.Write (8, 0xF8, 0xA0, 0xB0); // Set display clock divide ratio/oscillator frequency Protocol.SPI.Write (8, 0xF8, 0x00, 0xE0); // Set display clock divide ratio/oscillator frequency Protocol.SPI.Write (8, 0xF8, 0x10, 0xE0); // OLED command set disabled Protocol.SPI.Write (8, 0xF8, 0x90, 0x00); // Extended function set (4-lines) Protocol.SPI.Write (8, 0xF8, 0x60, 0x00); // COM SEG direction Protocol.SPI.Write (8, 0xF8, 0x40, 0xE0); // Function selection B Protocol.SPI.Write (8, 0xFA, 0x00, 0x00); // ROM CGRAM selection Protocol.SPI.Write (8, 0xF8, 0x50, 0x40); // Function set (extended command set) Protocol.SPI.Write (8, 0xF8, 0x90, 0xE0); // OLED command set enabled Protocol.SPI.Write (8, 0xF8, 0x50, 0xB0); // Set SEG pins hardware configuration Protocol.SPI.Write (8, 0xF8, 0x00, 0x80); // Set SEG pins hardware configuration Protocol.SPI.Write (8, 0xF8, 0x30, 0xB0); // Function selection C Protocol.SPI.Write (8, 0xF8, 0x00, 0x00); // Function selection C Protocol.SPI.Write (8, 0xF8, 0x80, 0x10); // Set contrast control Protocol.SPI.Write (8, 0xF8, 0xF0, 0xE0); // Set contrast control Protocol.SPI.Write (8, 0xF8, 0x90, 0xB0); // Set phase length Protocol.SPI.Write (8, 0xF8, 0x80, 0xF0); // Set phase length Protocol.SPI.Write (8, 0xF8, 0xD0, 0xB0); // Set VCOMH deselect level Protocol.SPI.Write (8, 0xF8, 0x00, 0x20); // Set VCOMH deselect level Protocol.SPI.Write (8, 0xF8, 0x10, 0xE0); // OLED command set disabled Protocol.SPI.Write (8, 0xF8, 0x10, 0x40); // Function set (fundamental command set) Protocol.SPI.Write (8, 0xF8, 0x80, 0x00); // Clear display Protocol.SPI.Write (8, 0xF8, 0x00, 0x10); // Set DDRAM address to 0x00 Protocol.SPI.Write (8, 0xF8, 0x30, 0x00); // Display ON print(" Init sequence Complete."); print("Delaying 100ms."); wait(0.10) // Wait 100ms print(" Delay complete."); print("Clearing display and setting cursor at top-left-most position."); Protocol.SPI.Write (8, 0xF8, 0x80, 0x00); //Clear display Protocol.SPI.Write (8, 0x40, 0x00); //Return home // write 10 chars to display print("Writing characters to display."); Protocol.SPI.Write (8, 0xF8, 0x80, 0x00); // Clear display Protocol.SPI.Write (8, 0xF8, 0x40, 0x00); // Return home Protocol.SPI.Write (8, 0xF8, 0x00, 0x50); // Set DDRAM address Protocol.SPI.Write (8, 0xFA, 0x00, 0x40); // Write character 0x20 Protocol.SPI.Write (8, 0xFA, 0x00, 0xA0); // Write character 0x50 Protocol.SPI.Write (8, 0xFA, 0x00, 0xA0); // Write character 0x50 Protocol.SPI.Write (8, 0xFA, 0xF0, 0x20); // Write character 0x4F Protocol.SPI.Write (8, 0xFA, 0x70, 0x20); // Write character 0x4E Protocol.SPI.Write (8, 0xFA, 0xF0, 0x20); // Write character 0x4F Protocol.SPI.Write (8, 0xFA, 0x60, 0xA0); // Write character 0x56 Protocol.SPI.Write (8, 0xFA, 0x80, 0x20); // Write character 0x41 Protocol.SPI.Write (8, 0xFA, 0x00, 0x40); // Write character 0x20 Protocol.SPI.Write (8, 0xFA, 0xC0, 0xA0); // Write character 0x53 Protocol.SPI.Write (8, 0xFA, 0xF0, 0x20); // Write character 0x4F Protocol.SPI.Write (8, 0xFA, 0x30, 0x20); // Write character 0x4C Protocol.SPI.Write (8, 0xFA, 0xA0, 0xA0); // Write character 0x55 Protocol.SPI.Write (8, 0xFA, 0x20, 0xA0); // Write character 0x54 Protocol.SPI.Write (8, 0xFA, 0x90, 0x20); // Write character 0x49 Protocol.SPI.Write (8, 0xFA, 0xF0, 0x20); // Write character 0x4F Protocol.SPI.Write (8, 0xFA, 0x70, 0x20); // Write character 0x4E Protocol.SPI.Write (8, 0xFA, 0xC0, 0xA0); // Write character 0x53 Protocol.SPI.Write (8, 0xFA, 0x00, 0x40); // Write character 0x20 Protocol.SPI.Write (8, 0xFA, 0x00, 0x40); // Write character 0x20 print("Completed writing characters to display."); print("Raising chip select."); Protocol.SPI.Stop(); print ("Finished!");

Thanks, @JColvin. Much appreciated. I've got a follow-up question but I'll ask in a new thread to keep things separate.

OK. And presumably the script executed with no errors then as well? Did I just miss this in the documentation?

Excellent. Making good progress now. Thanks again for the help, @attila.

Wow - that is super helpful. Thanks Attila! If I close the Logic Analyzer panel and then click the Protocol panel 'Debug with Logic Analyzer' button, that button turns green, the text changes to 'Debug with Logic Analyzer. No Data Reception!'. And a Logic Analyzer window opens showing the expected Master SPI bus. When I click 'Execute', the SPI transfer shows in the Logic Analyzer. For kicks, is there a way to also show the Slave interface in that logic analyzer (since if have the pins 24 connected to 28, 25 to 29, etc.)?

I'm still learning how to use this Digital Discovery device. Slow progress. Using the Logic Analyzer panel, I've setup the device to do an SPI test where pins DIO 24-27 represent a Master and pins DIO28-31 represent a slave. I've physically connected pins 24 to 28 (chip select active low), 25 to 29 (sclk), 26 to 31 (MOSI), and 27 to 30 (MISO). To see something working, I then used the Pattern Generator panel and setup a bus on pins 24-27 to perform an auto-repeat Binary Counter at a frequency of 500KHz. I click 'Run' on the Logic Analyzer, then I click 'Single' on the Logic analyzer. I get the following (which seems to indicate things are working and the appropriate pins are connected together (sorry the picture is small but there was a lot on the screen). Since the pattern generator seemed to provide expected results, I clicked 'Stop' on the pattern generator. I then used the Protocol panel to attempt to send 4 bytes over the SPI interface. I click 'Single' on the Logic Analyzer and the Logic Analyzer indicates 'Armed'. I then click 'Execute' in the Protocol panel, the Protocol panel shows the bytes written, shows 0x00 for the bytes read, and the Logic Analyzer just shows 'Busy' (see next screenshot). I looked in the help at the states for the Logic Analyzer and 'Busy' isn't mentioned. I never see any transitions in the Logic Analyzer and I've waited up to several minutes to see if the 'Busy' indicator ever changes. It doesn't. I can click 'Single' or 'Run' and the Busy indicator goes away. But I never see any waveforms appear. I figure I'm close to getting the result I expect but must be doing something stupid and though probably obvious, escapes me. Any assistance, please?

Thank you, @attila for the reply. A few follow-up questions. While in the 'Script' window, I do see results when displaying the Output window and I use print statements. That is cleared up so thanks. While in the 'Protocol' window - the one that has the Evaluate Script button - the text next to the button always says 'undefined'. No pointer to a line or anything, just 'undefined'. Searching the help, I don't find an entry that helps me move past the undefined item (or what it even means). Also, since in the protocol window - with the protocol being SPI - I don't *think* I need to prefix the methods/function calls with the object content (so in the Protocol window, I can use Write() instead of Protocol.SPI.Write()). Is that true? Can I use the entire object hierarchy (Protocol.SPI.Write()) if I want to? (Note int he picture showing the Protocol editor, I don't prefix Start nor Write with Protocol.SPI.).

Darn... I forgot also ask in previous post so just doing in second post. At the bottom of the scripting window, there is a button to 'Evaluate Script'. What should happen when this button is pressed? All I ever see in the box to the right of the button is the text 'undefined'...

I've been playing a bit with the Digital Discovery Waverforms application scripting to help speed development of some SPI peripherals. Although I find the scripting documentation mostly helpful, some things puzzle me (for example, where would one see 'true' or 'false'? even when I step through a script using the debugger, I don't see return values). And from a script perspective, I *think* the script 'honors' the pin descriptions identified in the 'Settings' portion of the Waveforms app. So with this small script shown below... SPI Chip select is on pin DIO24 and is active low SPI clk is on DIO25 (even though the 'Settings' control indicates a frequency of 1MHz, the script sets the frequency to 100KHz) MOSI is on DIO27 MISO is on DIO26 Then the script starting at line 7 merely starts the SPI function (pulling DIO24 low), then writes 8 bytes (lines 9-11), then waits 100ms, then writes 3 more bytes, then stops (pulling DIO24 high). Is anything I've said about the script not accurate?

Ahh, yes, I have a few tools and those are the default ones I go to while trying to acquire new tools. I am in a hurry but am also fortunate for now - I have lots of other things going on so this design can be iterative and improved on. Being a mostly PS side person delving more and more into the PL side (because I find it very interesting), I am not sure how to efficiently (OK, 'maybe efficiently) get from the PS to the PL *except* by using an AXI peripheral. I do love to read and have no problem doing research. You have any pointer links I could wade through that show other ways to accomplish PS/PL interactions besides AXI?

Sorry for the late reply - I hadn't noticed your post, @Viktor Nikolov yesterday. I spent yesterday learning exactly what you posted. 😀 I spent a lot of time with the global timer and the triple timer counters (TTC) to get something 'debuggable' in Vitis only to arrive at the same conclusion that the included drivers are simply waiting in a do loop which isn't a lot better than a for loop (the do loop looking at the timer counter value would at least let you do accurate timing without the need to do trial and error on a for loop max iteration value). Edited to add this line... I could use a TTC with an interrupt to avoid the do loop. That's how I use the scutimer right now for other tasks anyway. So using a timer does provide a solution. Now I'm reconsidering @zygot's last post. I totally agree with zygot's post about the using the PS and PL based on their respective strengths (and ease of implementation). The PS code for this project is pretty complicated so keeping the PL functionality easy to use and 'complete' on its own is something I've been striving for. And to get the display functional (if not optimized), I was looking for the PS solution to time delays so I could just use the Xilinx provided AXI QSPI out-of-the-box for sending messages. But now that I've had some time to think about it, I'm not sure of a reasonable way to use the AXI QSPI for communication while also including delays on the PL side since they would seemingly need to be after the AXI QSPI block. I'm still thinking about this though.

Using Vivado 2022.2, I created a new very simple project based on the ZyboZ7-10 (see pic 1 below). The only changes I made to the 'as-placed' IP were with the Zynq7 processing system in which I enabled UART0, TTC0, and TTC1 (see pic 2 below). I ran synthesis, implementation, generate bitstream, export hardware. In a new Vitis workspace, I created a new platform project based on the exported hardware. I then created a new application project using the 'Hello World' template based on the platform project. The options for the 'sleep_timer' are shown in pic 3 below. I built the platform project and app project with no errors. I updated the BSP settings to add the xiltimer item but left the 'sleep_timer' value as 'none'. The platform project and app project build with no errors. I updated the BSP settings to set the 'sleep_timer' value to 'ps7_globaltimer_0'. The platform project and app project build with no errors. I updated the BSP settings to set the 'sleep_timer' value to 'ps7_ttc_0'. The platform project builds with no errors. When building the app project, the platform project shows with the same error I posted yesterday (undefined reference to XTime_StartTTCTimer). I updated the BSP settings to set the 'sleep_timer' value to 'ps7_ttc_1'. The platform project builds with no errors. When building the app project, the platform project shows with the same error I posted yesterday (undefined reference to XTime_StartTTCTimer). I returned the BSP settings 'sleep_timer' value to 'ps7_globaltimer_0'. The platform project and app project build with no errors. Frustrating. Any ideas? Google hasn't been my friend searching for a solution to this problem. I'm going to post on the Xilinx fora but I'm not expecting much there (you guys are more helpful here and again, anyone who answers questions, thank you very much)

Crazy tool. I'll give that a shot and even just create a dirt-simple, plain project with a zynq and the items that represent the AXI GPIO for the Zybo-10. No other content to see what happens with the sleep stuff.

More odd info (at least odd to me). I didn't review all the search results earlier. The XTime_StartTTCTimer() function is defined. It's in xil_sleeptimer.h/c (see screenshot below). But it's almost as if the function is 'ifdef' dependent as it's greyed out in Vitis. However, at the top of the xil_sleeptimer.c file, I find #if defined (SLEEP_TIMER_BASEADDR) and SLEEP_TIMER_BASEADDR is clearely defined in xparameters.h...

Thanks, @artvvb. It does look like the functions contained in this header file will be just what I need. If only I could get the undefined reference problem solved... I'm still looking into it.

Thanks @Viktor Nikolov for the additional reply. Indeed, I do see exactly what you showed in your pictures. I should have looked more closely. The UI does have the bug when you are setting the 'values' but the 'standalone' level does show exactly what you posted. The xparameters.h file also looks exactly like what you posted regarding the XSLEEP_TTC_INSTAANCE and SLEEP_TIMER_xxx lines. Weirdly, even though I can build the hardware project with no issues, when I attempt to build the application project, I still get the following error in the HARDWARE project... C:\PXilinx20222\VitisWorkspaces\VW-E20\etest\ps7_cortexa9_0\standalone_domain\bsp\ps7_cortexa9_0\libsrc\standalone_v8_0\src/xil-crt0.S:97: undefined reference to `XTime_StartTTCTimer' collect2.exe: error: ld returned 1 exit status make[1]: *** [makefile:56: Edc20.elf] Error 1 make: *** [makefile:47: all] Error 2 I'm curious @Viktor Nikolov (and thank you for the time you've devoted already to helping me) if after you build the hardware project, you built any application project based on the hardware project and saw different results from me. I searched the entire workspace (both hardware project and app project) for 'XTIME_StartTTCTimer' and it only shows in two places in this xil-crt0.S file. The file header does mention... When I look at the hardware project files under xiltimer_v1_1, particularly the xiltimer.h file (though I looked at all the non-O files), there is no mention of an XTIME_StartTTCTimer method. Searching XTIME_StartTTCTimer on the web didn't result in any useful leads.

Actually, it seems that even though I select ps7_ttc_0 in this dropdown and then click 'OK', the value isn't saved. If I return to this screen immediately after clicking 'OK', the value is always set back to 'none'...