engrpetero

I'm trying to access the buttons 4 and 5 and the LED 4 on the Zybo-10 PS. I searched these fora and found one seemingly relevant post but it has to do with petalinux and I'm just doing baremetal. I also downloaded the polled and interrupt examples (which I usually find really useful) but alas, not so for accessing these buttons and LED. One snip from the XGPIOPS polled example includes these two items (Input_Pin and Output_Pin). I can't figure out what they reference though (I assume some exposed pin on the GPIO MIO though I don't find pins 10 or 14 on the Zynq block (second pic)). I also included a snip from the schematic but still can't make sense out of the 10 and 14 in the code snip (maybe the MIO pins?). Any chance there is a pointer to access these two buttons and LED somewhere? FWIW, I have done the PMOD example project on the website when I was learning and found it very useful.

Thanks, Arthur. Adding the files to the File Groups as you suggested fixed the issue and allowed the instantiation and at least got by the initial errors with synthesis (I had already added them to the Sources but that hadn't fixed the problem). There are other errors - but I can move on to tackling those. Your help much appreciated.

So I continue to make progress with my current project. I've created several Verilog modules and test benches for them and am happy with the results. I've got an Axi-Lite peripheral and can write and read to its memory addresses as expected. Next step is to instantiate some of the mentioned verilog modules in the Axi-Lite peripheral to complete a portion of the design. I have copied the verilog modules with the mentioned designs into the src file of my created IP. My top level project has a block design with an instance of the mentioned Axi-Lite peripheral. So I highlight it, then click the 'Edit in IP Packager' menu item to access that design and begin the edits to instantiate content from the modules. I then add as a Design Source one of the files (ExtConverter) with a design in intend to instantiate in the Axi-Lite peripheral. I do instantiate one instance of ExtConverter in the peripheral. My design sources window looks like the picture below. I don't know what the red question mark icons indicate (but it doesn't seem good). I repackage the IP to return to my top level project and after I upgrade the IP, I 'Generate Output Products' and then attempt to synthesize again. Unfortunately, I am met with Vivado errors (see second pic). So my two questions... 1) what do the red question mark icons mean, and 2) why am I getting these errors?

Hi Arthur, Yes, indeed it does help, if for nothing else than to confirm what I'm seeing. I do see that extra RECV_DATA interrupt on start. I did not think to setup the ReceiveBuffer before enabling the interrupt. A good suggestion I will try. I resigned myself to ignoring that first event since it was absolutely repeatable. I temporarily side-tracked this part of the project to work on a simple AXI-Lite peripheral. Let me ponder your points and play with it some more. I'll certainly report back on what I see and learn. I did want to let you know I saw your post and greatly appreciate it. Peter

It seems the examples for the UartLite (implemented in PL, obviously) are virtually identical to the PS Uarts. So there is a way around the issue I'm facing. When I figure it out - and I will figure it out! :-) - I'll post back here with a fully working example for others to use.

Thanks, @zygot. Yes, I've found the learning curve to be quite steep - I'm somewhere in the middle of the climb still. I do feel like I've read 2000 pages of Xilinx documentation over the last 6 weeks or so. :-) I am using the PL side of the device (or I'd just be using a ucontroller, of course!) for some relatively simple functionality. That remains a work in progress. I am becoming more comfortable with the HDL design flow. And Axi peripherals. I'll continue reading, studying the examples, and hope for the best. Fortunately, outputting data on either of the PS Uarts always works exactly as I want so some debugging is a breeze.

Even though the XUartPS interrupt example shows a line similar to the XUartPs_SetHandler() one shown above, the function prototype seems to suggest the line should be... // Setup a handler for Uart raised 'events' XUartPs_SetHandler(ptrUart, (XUartPs_Handler)UartISR, (void *)ptrUart); This of course wouldn't affect the UartISR() from being called, just an the ptrUart reference inside that ISR.

