All Activity

This stream auto-updates   

  1. Today
  2. hey, I ordered the papilio duo through the kickstarter long ago... and never really used it because i was waiting for an update of the ebook... recently found it again while moving.. so wanted to see if there was any update.. Yet i can't seem to find any updates about the ebook ...?
  3. Synchronous resets are not an issue. Reseting the clock generator is General rule is: - If you have a single clock on your system, make sure the reset signal is deasserted at least one clock cycle after your clocking is stable. Do not deassert it if you use a DCM/PLL until it locks. Do not reset DCM/PLL unless you absolutely need to. - For multiple clocks its a bit more tricky. You will need a reset for each of your clock domains. Here async reset for the reset itself may prove useful - assert resets asynchronously, but deassert them synchronously for each of your clock domains. May not be enough, though. Alvie
  4. OK, so I figured this out... silly amateur mistake on my part. For the record, the problem was caused by using synchronous resets and also connecting the reset signal to the coregen'd clock core. This of course caused the clock core to stop and therefore parts of the design weren't getting the reset (synchronous reset won't reset without running clock). Interestingly the slower clock circuits were getting reset while the faster ones weren't. Anyway, lesson learned.
  5. Hey All, I've got a problem with a design I'm working on for Papilio Duo as follows: Programming SPI flash works fine and starts up correctly on every power on. After power on if I program the FPGA directly there's some randomness in whether it starts correctly. Usually it fails. Basically the Z80 code executes in a way that can "never happen". Either the T80 core isn't getting reset correctly or there's some issues with ram/rom. It looks like a CALL instruction is simply skipped. After programing to FPGA, using the reset button on the classic computing shield resets correctly - everytime. So... I'm wondering if there's something different about the reset procedure after programming directly to FPGA vs programming to SPI Flash using the reset button. I'm sure this is an issue in my design, but not really sure what to look for - any hints greatly appreciated. Brad
  6. Hello adamada, You should check all of your configuration settings. The easiest way to do that is to open the *.xise file and compare it to an xise file that is successfully generating a bit file that loads to spi flash. You have probably accidentally set the configuration to a quad spi chip or something... Jack.
  7. Yesterday
  8. Last week
  9. FYI: This is the FTDI board to rule them all: "-H" means high speed version, the MPSSE will clock up to 30 MHz and this works reliably with JTAG+Xilinx. You can get it from many vendors.The same exists for quad-channel FT4232H BTW, but I prefer the remaining pins as GPIO. It has proper protection circuitry on the USB port, which most other boards are lacking. I am using those in volume for industrial automation BTW.
  10. No, the ft232R does not have an MPSSE unit, which is what the Papilio loader is using for JTAG. Magnus
  11. Well this looks like the right thread to ask my question, rather than open a new one. Hopefully people will notice the new posting! I have been given a Spartan 3 based tiny PCB. It has a large SRAM, Flash ROM, 32 pin general purpose header, and a few switches and LEDs. It also has a 14 way header (smaller than 0.1") which I am told is for a standard Xilinx programmer. Well I don't have a Xilinx programmer, although I do have a cheap Chinese Altera programmer. So I wondered if I could use the programming circuitry on my Papilio One/Pro (I believe they are the same). The Papilio programmer appears to be based around the FTDI2232, a dual channel USB to UART. I am guessing that it is not used in serial "RS232" mode, but the JTAG pins are toggled high and low. Given that I cannot isolate the JTAG pins (TCK, TMS, TDI and TDO), the answer must be no. Interestingly there does appear a row of empty vias for soldering in a header for an external programmer, but I can't tap off from this as there would be contention on the TDO connection. Now I have a Sparkfun FDTI breakout board, but when I found it, it uses the single channel FDTI232R chip and not the dual channel chip. I have access to all pins. The question is, will this work with the Papilio Loader? Well I tried it out. Using simple COMMs software it works correctly as COM5 if I connect TX and RX. When I start the Papilio Loader, I get no messages to confirm that any programmer has been seen, nevertheless I loaded a random bit file and hit the "Run" button. For a few seconds the TX/RX (still linked together) light up, and then go out. The "Run" button is still greyed out. So is the Papilio Loader really using this single channel chip as a programmer? If there are multiple FDTI chips plugged into the USB, including a Papilio, how does the software figure out which to use? Note: I am using Papilio Loader 2.6. I think the latest version is 2.8, which I ought to try out. --Gary
  12. Here some additional information: I wanted to see if I could use DesignLab to upload bit files generated in ISE. So I went into the Libraries directory and created a library called custom. I imitated the directory structure of the other libraries, so my bit file was at "C:\DesignLab-1.0.8\libraries\custom\circuit\DUO_LX9\papilio_duo_lx9.bit". Then I loaded a blank sketch template and changed the line #define circuit blank to #define circuit custom and pressed upload. The console indicated it was uploading the proper file to SPI, but then once everything was done, nothing worked as it was supposed to (the same symptom when using Papilio Loader to SPI and not directly to FPGA). So this is really weird. Writing to persistent flash works with the example .bit files that come with DesignLab, but not with my own .bit files made in ISE. This is not a vital issue for my current project, because I was able to load the blank circuit onto SPI so that the AVR reset was not constantly on high. So now I can use the 32u4 chip, which is the only one my currently assigned project uses. But if I want to use the FPGA chip again, I'm still no further than I was before I posted here: writing to FPGA works, but no program I use can get my own bit files to write to SPI.
  13. So I downloaded DesignLab and it seems I can load the ZPUino QuickStart circuit and sketch onto my board from the examples, and it stays persistent when I reconnect power. So I guess the SPI flash is not totally broken. But my school isn't using the Spartan 6 for ZPUino at all. We have been using Xilinx ISE projects, generating bit files, and using the Papilio Loader to get them onto our boards. I don't believe the best solution should be to just stop using that toolchain all together.
  14. You can try using ZPUino itself to perform the SPI programming. Let me know if you need some pointers on how to do it. Contact me at Alvaro
  15. Today
  16. Hi. So I'm a student at Binghamton University's EECE department. We use the Papilio Duo boards (plus the LogicStart shield, but that's not relevant) for our design courses. I (and many others in my class) have been having an issue with writing FPGA bit files to the persistent SPI flash memory. Using Papilio Loader (or even papilio-prog) to write to the FPGA directly works fine, but it needs to stay plugged into the computer, and it loses the program when you disconnect the power. When I try to write to SPI Flash, the program output does not indicate any problems. It indicates it could erase, verify erase, write, and verify successfully. But then nothing functions, even when I remove and reapply power. It starts working again when I load the file to FPGA directly. I have tried this using multiple computers (Linux, Windows, OS X) and I still have this problem. I have tried both SW1 positions to no avail, I have tried pressing the "FPGA Reset" button, and I have tried triggering an FPGA reconfiguration using papilio-prog. Nothing seems to help. Is there a known fix for this, or should I contact support to request an exchange? Note that I was able to program to SPI Flash successfully until about a month ago. (I can't think of anything that should have caused this change). Thanks.
  17. Last week
  18. Earlier
  19. Hey Brad, The 5V rail is connected directly to the USB connector so you should be able to draw as much as the USB socket can provide. If you are powering from a USB socket then it is limited to 500mA unless you are connecting through a powered hub. The Voltage regulator on the 3.3V rail can supply a maximum of 600mA if I remember correctly. Jack.
  20. Not sure if anyone noticed but there are a few new chip cores created by jotego who frequents at least on the zxuno and mist forums. (link to ym2151 clone, there are also ym2612 and a new take on sn76489) I don't own a synth wing so i've no idea if they would be an useful addition or not, nor how much work they would be to plug in. br, -V ps. the jt51 demo is using a new cycle accurate 6809 core which could be of interest to someone running old synth code on fpga
  21. thanks for the feedback
  22. Follow up... I finally figured it out. It was a combination of block number miscalculations and some timing errors in my design. The SD slot on classic computing shield works fine with both SD and SDHC cards (at least the ones I have). Thanks for the help.
  23. Hey all, Anyone know how much current I can safely draw from the 3.3 and 5V supplies on the Duo board. Looking to power 1x MAX7219 based 8x8 matrix module. Says max current draw is 2A, but I'm only going to be lighting a few leds and can dial down the brightness. Brad
  24. Thanks! I'll look into some of these options. In the meantime I haven't had much time to play with it, but I've tried 3 or 4 other cards now and still no luck. I'll post back when I figure it out.
  25. I think designlab has a ready to run example too.
  26. not sure what to suggest other than trying out Vlait's project to check the SD card interface.
  27. Hi All, First post here... I'm in the process of porting my FPGA 80's home computer to Papilio Duo but currently stumped by the SD card. I'm using a Papilio Duo and a Classic Computing Shield. What I'm seeing is exactly like what's described in this post - Basically the card initializes correctly as SDHC, a read command is issued, the read response returns success, the lead token on the data packet comes back as expected, but the data is all zeros. I've double checked the data on the card multiple times and it definitely contains data. The cause of the problem in the above post was related to voltage drops once the read starts. ie: the card initialization and most register related commands worked but any access to the actual memory resulted in zero data due to a 2v drop. So... I'm wondering if this might be a problem with the way I'm powering the board or with the shield itself. I'm powering it via USB port from my Macbook but have also tried USB plugged straight into a iPhone charger. Anyone else seen issues like this? Any help resolving this would be much appreciated including suggestions of other projects/designs that are known to work that I could use for testing the hardware side of things. Brad btw: here's the details on my project - - it's an FPGA emulation of a Microbee which was an 80's home computer designed and built here in Australia.
  28. dcachev2_zpuino_preliminar.tar.gz

    Version 2.0.0


    Preliminary ZPUino dcache (v2)
  29. Hey Keith, that long 12" cable on the digital side is going to add resistance to the equation too. You might want to take a look at that next. Jack.
  30. Thanks Jack and Jaxartes for the replies. I've read them each a couple times. And read the section Jack linked to a few times, even before I posted originally. The FPGA does have configurable voltages, but I've been very careful to set them to +3.3v. It defaults to 8ma drive strength, but I tried adjusting it to "Maximum current" with no effect. I can double check the digital input pins for proper voltage. The 12" cable mentioned is on the digital side. Between the computing shield header and the FPGA GPIO header. I am using a regular proper VGA cable on the analog side between the VGA connector of the computing shield and the monitor. What bothers me isn't so much the dimness, but the lack of range. The advantage of a 4-bit per color DAC is so that you have 16 distinct brightness levels per color. My current setup has only 0xA through 0xF usable, anything less than 0xA is black. So I end up with about 5-6 distinct brightness options per color, which gives me sort of hundreds of colors instead of thousands of colors. Note I'm not really blaming the shield -- it may be the simplest part of the equation. There's lots of moving parts here, and something along the way is breaking down. I'm just trying to figure out what that is. I'll also connect the output of a color on the analog side to ground via a 75-ohm (or close) resistor, and then measure that voltage. I'll also try outputting blocks of color from 0 to 16 on each color. Thanks
  31. Please take a look at the VGA section for the VGA circuit of the Computing Shield: This is probably the important part that is affecting your design: The VGA cable should be providing 75 ohm resistance. If you are not using a VGA cable with 75 ohm's then that might be why the colors look dim? Jack.
  32. Load more activity