Hey Ian, just OT but .... if you wrote the SPAM filter you might be able to adapt it that new people can get rid of that if they get befriended with another forum member of a certain "rank".... e.g. if you know someone in person or trust him, you can assign him to your friend list giving even a newbie full access to the forum features. That would be a decentralized way to give real contributors fast access.
I read back the the PROM content written by urjtag. The files are almost identical beside of the very last line. The original file contains nothing at the end the read-back file (read-back was done by impact) contains ^M at the very end. I would assume that might be a problem of impact, since the MCS format does not deal with any special characters.
Thus, I could assume that the content of the PROM and the original file is equal.
I somehow have the impression that the PROM is not correctly configured using urjtag. In impact I can tell via the programming parameters which clocks are used and whether the PROM should load the FPGA. Esp. this flag seems to be interesting.
Xilinx helps says:
Load FPGA Sets the Load FPGA flag in XC18V00 or Platform Flash PROM device. When this option is set, once the PROM is configured the PROM toggles the FPGA's program pin and configuration commences automatically.
Activated this I can flash the PROM via impact and it works. However, using the same impact project to generate a SVF file and trying to use urjtag does NOT work. The question is, does the SVF file contains those programming settings?
Ok guys I am making little steps forward here. After a nice night-IRC chat with Tayken we get closer... Status now:
Can use Xilinx impact + the open source Linux drivers + busblaster to burn both PROM and FPGA. This works !!!! but is slow like hell. I CAN'T for some strange reason burn an svf file by urjtag. I tried in different ways to convert the MCS file into a SVF file by using impact. 1. Using impact boundary scan and assigning the MCS-file to the PROM, convert this to a SVF, using urjtag to flash->fails I thought it might fail because urjtag can't deal with multiple device info in the SVF file (warnings and errors in urjtag). 2. Created a single device (PROM) by hand and assigned the MCS-file to it, convert to an SVF file, using urjtag to flash->fails This time urjtag does not brag about any warnings or errors. Thus leaving me clueless what is going wrong. The SVF file should be the exact copy of what impact would do if it would directly write via a cable.
At the moment I try to read-back the PROM after flashing it with urjtag (which renders the board non-function). Lets see if this gives some idea what went wrong using urjtag.
Some side remarks. During start-up of the svf flash command in urjtag takes rather long about a minute before the progress bar appears. In that time urjtag takes as little as 1.5GB of the PC RAM. A bit greedy if you ask me... noticed that when swapping kicked in and my Linux-box got as slow as running the same machine under Windows ;).
Ahh if you flash PROM or FPGA via impact, do not trust the progress bars. Silly me who thought that programming and verification would split the progress into half... noooooo programming takes from 0 to 99% and then you stuck for another 15-20 min on the last percent for verification. But hey Xilinx never claimed a linear progress bar... I guess this is an upcoming feature for Webpack 15 or the paid version :)
ok I make little progress. Still not there but it seems to get better.
First of all apologize I mixed up a few things
The board HAS two FPGAs on board. However, the JTAG chain is only connected to one of them and to its platform flash (thanks dps). That confused me first since I expected to see both FPGAs.
Furthermore, I learned that urJTAG fails if not really all devices in the JTAG chain are recognized by urJTAG. I believe this has something to do with the fact that impact addresses the devices from within the SVF-file whereas urJTAG has the part commando. Having an unkown (even bypassed) device in the chain resulted in error messages reading the SVF file from within urJTAG.
I copied over BOTH bsdl files from the xilinx webpack installation and pointed urJTAG to them. In total just for the record (and maybe someone will like to read this during his own struggle with this stuff...) After starting urjtag (again by calling jtag not urjtag ;) )
jtag> svf default.svf progress stop warning: command HIR not implemented warning: command HDR not implemented warning: command HIR not implemented warning: command HDR not implemented detail: Parsing 475240/475249 ( 99%)warning: command HIR not implemented warning: command HDR not implemented error: Error svf: SIR command length inconsistent. error: in input file between line 475249 col 1 and line 475249 col 41 error: Error occurred for SVF command, line 475248, column 0-40: SIR. detail: Parsing 475250/475249 (100%)detail: detail: Scanned device output matched expected TDO values.
Ok thats looks better already. However, the warnings and one error remain. Board is still not working....
From what I read on the urjtag mailing list this might be a problem. Having two devices in a chain might require some way of implementing the HIR and HDR comands to work correctly.
Any help is greatly welcome. Did someone here already use mutliple devices in a JTAG chain in combination with urjtag and the busblaster?
just a quick question I couldn't find much info yet. I still try to program a xcf16p. However, the version of the board returns to be STEPPING 14. urJTAG only contains STEPPING 0 in its stepping file I added 14 so now the file looks like this
Just guess there is more work to do. Otherwise, all this stepping stuff in urJTAG would be kind of senseless. Any idea where or how to make sure its working for other stepping versions.
with urJTAG I had to fight with ftdi_sio vs. ftd2XX drivers... as soon as this was sort out it worked rather nice. However, I was not able to flash the xc16fp memory successful. Something between the conversion of the MCS file from Xilinx to an SVF file and calling it went wrong. I tried it in many several way. Also later after installing the Xilinx drivers I even having the correct chain and everything the converted SVF files failed.
Via impact and the opensource drivers it worked out however as already said here, its very very slow. Ideally, I want to use urJTAG but still can't get it working.
If there is interest I can write down my findings to far in the wiki... esp. the impact Xilinx part with the open drivers... just to add it here already, its still working with the actual Xilinx webpack (14.2) even the drivers do not claim support for this version.
# Copy this file to ~/.libusb-driverrc if you want to use FTDI2232 cables # All parallel ports not defined in this file are mapped to real ports on the # system
Hi, still struggling how to program the FPGA board. Since i wasn't sucessfull using urJTAG, I thought I give Xilinx "impact" and the open source Linux drivers a chance. It seems the drivers and hence the cable gets recognized. However, performing a "Initialize chain" ends up showing me a single device xc2c32a instead of two devices (one should be xc5vlx30).
I somehow feel the scan used the wrong port of the FTDI FT2232C Dual chip and hence showing me the CPLD used by the busblaster.
Can someone confirm this or tell me how to change the channel?
the second FPGA seems to be correctly identified. Anyhow I tried to load the BSDL file, the results are the same. Still not sure I do the SVF conversion correctly in impact. I added a second device to mimick the chain as I found it by urJTAG as you said. Still receiving the same error messages.
I was going to try out to program directly from impact but the drivers trouble me. I have impact version 14.2 installed and it seems that the available drivers are not tested against this new version. Will dig a bit more.
If someone has an detailed plan how to convert a MCS file into a SVF file I am eager to hear.
I still struggel to get the toolchain up and running for the above device. I got the Linux stuff working so far (at least I hope) Here is a dump of what is working. I will be verbose to make sure I do not overlook something obvious
So far all looks good I guess. I only have a MCS file from Xilinx ISE (no access to the sources yet). I called impact created a new project and importet the MCS file. I called the "One Step SVG" process which created a file default.svf
svf default.svf stop progress Error svf: mismatch at position 31 for TDO in input file between line 21 col 1 and line 21 col 72 error: Error occurred for SVF command, line 20, column 0-71: SDR. detail: Parsing 475240/475248 ( 99%)detail: detail: Mismatches occurred between scanned device output and expected TDO values. jtag>
At this point I have trouble. Either the SVF conversion did not went right or something else is wrong as you can see from the output. The board does not react anymore (its not bricked I guess just not correctly programmed).
I would highly appreciate if someone can give me a hand and help me with that.
Two points I would like to notice. The stepping for the FPGA was not available in urJTAG. I manually added:
It seems the wiki is a bit out of date and I would be glad if we could summarize the actual status. Here is what I did so far.
I use 64 bit Arch Linux system and used a AUR package (a receipt) to build and install urJTAG from SVN. The busblaster was nicely recognized by the ftdi_sio drivers. However, the package explicitly build urJTAG against the proprietary ftd2xx drivers. No idea if that is a personal preference or a requirement. Anyhow, those drivers came as dependencies in form of another Arch Linux package (thanks Arch).
I hate if program binaries call different compared to the software name esp. for CLI-tools ;) )
Furthermore, it seems not longer necessary to used a patched version of urJTAG to address the second interface (interface=1). This seems to work with the current build from urJTAG. However, the Arch AUR shipped a patch which took care of some long int and integer conversion. This problem was addressed here already and seems not to be upstream yet.
So the question remain. Could it work with the native drivers (ftdi_sio) and where are the pros and cons? Obvious one pro would be the fact that the ftdi_sio drivers are available on most systems without additional installation.
If we once get an up-to-date "How to use it under Linux" we might push it forward to the wiki.
I like this project. Some thoughts as feedback 1. As mentioned by squonk, have the right PCB thickness. 1.6 mm might fit but might create disconnections just by looking at it ;). I have some of this ultra-slim memory sticks which have the same problem. You have to constantly press them down to guarantee a stable contact. This is really a pain.
2. Maybe people like to get rid of the USB plug after finishing the development process. This would save some space and the USB connection is still available via the headers. Maybe you could design some sort of predetermined breaking line in case people would like to use a clipper to get rid of the USB plug. Make sure this works out with the PCB tracks too.
3. I think space is very limited, but if you find a smart way to have a screw hole somewhere people could easily fix the board to an enclosure body.
I just had an idea for a website, programming, software thing. Since I do not work on web-development I just place the idea here and hope someone else like to pick it up.
Problem: Just looking out for a uC-chip with certain features. Frankly spoken, there are many uC from many different brands, Atmel, Microchip, Ti, Cypress, Hitachi, etc. Some of the feature set, are very similar and programming them in C blurs the boarders between different manufactures further. However, some features are unique and would be a win for a certain project. Most important might be the the particular combination of such features.
E.g. a not real world example Project requirement USB, DAC and ADC
ADC DAC USB Price per unit AVR: X - X $3 PIC: X X - $2 MSP430: X X X $5
Now, first of all it takes much time to scan all the different manufacture pages and do all the same parametric searches over and over. Secondly, the different prices as well as other features makes it difficult to compare them, Is a $5 all included uC solution cheaper compared to a $3 uC with an FTDI chip? Does the PIC in question come with ultralow-power mode comparable to the ultralow-power of the MSP430? How about the clock speed of the AVR compared to the PIC? The MSP430 is 16 bit but what was the bus-width of the PIC again? Keep in mind, in this simple example we took one uC of each manufacture, in real life, you would have to deal with different families and a bunch of possible chips of each manufacture already.
How great would it be to have a meta-search engine for uC. A parametric search which leads to all kind of possible uC. You specify your requirements in a parametric search and get PICs, AVRs, MSP430, etc. all side by side for a direct comparison.
if someone found time I would be happy to read about the experience. How easy was it to set-up? How much ressources (computational, memory) left for the real task? How stable is it?
Well many projects need some sort of PC interface only for a very limited amount of time (e.g. to set-up or change some parameters). You could save the FTDI or external USB-UART cable by this. E.g. add the code to the PIC to easily access the EEPROM via USB and you can whenever needed reconfigure your program by writing new data to a config area in the EEPROM without the need of a programmer. Design your PCB to become a cheap USB plug and you might have the cheapest and fastest way to reconfigure your project.
Create a small application for the PC and you are done.
Most interesting would be how much resources are occupied and if there is enough left for the real task.
Open Source Hardware