I'd just about give my left arm at this point for a working example of using the Xilinx XUartPs stuff with interrupts in a non-loopback, continuously receive data example. I desire to process every character one at a time as it is received. I normally send characters over a serial port connected to the Zybo with a simple C# app but for test purposes, TeraTerm works fine for sending characters. I'm using Vivado and Vitis 2022.2 and a ZyboZ7-10. I have a very simple project based on the XUartPs interrupt example (which of course just uses the loopback mode and a fixed set of send/receive chars). I've attached the c file to this post (no header file needed) which I think could be executed by anyone with a ZyboZ7-10 with no additional work. The program initializes the Gic, then initializes the Xuart, then initializes the GPIO (LED) of the Zybo so I could see in a run (not Debug) environment if the hander for the Uart 'event' is ever called (the LED just turns on and off when the Uart event occurs). The Vitis debug environment isn't consistent. Sometimes the Uart handler is entered, sometimes not - which is why I stuck the LED on/off change in there). Since the debug environment isn't consistent, it's awfully difficult to step through the code to see what exactly is going on with the XUartPs software. And the XUartPS documentation, like most Xilinx documentation, is pretty sparse. At most, it seems the UartISR handler is entered four times - this ought to be a clue but I've haven't discovered what it means yet. I've included the InitUart function below. Note the Fifo threshold is set to 1 in the InitUart function (which I guess means the Uart 'event' handler UartISR) would be entered with every received character. It is (very) unclear to me based on the comments in the Xilinx XuartPs software what the function XUartPs_Recv() is supposed to do. To quote the xuartps.c file in which the function is provided... * In interrupt mode, this function will start the receiving, if not the entire * buffer has been received, the interrupt handler will continue receiving data * until the entire buffer has been received. A callback function, as specified * by the application, will be called to indicate the completion of the * receiving or error conditions. For interrupt mode, it *seems* I need to call the XUartPs_Recv() function only once (that's why I did it at the end of the InitUart function) and the hander UartISR() would then be called whenever a single new character is received. That character would be available in the 'RecvBuffer' that was provided in the XUartPs_Recv() function call. I know it's asking a lot but would greatly appreciate some help on this. It's critical to my Zybo use that I can faithfully receive and process characters. The Zybo is a *huge* (and much desired) upgrade over my previous use of AVR controllers for similar applications but no so much if I can't get this working. int InitUart(XUartPs *ptrUart, u16 UartDeviceId, u16 UartInterruptId) { int Status; u32 IntrMask; XUartPs_Config *ptrConfig; // Look-up the Uart config ptrConfig = XUartPs_LookupConfig(UartDeviceId); if (ptrConfig == NULL) {return XST_FAILURE;} // Initialize Uart Status = XUartPs_CfgInitialize(ptrUart, ptrConfig, ptrConfig->BaseAddress); if (Status != XST_SUCCESS) {return XST_FAILURE;} // Self-test Uart Status = XUartPs_SelfTest(ptrUart); if (Status != XST_SUCCESS) {return XST_FAILURE;} // Setup Uart specific items XUartPs_SetBaudRate(ptrUart, 115200); IntrMask = XUARTPS_IXR_RXFULL | XUARTPS_IXR_RXEMPTY | XUARTPS_IXR_RXOVR; XUartPs_SetInterruptMask(ptrUart, IntrMask); XUartPs_SetOperMode(ptrUart, XUARTPS_OPER_MODE_NORMAL); XUartPs_SetFifoThreshold(ptrUart, 1); // Add Uart to Gic system (remember to always use XUartPs_InterruptHandler) Status = XScuGic_Connect(ptrGic, UartInterruptId, (Xil_ExceptionHandler)XUartPs_InterruptHandler, (void *)ptrUart); if (Status != XST_SUCCESS) {return Status;} // Setup a handler for Uart raised 'events' XUartPs_SetHandler(ptrUart, (XUartPs_Handler)UartISR, ptrUart); // Enable Uart interrupts with the Gic XScuGic_Enable(ptrGic, UartInterruptId); // Enable the Uart XUartPs_EnableUart(ptrUart); // In interrupt mode, start receiving so receive events can occur? XUartPs_Recv(ptrUart, RecvBuffer, TEST_BUFFER_SIZE); return XST_SUCCESS; } UartTest.c

ugh. The cable for the MIO UART was bad. Comm over both PS Uarts seems to be working now and I can continue debugging.

Thanks for the comments, @zygot. Just another frustrating thing. I have checked the BSP and support libraries and I agree with your observation that the hardware and BSP UART identifiers look backwards. But at this point, all I care is that they are different. Also, I'm not sure how Vivado/Vitis 'assigns' the base addresses (0xE0000000 or 0XE0001000) for the UARTs - I didn't see anything in the Zynq IP block in Vivado so I'm just assuming the base addresses are correct. I keep two serial ports open on my laptop test app and just print a message anytime data is received on either port. In Vitis, I simply change the DeviceID and then confirm while debugging on the hardware the expected base address is used. All messages sent for the hardware though, regardless of the peripheral base address always show on only one of the laptop serial ports. I'll continue looking and perhaps post on the Xilinx forums.

