Can you skip the zynq and reliably do some simple counting in the fpga? The processor subsystem is hideously complex and opaque in my opinion. I'm pretty sure there is a way to do pure gate logic on the part.
Yep, I just need a clock to use. That's why I was trying to use the PS clock. I'll try a different clock to do some basic FPGA testing this coming week.
In line 89 you call "print" instead of "printf". I don't know what "print" is or where it's defined, but it's definitely not a part of standard C library. Seems like it's awful lot of includes for such simple program. Remove as much of them as possible. Some of them may be calling some static initializers and enable something that you don't expect to be enabled. I have no idea if that slow clock could be an issue. There might be some watchdog running, somewhere. Does FPGA portion of the chip work?
I think "print" was used in the sample app. I do plan to start another project that is simplified. I imagine many of those includes are to support the sample app's peripheral testing and are not needed for my simpler test. I was hoping to pull a clock from the Zynq PS to test the FPGA portion, but I haven't gotten there yet. I'll try a simpler FPGA test in the coming week.
1. Use the correct clock generator - nothing is going to work with incorrect one. 2. Check your bootstrap pins configuration. 3. Configure one of UARTs. What do you think is supposed to happen when you do a "print"? You will likely need to assemble USB-JTAG section for that, or USB-UART (I don't remember how did you wire it up). You can choose which of UARTs will be used for "print" in BSP configuration. 4. Most Zynq project templates assume you have DDR configured and so they attempt the run the code off DDR. I think you will need to use "Zynq FSBL" template which is meant to run off OCM RAM - but don't quote me on that as I don't have much experience with Zynq (I mostly work with "pure" FPGAs).
1. Later this week -- just need the right part. :) 2. Will do. 3. Yep, I haven't done that yet, but it's on my list. As you mentioned, I'll need to populate those components. For now, the print calls simply show up in the XSCT console, which is convenient. 4. Great to know! I saw a DDR test project. I'll try to get my DDR configured and see how it tests out. Phil from Phil's Lab has a video on DDR config/testing, so I'll check that out, too. Thanks, @asmi06!
@rehsd I think you can configure uart to use pretty much any mio pin, so if you have any not used for peripheral, set up uart to output to it, and hook up oscilloscope or external usb-uart. Just be mindful that some mio use 1.8v level and so don't connect 3.3 v usb-uart to it!
It's 3:07 AM. Good time to watch rehsd's video.
Can you skip the zynq and reliably do some simple counting in the fpga? The processor subsystem is hideously complex and opaque in my opinion. I'm pretty sure there is a way to do pure gate logic on the part.
Yep, I just need a clock to use. That's why I was trying to use the PS clock. I'll try a different clock to do some basic FPGA testing this coming week.
In line 89 you call "print" instead of "printf". I don't know what "print" is or where it's defined, but it's definitely not a part of standard C library.
Seems like it's awful lot of includes for such simple program. Remove as much of them as possible. Some of them may be calling some static initializers and enable something that you don't expect to be enabled.
I have no idea if that slow clock could be an issue.
There might be some watchdog running, somewhere.
Does FPGA portion of the chip work?
I think "print" was used in the sample app. I do plan to start another project that is simplified. I imagine many of those includes are to support the sample app's peripheral testing and are not needed for my simpler test. I was hoping to pull a clock from the Zynq PS to test the FPGA portion, but I haven't gotten there yet. I'll try a simpler FPGA test in the coming week.
1. Use the correct clock generator - nothing is going to work with incorrect one.
2. Check your bootstrap pins configuration.
3. Configure one of UARTs. What do you think is supposed to happen when you do a "print"? You will likely need to assemble USB-JTAG section for that, or USB-UART (I don't remember how did you wire it up). You can choose which of UARTs will be used for "print" in BSP configuration.
4. Most Zynq project templates assume you have DDR configured and so they attempt the run the code off DDR. I think you will need to use "Zynq FSBL" template which is meant to run off OCM RAM - but don't quote me on that as I don't have much experience with Zynq (I mostly work with "pure" FPGAs).
1. Later this week -- just need the right part. :)
2. Will do.
3. Yep, I haven't done that yet, but it's on my list. As you mentioned, I'll need to populate those components. For now, the print calls simply show up in the XSCT console, which is convenient.
4. Great to know! I saw a DDR test project. I'll try to get my DDR configured and see how it tests out. Phil from Phil's Lab has a video on DDR config/testing, so I'll check that out, too.
Thanks, @asmi06!
@rehsd I think you can configure uart to use pretty much any mio pin, so if you have any not used for peripheral, set up uart to output to it, and hook up oscilloscope or external usb-uart. Just be mindful that some mio use 1.8v level and so don't connect 3.3 v usb-uart to it!