• Content Count

  • Joined

  • Last visited

  • Days Won


About [email protected]

  • Rank

Recent Profile Visitors

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

  1. I am using Vivado 2017.4 and using the download.bit image (and .elf file with offset) with the "Program Flash Memory" function in SDK. This follows your MicroBlaze tutorial and has been working well using the same CmodA7 module. I've bought several of these and when I connected a different one there have been a few issues. Using Windows 7 64 bit, the first time a new module is plugged in, it has to install it as a new device. This makes Device Mangler assign a new Com port number to it. Sometimes Windows thinks it's some kind of electronic pen and I've had to delete the driver and let it install again. This is being done automatically by Windows. So, the first question is whether there is a better way to install these? I guess there's no way around having Windows recognize each one of these as different devices? Next, if I have Vivado and SDK up and running and try to program the flash it fails and errors because it can't find the device to program. I went into Vivado and used the Hardware Manager to find new hardware. It did this okay but then going back to SDK and trying to program the flash it fails to find the device. So I closed SDK and reopened it and tried this again but this doesn't work either. Closing SDK and Vivado and then reopening then both, SDK now recognizes and programs the new device successfully. I've had to close both and then reopen them for each device. The above was done with devices that I had already managed to install once before. A completely new device seems to require setting the flash device type again in the programming utility but SDK seems to remembers that the next time that device is plugged in. I have a few more CmodA7 modules on order for some further prototyping and am wondering if there is a more streamlined way to work with these?
  2. The CmodA7-35T uses a N25Q032 flash. This provides sufficient room for the bit file and a little less than half of it for something else like an elf load. If two bit loads were desired such as for a multi boot reconfiguration with a golden load and a field installed load there would not be sufficient room to do this. Perhaps compressing the bit files might be a way to still make that work. I was looking at this line of flash devices and noticed that there is a general trend toward the lower sizes becoming less available or obsolete and the cost for larger sizes aren't much more than the smaller ones now. In particular the 032 and 064 seem to be going away. With that, is there any plan to use larger size flash devices for this product in the future?
  3. That offset might be better off being 0x00220000. I don't know whether Xilinx utilizes the sub sector erase but using this offset would be safe if it only uses sector erase.
  4. This is just follow up: I found that if you disconnect with the terminal program before plugging the USB cable back in and then reconnect right after plugging in the USB cable, all of the messages get presented. This way it seems to be ready before the FPGA DONE LED is presented. Considering the actual amount of the room in the flash that is required for the 35T FPGA load, an offset of 0x00218000 can be used to maximize the flash space that will still available for program code. This is 48% of the N25Q032 flash whereas the offset of 0x00300000 only leaves 25%. Again, I did not compress my image. I did program this new offset into blconfig.h and used it in the elf program flash step just to test it out and insure that it still worked.
  5. Success, finally, although there are several things to note. It would appear that upon plugging the USB into the PC, the terminal program was not catching the communications. I was using HyperTerminal and found that it would miss the initial message but upon doing a disconnect-reconnect, it would then see receive data that was delayed from the CmodA7. In this latest build I added in blinking LEDs and several delayed messages to the C code so that I could see activity both ways. I also tried this with TerraTerm but it acted the same way. I added BTN0 as a reset. This allowed starting the program over without the USB disconnect-reconnect. On pressing BTN0 reset, all of the print messages appeared on the terminal. Of course the LEDs always blink to tell me that the thing is working whether I see info on the terminal or not. I'll attach the code and the BD image. This version has the 50MHz ext_spi_clk. Whether that made a difference I can't say. I know the hardware is working with this and flash programming is obviously working too. Now when I plug the USB in the DONE LED takes several seconds to come on. On previous try's it came on immediately. That's probably telling but I don't know what was different before to cause that. Two other things: This time I used xil_printf() instead of print. I believe the amount of code generated is less this way. Also, I did not compress the image. The MicroBlaze has 32k of local memory and 16k Cache as you directed earlier. I'm not sure what thing(s) made this work now but obviously there are a number questions still lingering. The problem is that it takes a long time to try this and then try that with proper scientific method and I've already spent way too long just getting to this point. I really need to move on and get some other things going here. At least I have a good starting point now to do that. Thanks for all of your help with this Jon! helloworld.c
  6. Yes, It still runs under SDK debug run with the correct message showing up on the terminal. I'll start over with a new project and include the 50MHz ext_spi_clk and see what happens. This will be about the 6th time I've started this new.
  7. Tried the "50MHz clk", same thing. Do I need to shut down the tools? I see a lot of communications with the module com led but nothing on the terminal. Also strange, the done led is on immediately at USB plug in.
  8. I'm building the "50MHz clk" into the design right now but just one more thing for today... Was I supposed to flash the hardware bitstream in Vivado before the two program events in SDK? I assumed that the boot loader was combined with the hardware in the download.bit.
  9. Hyperterm. Since it seems to work in SDK debug I would imagine that is not the issue. It says "The contents are read back and check if the region erased is blank" which is most ambiguous but if that works for you than it must be only a partial erase. I'll not worry about this one any more. I'm using the "getting started with microblaze tutorial " and adding the spi IP. I'll add in the 50MHz clk that you mentioned and try that. I had it tied to the AXI clk at 100MHz. BTW, I'm using the n25q32-3.3v-spi-x1_x2_x4 for the flash type and giving the type a 5 as it says. BD screen shot attached and also I've attached the SDK log during my programming of the flash. BTW, I sure do appreciate you staying with me on this! SDK.log
  10. That's what I was doing, pulling the USB cable out and plunging it back in. Just checking, I was thinking that perhaps the USB-UART device or the PC driver might have not been up and running in time to catch the "hello world" on the terminal. Yes, section 4. I'm using those offsets, 0x00300000 for the hello world elf and 0x0 for the boot loader bit files. How is it that the whole flash is not erased each time? Is there a setting to control this that I might have missed? Each time it tells me that it did a blank check. And just to be sure, download.bit is at: Proj_Name/Proj_Name.sdk/Proj_Name_wrapper_HW_Platform_0/download.bit, is that correct?
  11. It's still not working and I'm really trying to follow this to the letter. I appreciate you hanging in there with me on this. I went back and recreated the hardware insuring that it had the local memory set to 32k and the cache at 16k. Previously I had it set to local memory set to 64k and the cache at 8k. I'm am using FLASH_IMAGE_BASEADDR as 0x00300000. I cleared out the code in SDK and started that over. When I run it in the SDK debugger it runs and presents on the terminal so the code must be working but this worked for me earlier too. 1. How are you resetting the CmodA7? I'm pulling the USB then reinserting. 2. How is it that we program twice and the second time doesn't erase what was programmed on the first program step? (It indicates erase and blank check.) Thanks, Dean
  12. Never mind about the part where I said "...Program FPGA step with the bootloader ... I got "Blink World"..." Apparently I had managed to get code into the flash at some point and this was executing when I did the Program FPGA step at 3.1. There's something wrong with the Program Flash function in 2016.3. I recreated the project in 2017.2 and the Program Flash function works there. After programming the flash in 2017.2 as in sections 4.1 and 4.2 I tried unplugging the CmodA7 then plugging it back in again to reset it but nothing comes up on the terminal. In SDK run debug this works. This brings up the flash erase operation. It appears to erase the entire flash. If this is so then the elf file that I programmed first would no longer be there after the second program flash step where I programmed in the bootloader. But the tutorial said that this works. What am I missing?
  13. Hi Jon, I created (using 2013.3) a simple new project today to try this out again. It's the "hello_world" project from the "Cmod A7 - Getting Started with Microblaze" tutorial. To this I added the quad spi IP from the board tab to this project BD. Everything in this tutorial runs fine. Using this project as a starting point I followed everything in the "store in flash" tutorial very closely. Unfortunately, my result is always the same that I cannot program the flash on the CmodA7. I get the following response: >Connected to hw_server @ TCP: >Available targets and devices: >Target 0 : jsn-Cmod A7 - 35T-210328A4172FA > Device 0: jsn-Cmod A7 - 35T-210328A4172FA-0362d093-0 >Retrieving Flash info... >ERROR: Flash Operation Failed I did notice one thing that seemed odd in that when I ran the Program FPGA step with the bootloader just before the Program Flash, I got "Blink World" on the terminal. Perhaps that's just what it does. I've tried doing this several times before and always get stuck at the program flash part. At this point I'm lost as to what to do next or what I'm doing wrong. I've included the image of the programming step below. Any help you can provide on this would be greatly appreciated! Thanks. Dean
  14. Thank you. I'm trying this with 2016.3 so hopefully it's close enough. In the tutorial at 1.3 it states "If you are using the Cmod-A7 and you did not compressed your bitstream try the offset: 0x00300000." I'm trying this out on a Cmod-A7. What is a reasonable address if you did compress it? (Maybe I'm missing something obvious here?)
  15. What version of Vivado was used to create the tutorial "How To Store Your SDK Project in SPI Flash"?