As I mentioned in another thread, I've added a second PS UART to a design on MIO pins 14-15. The platform project has been updated and I'm back in Vitis. By screwing around with the Xparameters.h, Xprint.c and Xprint.h files, I was able to send strings from Zybo_Z7 to PC over both UARTs, that is the USB UART and the Uart on MIO pins 14-15. I did restore the 3 mentioned files to their original content. I decided I was wasting some time and really needed to use the already defined methods in the xuartps.h/c files. And to get started, I downloaded the example projects the bsp pointed to (particularly the simple xuartps_hello_world_example). It seems to make sense. So I changed the define to what seemed should obviously send over UART0 (the one connected to MIO 14-15). No luck - data is always transmitted over the USB Uart. I even ran in Debug mode from Vitis, saw the expected 'base address', but still my laptop always receives data over the USB Uart, regardless which line I've uncommented below. Any idea as to what stupid thing I'm doing wrong?

@artvvb- thanks for this additional information. I didn't mean to wait so long to respond but I continue to play with Vitis and review content in some files associated with this folder structure and got distracted from responding. The comment about editing the 'BSP libsrc folders' files directly is much appreciated. I wish there was a way (perhaps there is) to be able to edit one of the files in one of the libsrc folders and 'apply' those changes to that similar file in the other BSP folders. Seems unfortunate to have to edit them all to include the same functionality. I'll continue working on this - I've gotten distracted with just using the second PS UART (normally not enabled) and routing that through the MIO pins to the JF connector to do further work on the Vitis app before getting back to... implementing another UART with a UartLite IP block in the PL running the second PS UART through the PL to allow connection on other Zybo connectors/pins

This subject is near and dear to my Zybo learning exercise lately so I thought I'd add an additional comment. The Zynq PS block does have an unused UART (mentioned by @zygot with the mentioned FIFO limitations) that can be connected to MIO pins exposed on the Zybo JF connector (bypassing the PL, if desired). Of course, to use xil_printf for both UART0 and UART1, some Vitis code changes are needed (seemingly straightforward since the xil_printf functions are easy to duplicate).

Thanks, @zygot. I should have gone to the ref manual. Much appreciated. Edit to add a picture from the ref manual...

I searched the forum for Zybo and constraints file and did not find an similar post. Hopefully, I didn't miss one. I'm using the ZyzoZ7-10. The device has physical connectors for the PMOD ports JA, JC, JD, JE, JF. The master constraints file from Digilent has JA, JB (with useful note JB is only available on the ZyboZ7-20), JC, JD, JE but no JF. Why isn't there a section for JF? I looked at the schematic and it *seems* the JF connector could be somewhat easily added (based on looking at JE on the schematic and the constraints file) to the constraints file as the pin identifiers are shown. with something like... ##Pmod Header JF #set_property -dict { PACKAGE_PIN E8 IOSTANDARD LVCMOS33 } [get_ports { jf[0] }]; #PS_MIOI2_500 Sch=jf1 #set_property -dict { PACKAGE_PIN E9 IOSTANDARD LVCMOS33 } [get_ports { jf[1] }]; #PS_MIOI2_500 Sch=jf2 #set_property -dict { PACKAGE_PIN C6 IOSTANDARD LVCMOS33 } [get_ports { jf[2] }]; #PS_MIOI2_500 Sch=jf3 #set_property -dict { PACKAGE_PIN D9 IOSTANDARD LVCMOS33 } [get_ports { jf[3] }]; #PS_MIOI2_500 Sch=jf4 #set_property -dict { PACKAGE_PIN E6 IOSTANDARD LVCMOS33 } [get_ports { jf[4] }]; #PS_MIOI2_500 Sch=jf7 #set_property -dict { PACKAGE_PIN B5 IOSTANDARD LVCMOS33 } [get_ports { jf[5] }]; #PS_MIOI2_500 Sch=jf8 #set_property -dict { PACKAGE_PIN C5 IOSTANDARD LVCMOS33 } [get_ports { jf[6] }]; #PS_MIOI2_500 Sch=jf9 #set_property -dict { PACKAGE_PIN C8 IOSTANDARD LVCMOS33 } [get_ports { jf[7] }]; #PS_MIOI2_500 Sch=jf10

The Xilinx documentation can be overwhelming! :-) I'll keep looking around and learning. And will continue to work on getting this second Uart (first instance of UartLite) working with the ZYbo in the manner mentioned in the rest of this thread and post an update when I'm successful. For those who responded @JColvin, @Tim S., thanks again. I know it takes time and effort to respond to these posts and it's much appreciated.

