Erickson

Members
  • Content Count

    13
  • Joined

  • Last visited

About Erickson

  • Rank
    Member

Recent Profile Visitors

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

  1. I have a new design coming along that will need to use I/O pins on the (normally not populated) J1 connector. I don't have easy access to a CORA at the moment, so am looking for X and Y offsets from J1 to the J4/J5 connectors. Also, are there part numbers or height measurements available for the normally populated headers to help in selecting a part with appropriate dimensions to install in the J1 position? Thanks!
  2. Thanks for the input. I suppose the VHDL or Verilog approach would require a little more design-entry work overall on my part, but would make the block diagram a little bit cleaner and easier to follow. For this project, I don't think it makes sense to go down that path, but in the future if I need to add some VHDL/Verilog-defined modules anyway, then I'd want to do this.
  3. I'm working with a CORA Z7 board and developing a system that will use make on and off-chip connections for the GPIO interface via the EMIO. A conceptual block diagram of what I am trying to put together is shown below: I will have a 16-bit wide constant IP block in PL that holds version information to be read-only as seen by the PS, along with a 2-bit wide pair of lines from the push buttons, and finally a 6-bit wide group of outputs to drive the LEDs. My (working, now) solution involves a concat and a slice block in addition to the constant and processor subsystem blocks: Does this seem like an overly-complicated approach, or is this the only way to avoid Vivado throwing errors because the 18-bit wide input and 6-bit wide output don't match the 24-bit wide GPIO_I and GPIO_O ports respectively?
  4. Hi @jpeyron, This is exactly what I needed. Thanks!
  5. Hi Jon, Thanks for the reply. We've already taken caliper measurements here. I'm looking for a DXF file to hand off to a PCB designer to help with placing board-to-board connectors for a custom hat/shield. Is it correct that the outer headers are the same as an Arduino Uno? I think I could track down an Arduino DXF without too much difficulty. Thanks again!
  6. Are there DXF or other mechanical CAD files available for the CORA Z7 board?
  7. I ran some experiments to figure out how much delay is needed. It's somewhere in between 0 and the amount of time added as a result of FSBL_DEBUG_INFO being defined in fsbl_debug.h. I'm a bit of a novice with C, and didn't realize that if I defined FSBL_DEBUG_INFO in fsbl.h, that it would be ignored by the compiler. Had I enabled it correctly to begin with, I probably would have never noticed the sensitivity to delay and would have had a painful time in a few months when we go to do customer demos and I (hypothetically) un-define the FSBL_DEBUG_INFO flag. On a related note, I found that the BOOT.bin file @jpeyron kindly provided had been built with the FSBL.elf, HW.bit, and APPLICATION.elf files. The resulting BOOT.bin file was a little over 2-MB, while the BOOT.bin file resulting from just an FSBL.elf and APPLICATION.elf is about 120-kB without FSBL_DEBUG_INFO and about 135-kB with FSBL_DEBUG_INFO included. Based on my hardware setup where the BOOT.bin has to be transferred to the micro SD card by way of the UART interface on the Zynq (IT still won't let me put an SD card into a company computer), the factor of 16 difference in file size made for a meaningful difference in the time I had to wait for Tera Term to push the file to the Zynq. Needless to say, for my delay-length experiments, I cut down the cycle time considerably by leaving out the HW.bit file.
  8. Hi @jpeyron, Before I saw your reply, I went ahead and added a for loop to the start of the FSBL main function, and re-generated my programming files. Now, from the time I reset the board until the done bit LED comes on is several seconds. I was pleased to see that my helloworld program now executes correctly. It appears I stumbled upon an additional issue that may have been confusing things for a while. When I power cycle the CORA board, Tera Term seems to disconnect from the COM port, even though it continues to read "COM4:115200baud - Tera Term VT" at the top of the window. Do you know if there is a setting in Tera Term to keep a hold on the port and keep listening even if the device at the other end disappeared? EDIT: This seems to be more of a Windows issue than a terminal program issue. When the CORA board power cycles, the COM4 device disappears momentarily from Windows device manager. Tera Term allows this to happen silently. Putty, on the other hand, throws a warning. The sequence of steps I'm needing to take in order to see the helloworld output looks like: Power cycle CORA board File -> Disconnect in Tera Term File -> New Connection in Tera Term Select COM4 and press OK Press the SRST button on the CORA board Wait for my for-loop to finish looping Then the helloworld output appears on the terminal I'm going to go have lunch, but I'll do some experimenting this afternoon to see how much delay I actually need in order for the system to work, and whether it matters if it's at the start of the FSBL or the start of my application. Thanks for the suggestion to add delay.
  9. Hi @jpeyron, Both SD cards that I tried were formatted to FAT32. Unfortunately, I can't provide a screen shot of the contents. I can't connect an SD card into a work computer system, due to an IT policy that I mentioned in my original post. I've checked both cards on a non-work system and verified that BOOT.bin was the only file, and that the file size matched what had been generated by the Xilinx tools. With respect to adding a delay, would that be at the start of the main function in the FSBL? Thank you for the help.
  10. Good morning @jpeyron, Thank you for the follow-up. I'm seeing the exact same result with your project as I did with mine. I've put together a more detailed description of my setup and the steps I've been following: PC running SDK and Tera Term <------ USB/UART ------> CORA <------ SDIO -------> micro SD card Launch SDK Power CORA board Connect Tera Term to COM4 @ 115200baud Launch SDIO_write_file application (modified from xilffs_polled_example in xilffs_v3_6 library) from the SDK When prompted in Tera Term, send BOOT.bin file Power down CORA board Set jumper on JP2 to select SD boot Power CORA board The output I am seeing on Tera Term is as follows. It is all generated by the SDIO write application. There is no indication of output from either the FSBL or the user application. <font=courier> Write File Test Entering FfsSdPolledExample() Filling SourceAddress[] buffer. Send file to be written: 2204424 bytes received Attempting to mount the device Attempting to make a filesystem Entered f_mkfs() Volume read from path: 0 Attempting to open file Attempting to seek to start of file Attempting to write data to file Attempting to seek to start of file Attempting to read data from file Checking file contents for match Attempting to close the file Successfully ran SD Polled File System Example Test </font> I tried a different micro SD card without any luck. I've already installed the Digilent board files, and have been using those for all of the projects I've started in Vivado.
  11. After some more digging, I'm still not there, but have an update that may help narrow down what's happening. The Xilinx AR# 59476 suggests: Please provide the status of INIT_B (high or low or blinking), REBOOT_STATUS and BOOT_MODE registers after the boot failure. REBOOT_STATUS is reading a value of 0x0040_0000 after POR, and reads 0x0060_0000 after I press the SRST button. The BOOT_MODE register reads 0x0000_0000 following a POR with the JP2 jumper removed. After a POR with JP2 installed, BOOT_MODE reads 0x0000_0005. These match my expectations based on studying the UG585 Zynq 7000 TRM. Looking at the schematic, I see INIT_B is tied to a resistor rather than an LED as assumed by the Xilinx troubleshooting checklist. I suppose that means I will have to find a magnifying glass and oscilloscope in order to find out what it is doing. UPDATE: INIT_B is sitting happy at 3.3-V.
  12. Hi Jon, It appears I do not have a successful boot from the SD card, even for just a UART helloworld. When I go through Run As -> Run Configurations from the SDK, the applications work as I expect. I'm trying to run on a CORA Z7 10 version with the XC7Z010-1CLG400, developing with Vivado and SDK 17.2. Looking at the Zedboard programming guide, I noticed a difference between what it describes in Appendix A and what I had been doing. It calls out including the HW.bit file in addition to the FSBL.elf and APPLICATION.elf files. Because my application only uses the Processor Subsystem (employing the UART and SDIO peripherals), I assumed the HW.bit file did not need to be included in the BOOT.bin file. I'm still not very confident whether that is needed or not, given the nature of my application and intended HW configuration. Do you know if this is a meaningful difference? I tried creating a new BOOT.bin incorporating the HW.bit file from the Vivado project. That made the .bin file a lot bigger, but behaved the same when I attempted to boot from the SD card. Something else I noticed is that my original BOOT.bin file was only about 120-kB. That seemed small, given that the FSBL.elf and APPLICATION.elf files were 310-kB and 162-kB respectively. I'm not confident that this is the root of my problem, but seems a little suspicious. Step 3 of the Xilinx Programming/Booting troubleshooting checklist suggested: Please provide the status of INIT_B (high or low or blinking), REBOOT_STATUS and BOOT_MODE registers after the boot failure. I'm trying to figure out how to read those. Are they something I would access through the XSCT console in the SDK?
  13. I am trying to boot a standalone application from a micro SD card on the CORA Z7 board. I'm working with a rather unconventional setup. Due to IT policy at work, the only micro SD card interface I have available is the one on the CORA board. Yesterday, I modified the example program that comes with the xilffs_v3_6 library to write and read back from an SD card. Then, I generated a BOOT.BIN file via Xilinx SDK -> Create Boot Image, using an auto-generated FSBL application and an auto-generated helloworld application. I wrote the BOOT.BIN to the SD card, but the CORA board did not seem to work with this configuration. I found Xilinx AR# 59476 with some troubleshooting tips. I've copied their steps (in italics) and provided answers covering what I've checked. 1) Please provide the board schematics and the name of the SD Memory Card used. Schematic from Digilent The micro SD card is an 8GB MMCTR08G3ACH-NJ (originally bundled with a Raspberry Pi). 2) Is Zynq Production Silicon? The Zynq is an XC7Z010, with ID code 13722093. Based on Xilinx AR# 37579, I interpret the first digit as the version code. Based on Table 1 in Errata Notification EN247, I think this means I am working with production silicon. 3) In which phase of booting is Zynq is failing? BootROM or FSBL? As far as I can tell, the device is not reaching the FSBL. I'm not seeing any output via the UART when I try to boot in SD card mode. When I configure via JTAG, my helloworld program happily sends characters back to my computer, so I am confident that the terminal is set up correctly. This is as far through the troubleshooting check list as I've reached so far. I'm going to investigate some of the following items in the Xilinx checklist, but am feeling kind of stuck being unable to read out any debug information from the FSBL.