Some progress - intermediate post and question (and maybe better posted on a Xilinx forum). I almost gave up looking for xuartlite.h in the folder structure. Turns out I'm an idiot and was searching in the Vivado project folder structure instead of the Vitis project folder structure. So it is there. And I can add an include for it in my main.c file to continue playing. On to my intermediate question... Is there a reference somewhere that more clearly defines the folder structure for the Vitis wrapper project and the Vitis app project? Maybe it isn't important to know all the details since it seems much of this is auto-generated but I can't help but believe the more I understand here, the more this will make sense and the fewer questions I'll have in the future (and the more I can help others). I do desire to use a similar method to xil_printf with this uartlite instance as the target. Now to continue brushing up on my C skills (been writing C# code too long).

@Tim S. - thanks for the additional posts. I have the afternoon available to work on this project so I'll dig into your example shortly but also consider your last item - specifically looking for that header file in the directory structure. For my example project, the UartLite is indeed a second Uart instance (the first being the Uart that uses the USB port on the Zybo Z7 - I'm leaving that intact for a separate purpose). So the project will be receiving/transmitting over both Uart instances.

Thanks for the additional reply @Tim S.. I should have noted that I added the UartLite to a baremetal project I was already working on and for which I had a functional Vitis program. I left out this detail because I didn't think it important - I should have mentioned that though - my mistake. So to recap... I had a simple Digilent baremetal example project (the PMOD example from the website) working in Vivado and Vitis. In Vivado, I added some HW features to the example project, re-synthesised, re-implemented, regenerated bit stream, exported XSA file. In Vitis I updated the hardware spec, added some additional C code, got the expected results from the HW features I added in 2. In Vivado, I added the UartLite IP to the Vivado project that started this thread, resynthesised, reimplemented, regenerated bit stream, exported XSA file. In Vitis I updated the hardware spec. Now I've also Reset the BPS Sources (did not Modify BSP Settings, just reset the sources) for the 'zynq_fsbl' and 'standalone_ps7...' domains in Vitis. From my online searches, I was expecting (maybe I shouldn't be) to find a uartlite header file appropriate methods would be exposed. However, I don't see one and searching all files in the Vitis project for the word 'lite' returns no results - which makes me think I've done something wrong.

I edited this post at 10:54 to include a better picture... Funny you should ask... The first two times yesterday I generated the bitstream, I did indeed forget to export the XSA file. But I did finally remember (and then to 'Update Hardware Specification' again). The BSP Headers/Sources regeneration though... I did not do that. Haven't played with that 'section' of Vitis in a year or two so unfortunately, I've forgotten about it. Was the suggestion to 'Reset BSP Sources' (which I just did and which the console seems to indicate happened) or am I totally in the wrong section? The UartLite item seems to show up correctly in the BSP shown in the picture but I don't see the header file I was expecting.

I should have added one more question. I sort-of expected that once I ran synthesis, implementation, and generate bitstream to update the hardware wrapper, then when I opened my development project in Vitis and 'Update Hardware Specification', I would have been able to find some reference to the 'xuartlite' header file. I did some googling to learn how to use the xuartlite and search results seemed to indicate I'd be interacting with methods identified in that header file. No such header file was found though after the hardware spec update. Should I have expected to find such a reference in the Vitis project?

Wow - either I've misunderstood, or the process is pretty easy (or perhaps neither or both! :-)). I believe I followed the @JColvin post (and @Kvass comment) about adding the AXI UartLite IP, making the rx and tx pins external, and then editing the constraints file to put the signals represented the newly external pins on one of the PMOD headers. See the pics below. I haven't been able to test yet as I need do put some wiring together (my plan is to simply connect these two pins to a serial port on my pc) but two questions... Can I choose any two unused pins on any PMOD header (I've obviously chosen the first two pins on JA in the pictures below)? Any other obvious issues based on the simple pictures provided?

Thanks, KVass and JColvin. I'll take a look at the link. Much appreciated!

Any chance someone could point me to an example of creating a UART (or UART Lite) using pins exposed by one of the PMOD ports? I'm using a ZyboZ7-10 platform.

I've been making reasonable (good, even) progress with the Vitis IDE and the ZyboZ7. A question though about clocks on this board and their interface to the Zybo. I've been using the xscutimer module in interrupt mode. However, I'm struggling to figure out appropriate values for the TIME_LOAD_VALUE. If I set it to a pretty high number (hex FFFF FFFF) (dec 4,294,967,295), I see events happen at about 0.8s. If I set it to 9FFF FFFF (dec 2,684,354,559), I see an event about every 0.5s (they scaled pretty linearly). Since I believe the timer is just counting this many clock cycles, it seems the clock is way too high - somewhere around 5.3E9 (or I'm not sure how to set this value). I've looked at the Zybo reference docs and seem some references to clocks (667Mhz). I will look further at the Arm9 cortex reference to gain some insight. But if anyone can help me out, much appreciated. Peter