If I find a reasonably priced mating connector for the 80 pin edge connector, I might make a breakout (to two 40 pin 2x20 .1" headers) for it... would anyone be interested?
From what I can tell, the BEMICRO CV has the same edge connector as the BEMICRO SDK. In which case, you have at least one possibility:
Fortunately I have a lot of the 40 pin stacking connectors in stock, as I use them in my products... and my EZasPi 300 prototyping board, by a fortuitous coincidence, stacks perfectly on top of the BE/CV!
How do you plan to deal with the problem that the scope board grounds all the pins it doesn't use?
According to the Arrow product page these connectors are sold in multiples of 125 and are drop shipped by the supplier. $8+ is the quantity 125 price apparently.
MEC6-140-02-L-DV-A is just under $8 each, though not a right-angle connector. For a simple break-out board, I don't think this would bother me (certainly not as much as trying to use the card edge directly).
MEC6-140-02-L-DV-A is just under $8 each, though not a right-angle connector. For a simple break-out board, I don't think this would bother me (certainly not as much as trying to use the card edge directly).
I notice Arrow has 100 of both the straight and the right angle connectors in stock.
Two right angle connectors on a board would make a nice adapter so addon boards could just have the same edge fingers as the BeMicro has. That would make additional breakout boards quite a bit cheaper.
The bitfile for the BeMicroCV loaded into the board without a problem.
But following along with the user manual, it says a tcl script called "beserver.tcl" should be in the app archive, but actually it isn't there.
I've tried searching the arrow site and the whole web with no luck yet.
Apparently it's a tool from Altera supposed to permit communication thru the USB programming port.
But I'm afraid that script is modified from the generic one (that should come with both full Quartus and the stand alone programmer).
If anyone already solved this problem, please report back!
I checked and I don't have the BeServer.tcl file either. Rather gross oversight on somebody's part I'd say. I "chatted" with Avery at Arrow and he has to "reach out to a colleague (oh my!)" who has left for the day and he will get back to me Monday. I have a feeling this is going to be a tough slog. Kind of a "who's on first" situation if you know the expression. Or "right hand not knowing what left hand is doing," if you don't. These kits came packed like something done by high school kids working a part time job - just sort of thrown together. This was a real contrast with the DE0-NANO experience.
This may be a case where everyone who has received one or more of these boards should start bugging Arrow until they find the guy in the back corner who packaged the files and deliver the goods. I hope they realize that this is an embarrassing gaffe on their part. Obviously no one there tried installing and running the package.
nCk - the outfit that did this design - is just a couple of engineers. The trick would be to get through to one of them because I'm sure they can produce the script in a heartbeat. I tried (not very hard) to find out more info about nCk but had no luck.
I'll post my experiences with Avery at Arrow but that won't be happening until Monday at the earliest.
P.S.
Apparently this outfit has a web address of nck-research.com. I called them up and left a detailed message and I intend to send them an email with the same information. I'm hopeful they can resolve this quickly.
I left a phone message with this same request but thought I'd send an email just to be sure.
I recently purchased a BeScopeBundle from Arrow and, after two hours of support time, finally got a working link to the zip file containing the files needed to make the kit work.
Unfortunately the BeServer.tcl file is missing and this file is required to establish a TCPIP link to the jtag adapter. Without it there is no communication with the BeMicro CV.
Would you be so kind as to either send me a copy of this script via email or point me to a location where I can download a version of the zip file that contains it?
There are a number of us at the parallax forums who have purchased this kit and are looking forward to making it work so you may be getting other requests.
Please note that Arrow has pretty much screwed up the job of providing links to the zip file from their parts.arrow.com web area. The only place where the zip file exists is at www.arrow.com/bescope. I know this is a new item but it's disappointing that Arrow is wasting their customer's time with sloppy product support.
Looks like a great board and good design. I'm looking forward to using it as soon as you help me out by providing the necessary file.
Oh MY! I thought those pins were just remapped from the 2 - 40pin connectors!
Looking at the board schematic I see it has 60 additional lines EG-P1 to EG-P60. Wow, that really changes what can be done with the board...
Just be careful, there are some pins missing in the middle of the range, some pins are not connected (you can see easily on the CV board. Perhaps 55 or so pins are available. Not quite enough to make a full terasic 2 x 40 pin breakout, but close
How do you plan to deal with the problem that the scope board grounds all the pins it doesn't use?
One technique for this is to use a long pin stackthrough header (PC104), and cut selected pins short (~2 or 3mm) that terminate on your interposing board.
You can do this for instance for connecting a QuickStart to a Pi B+. Ground the /CTS pin at the quickstart, cut/remove the other supply pins other than Vin/5v, and let the non conflicting data pins pass through.
Just a heads up for our group buy in Oz. Received a couple of emails back and forth trying to get them to ship the batch as Arrow staff said they would. So far no luck.
One technique for this is to use a long pin stackthrough header (PC104), and cut selected pins short (~2 or 3mm) that terminate on your interposing board.
You can do this for instance for connecting a QuickStart to a Pi B+. Ground the /CTS pin at the quickstart, cut/remove the other supply pins other than Vin/5v, and let the non conflicting data pins pass through.
I see. That's workable. Run traces from the cut off pins to another connector on an unused side of the interposer board.
Here's some additional information about the BeScope software/firmware/hardware.
The design is really basic and I wouldn't recommend this for someone who actually wants to use it as a scope.
I poked around the qsys and verilog files for awhile to see what was going on. There are two 2048 byte buffers, one for each channel, that accumulate the traces. A master module is controlled via a tcpip connection through the jtag usbblaster circuit via a socket connection set up in the python display program. The initial conditions have to be set up via a missing beserver.tcl script that runs under the altera system console. It appears that this mode of communication is only available when using the qsys facilities but I may be wrong about that.
The master module is responsible for controlling the two channels and for transferring the data buffers back to python via a 512 byte fifo. I couldn't find anything about the details of how this works in the code or the RTL diagrams. I don't know how fast the transfer rate is. If it is mediated by a TCL script it could be really pokey. Looks like the python script initiates an acquisition, waits for done and then displays it. I suspect the scope spends most of its time idle waiting for the python script to command it to take a reading. As I said above, this isn't a very practical oscilloscope.
Qsys left me cold. It's a complicated framework to allow interfacing modules with widely varying I/O structures (bus width, timing, etc.) and it results in a circuit that seems a lot more complicated than it needs to be for simple applications. Maybe it's a good thing for huge projects that pull in lots of IP from various sources but it sure seems like overkill for this project. I suspect a big part of why it was done was so that the usbblaster connection could be used for programmed I/O.
On the other hand, BeScope is probably as good a way as any to get an idea of how qsys works. Like anything, if I spent enough time with it I'd probably find out things that I like but on first sight it just seems big and clunky and opaque. It sure doesn't read like Chip's elegant code.
Right now BeScope uses a little more than two cogs worth of ram. To create 8 channels of digital capture would take another cog's worth. This would result in a scope with only 2K sample buffer size. If the idea is to put in a P1v with 4 cogs then the system would be getting pretty full. By today's standards a scope with only 2K of samples is pretty minimal.
Hooking up sample storage to DDR3 ram is probably doable since my Rigol scope manages to do it. However, getting the timing right would probably be tricky.
It's probably a lot more work than it's worth, for me anyway. If I change my mind about qsys after playing around some more I'll make it known.
As it stands I don't see an easy way to avoid using qsys unless an interposer board is designed to allow pulling off some pins for a prop plug or whatever. That's because as it stands there is no way to grab any pins for IO so that only leaves the usbblaster port for IO. And that requires using qsys jtag modules. Installing P1v inside the qsys framework sounds more complicated than I want to take on but Pik or someone else here may be in a better position to offer a knowledgeable opinion about the work involved.
For those interested in exploring the tcpip communications link with the usbblaster I found the following attached pdf. I also attached the example files as a zip.
Here's some additional information about the BeScope software/firmware/hardware.
The design is really basic and I wouldn't recommend this for someone who actually wants to use it as a scope.
I poked around the qsys and verilog files for awhile to see what was going on. There are two 2048 byte buffers, one for each channel, that accumulate the traces. A master module is controlled via a tcpip connection through the jtag usbblaster circuit via a socket connection set up in the python display program. The initial conditions have to be set up via a missing beserver.tcl script that runs under the altera system console. It appears that this mode of communication is only available when using the qsys facilities but I may be wrong about that.
The master module is responsible for controlling the two channels and for transferring the data buffers back to python via a 512 byte fifo. I couldn't find anything about the details of how this works in the code or the RTL diagrams. I don't know how fast the transfer rate is. If it is mediated by a TCL script it could be really pokey. Looks like the python script initiates an acquisition, waits for done and then displays it. I suspect the scope spends most of its time idle waiting for the python script to command it to take a reading. As I said above, this isn't a very practical oscilloscope.
Qsys left me cold. It's a complicated framework to allow interfacing modules with widely varying I/O structures (bus width, timing, etc.) and it results in a circuit that seems a lot more complicated than it needs to be for simple applications. Maybe it's a good thing for huge projects that pull in lots of IP from various sources but it sure seems like overkill for this project. I suspect a big part of why it was done was so that the usbblaster connection could be used for programmed I/O.
On the other hand, BeScope is probably as good a way as any to get an idea of how qsys works. Like anything, if I spent enough time with it I'd probably find out things that I like but on first sight it just seems big and clunky and opaque. It sure doesn't read like Chip's elegant code.
Right now BeScope uses a little more than two cogs worth of ram. To create 8 channels of digital capture would take another cog's worth. This would result in a scope with only 2K sample buffer size. If the idea is to put in a P1v with 4 cogs then the system would be getting pretty full. By today's standards a scope with only 2K of samples is pretty minimal.
Hooking up sample storage to DDR3 ram is probably doable since my Rigol scope manages to do it. However, getting the timing right would probably be tricky.
It's probably a lot more work than it's worth, for me anyway. If I change my mind about qsys after playing around some more I'll make it known.
As it stands I don't see an easy way to avoid using qsys unless an interposer board is designed to allow pulling off some pins for a prop plug or whatever. That's because as it stands there is no way to grab any pins for IO so that only leaves the usbblaster port for IO. And that requires using qsys jtag modules. Installing P1v inside the qsys framework sounds more complicated than I want to take on but Pik or someone else here may be in a better position to offer a knowledgeable opinion about the work involved.
For those interested in exploring the tcpip communications link with the usbblaster I found the following attached pdf. I also attached the example files as a zip.
Thanks for looking further into this.
This board has a FT2232, I found that enabling the VCP option in the main driver, the second channel gets enabled, and a serial port device will pop up.
So all this trickery with JTAG was really unnecessary on this hardware. :frown:
I think I managed to brick my BeMicro CV, the board will now freeze the programmer.
Might be that I selected the wrong chip in the JTAG chain, and paved the MAX V cpld with asphalt?
If it's so "easy", I find it strange that there's no "newbie safety switch" for that... and no way to restore it.
The FTDI controller is still recognized correctly, and the board still holds something that blinks four of the LEDs (possibly the scope firmware since I can't remember successful loading of anything else).
I guess some day I'll get a cheapy usb-blaster clone, and try if it works from the 10pin JTAG header.
This board has a FT2232, I found that enabling the VCP option in the main driver, the second channel gets enabled, and a serial port device will pop up.
So all this trickery with JTAG was really unnecessary on this hardware. :frown:
I think I managed to brick my BeMicro CV, the board will now freeze the programmer.
Might be that I selected the wrong chip in the JTAG chain, and paved the MAX V cpld with asphalt?
If it's so "easy", I find it strange that there's no "newbie safety switch" for that... and no way to restore it.
The FTDI controller is still recognized correctly, and the board still holds something that blinks four of the LEDs (possibly the scope firmware since I can't remember successful loading of anything else).
I guess some day I'll get a cheapy usb-blaster clone, and try if it works from the 10pin JTAG header.
Do you remember any details about what you did just before the BeMicro stopped working? I would hope that there are identifiers buried in the JTAG downloads to prevent sending an unintended bitstream to a particular device! Gadzooks!
My impression of the "fit and finish" of the DE0-Nano is much better than the BeMicro CV. It's more expensive but the documentation and support is good. Arrow isn't making much on the BeMicro CV so I expect the effort to produce quality support is not going to be there.
How did you enable the VCP option of the 2232 in the main driver? Were you in the JTAG programmer for that or is it something that can be set from the USB driver setup?
Might be that I selected the wrong chip in the JTAG chain, and paved the MAX V cpld with asphalt?
If it's so "easy", I find it strange that there's no "newbie safety switch" for that... and no way to restore it.
That would be surprising, as JTAG commands for things like erase are quite specific.
Can you try it on another PC, in case the setup morphed ?
Where I've seen FT2232H used, I think one half runs as JTAG (MPSSE?) and one half runs as UART
How did you enable the VCP option of the 2232 in the main driver? Were you in the JTAG programmer for that or is it something that can be set from the USB driver setup?
That bit makes me suspicious, maybe doing that flipped FT modes, and the ISP half may need to be set back to JTAG.
That bit makes me suspicious, maybe doing that flipped FT modes, and the ISP half may need to be set back to JTAG.
On my ancient XP system page in the usbblaster driver section there is a checkbox for enabling VCP in the driver options. I'm NOT going to enable it at this point. Even if the 2232 has support for an additional serial channel it doesn't mean the BeMicro CV has been wired up to use it even though they might have.
This board has a FT2232, I found that enabling the VCP option in the main driver, the second channel gets enabled, and a serial port device will pop up.
On my ancient XP system page in the usbblaster driver section there is a checkbox for enabling VCP in the driver options. I'm NOT going to enable it at this point. Even if the 2232 has support for an additional serial channel it doesn't mean the BeMicro CV has been wired up to use it even though they might have.
Now I'm a little more confused.
The manual I found
Hardware_Reference_Guide_for_BeMicro_CV_A2_v1.05.pdf
lacks searchable SCH, but mentions U3=FT245Q, but maybe that is out of date ?
I also found
hardware_reference_guide_for_bemicro_cv_1.1.pdf
but that also says FT245Q ? (which seems sillier choice than FT2232H, as it is much slower...)
The Lattice Boards I have do have FT2232H, and they have one half for direct JTAG (no MAX V ) and one half as an optional user serial port
Is there a version number on the BeMicro CV ? - maybe a 2014 upgrade gets FT2232H ?
Tubular you are right, what I saw with naked eye was a date code or something.
Now I pulled out a magnifier lens, and indeed it is an FT245... damn I'm getting old!
Anyway, I had the VCP option enabled only *after* the board was already unresponsive.
I tried completely removal of both the usb blaster and serial port, then reinstalling only usb-blaster from quartus driver directory, but did not help.
I tried with two different PCs, one with Quartus 14 and another laptop with Quartus 9.1 (programmer only 32bit).
I will try another tomorrow, it was the one I used the only time I managed to program the board (Quartus 13).
I think I managed to brick my BeMicro CV, the board will now freeze the programmer.
For what it's worth: I've been having trouble with my BeMicro CV too. It doesn't freeze the programmer as you mention, but when I unplug it and replug it after programming, it doesn't get recognized by the USB controller. I'm running Windows 7 64 bits on a notebook with an Intel ICH9 chipset.
HOWEVER I found out that I can make it work again by going into the device manager (type "devmgmt.msc" without the quotes in the Start menu) by disabling and enabling the USB host controller where the board would normally be connected (in my case: "Intel ICH9 Family USB Universal Host Controller - 2936") while the board is NOT connected, and then connect the board again. It's pretty annoying but other than rebooting my system every time I program the board, there is apparently no other way to fix my problem.
It might not be the same problem as you're having, but I hope it helps...
This may or may not be relevant here, but I found that leaving a prop plug connected to the DE0, but unplugged from the PC, resulted in a continuous reset loop where the first cog was loading up, led 0 switches on, then quickly reboots every second or two (the led 0 blinks on only briefly). That may be unique to my setup and power supplies, or could be a generic fault
One of our DE0's failed "overnight" and I suspect leaving it doing that for an extended time might have contributed to the failure. At least that's my best guess. I haven't checked whether the same thing happens with the BeMicro. Will get to it eventually. Just a heads up in the meantime.
I left a phone message with this same request but thought I'd send an email just to be sure.
I recently purchased a BeScopeBundle from Arrow and, after two hours of support time, finally got a working link to the zip file containing the files needed to make the kit work.
Unfortunately the BeServer.tcl file is missingand this file is required to establish a TCPIP link to the jtag adapter. Without it there is no communication with the BeMicro CV.
Would you be so kind as to either send me a copy of this script via email or point me to a location where I can download a version of the zip file that contains it?
There are a number of us at the parallax forums who have purchased this kit and are looking forward to making it work so you may be getting other requests.
Please note that Arrow has pretty much screwed up the job of providing links to the zip file from their parts.arrow.com web area. The only place where the zip file exists is at www.arrow.com/bescope. I know this is a new item but it's disappointing that Arrow is wasting their customer's time with sloppy product support.
Looks like a great board and good design. I'm looking forward to using it as soon as you help me out by providing the necessary file.
Thanks
Here's the response I got this morning:
John,
Thank you for contacting us. Are you saying the zip file Arrow posted is incomplete? We generally would refer support requests like this to Arrow but in this case it sounds like you have already tried that route.
Matt
What I said seems clear enough to me - but then, I wrote it. Matt didn't bother to attach the requested files and I haven't heard back from my response saying that, yes indeed, the zip file was incomplete. I passed him the link to the Arrow hosted zip files and suggested he take a look.
Avery, from Arrow, hasn't called back after promising to "reach out to his colleague" either.
There are now well over a hundred kits sold that can't be used as intended. I realize that a lot of the sales were probably for the BeMicro CV and the scope board board was an extra bonus. But surely some of the people will try to run the software.
Do I have unreasonable expectations? I've never had a problem with Digikey or Mouser over the years but, then again, they don't sell self-produced development kits. Maybe they know better than to get involved in such activities.
Just received a call from a sales rep at Arrow who was following up on the first BeMicro CV I ordered. I pretty much unloaded on her in very frank terms about the difficulties I've encountered with the BeScope software - both in finding it and then discovering that it's missing an essential file. I pointed out that there are a number of people watching this conversation and that it would be a good thing for Arrow and nCk-research to get the problems straightened out. I figure the sales rep is where the rubber meets the road - she's the one who has to make the cold calls and the thought of bad publicity is anathema.
She has my number. Neither Avery at Arrow or Matt at sales@nCk-research.com have gotten back to me.
Matt sent me the following server.tcl which I renamed to BeServer.tcl since that's how it's named in the manual. I haven't tested it yet. For some reason I can't upload it as a .tcl file so I've zipped it up.
Comments
From what I can tell, the BEMICRO CV has the same edge connector as the BEMICRO SDK. In which case, you have at least one possibility:
Samtec MEC6-140-02-L-D-RA1-TR
And I would be interested in such a board.
How do you plan to deal with the problem that the scope board grounds all the pins it doesn't use?
According to the Arrow product page these connectors are sold in multiples of 125 and are drop shipped by the supplier. $8+ is the quantity 125 price apparently.
http://www.newark.com/webapp/wcs/stores/servlet/Search?st=MEC614002
MEC6-140-02-L-DV-A is just under $8 each, though not a right-angle connector. For a simple break-out board, I don't think this would bother me (certainly not as much as trying to use the card edge directly).
I notice Arrow has 100 of both the straight and the right angle connectors in stock.
Two right angle connectors on a board would make a nice adapter so addon boards could just have the same edge fingers as the BeMicro has. That would make additional breakout boards quite a bit cheaper.
I checked and I don't have the BeServer.tcl file either. Rather gross oversight on somebody's part I'd say. I "chatted" with Avery at Arrow and he has to "reach out to a colleague (oh my!)" who has left for the day and he will get back to me Monday. I have a feeling this is going to be a tough slog. Kind of a "who's on first" situation if you know the expression. Or "right hand not knowing what left hand is doing," if you don't. These kits came packed like something done by high school kids working a part time job - just sort of thrown together. This was a real contrast with the DE0-NANO experience.
This may be a case where everyone who has received one or more of these boards should start bugging Arrow until they find the guy in the back corner who packaged the files and deliver the goods. I hope they realize that this is an embarrassing gaffe on their part. Obviously no one there tried installing and running the package.
nCk - the outfit that did this design - is just a couple of engineers. The trick would be to get through to one of them because I'm sure they can produce the script in a heartbeat. I tried (not very hard) to find out more info about nCk but had no luck.
I'll post my experiences with Avery at Arrow but that won't be happening until Monday at the earliest.
P.S.
Apparently this outfit has a web address of nck-research.com. I called them up and left a detailed message and I intend to send them an email with the same information. I'm hopeful they can resolve this quickly.
Here is the email:
sales@nck-research.com
Howdy,
I left a phone message with this same request but thought I'd send an email just to be sure.
I recently purchased a BeScopeBundle from Arrow and, after two hours of support time, finally got a working link to the zip file containing the files needed to make the kit work.
Unfortunately the BeServer.tcl file is missing and this file is required to establish a TCPIP link to the jtag adapter. Without it there is no communication with the BeMicro CV.
Would you be so kind as to either send me a copy of this script via email or point me to a location where I can download a version of the zip file that contains it?
There are a number of us at the parallax forums who have purchased this kit and are looking forward to making it work so you may be getting other requests.
Please note that Arrow has pretty much screwed up the job of providing links to the zip file from their parts.arrow.com web area. The only place where the zip file exists is at www.arrow.com/bescope. I know this is a new item but it's disappointing that Arrow is wasting their customer's time with sloppy product support.
Looks like a great board and good design. I'm looking forward to using it as soon as you help me out by providing the necessary file.
Thanks
it's a common object serialization library used with python.
I just noticed that the BESCOPEBUNDLE comes with the SDP Interposer board (http://www.analog.com/en/system-demonstration-platform/interposer-boards/evaluation/SDP-BEMICRO/eb.html). If that's the case, it might be a lot easier finding the mating 120-pin connector for that board.
Quest Components has them, $12.75qty1, $6.34 qty.4+
(offset board between the CV and the scope board would work too)
Just be careful, there are some pins missing in the middle of the range, some pins are not connected (you can see easily on the CV board. Perhaps 55 or so pins are available. Not quite enough to make a full terasic 2 x 40 pin breakout, but close
One technique for this is to use a long pin stackthrough header (PC104), and cut selected pins short (~2 or 3mm) that terminate on your interposing board.
You can do this for instance for connecting a QuickStart to a Pi B+. Ground the /CTS pin at the quickstart, cut/remove the other supply pins other than Vin/5v, and let the non conflicting data pins pass through.
I see. That's workable. Run traces from the cut off pins to another connector on an unused side of the interposer board.
The design is really basic and I wouldn't recommend this for someone who actually wants to use it as a scope.
I poked around the qsys and verilog files for awhile to see what was going on. There are two 2048 byte buffers, one for each channel, that accumulate the traces. A master module is controlled via a tcpip connection through the jtag usbblaster circuit via a socket connection set up in the python display program. The initial conditions have to be set up via a missing beserver.tcl script that runs under the altera system console. It appears that this mode of communication is only available when using the qsys facilities but I may be wrong about that.
The master module is responsible for controlling the two channels and for transferring the data buffers back to python via a 512 byte fifo. I couldn't find anything about the details of how this works in the code or the RTL diagrams. I don't know how fast the transfer rate is. If it is mediated by a TCL script it could be really pokey. Looks like the python script initiates an acquisition, waits for done and then displays it. I suspect the scope spends most of its time idle waiting for the python script to command it to take a reading. As I said above, this isn't a very practical oscilloscope.
Qsys left me cold. It's a complicated framework to allow interfacing modules with widely varying I/O structures (bus width, timing, etc.) and it results in a circuit that seems a lot more complicated than it needs to be for simple applications. Maybe it's a good thing for huge projects that pull in lots of IP from various sources but it sure seems like overkill for this project. I suspect a big part of why it was done was so that the usbblaster connection could be used for programmed I/O.
On the other hand, BeScope is probably as good a way as any to get an idea of how qsys works. Like anything, if I spent enough time with it I'd probably find out things that I like but on first sight it just seems big and clunky and opaque. It sure doesn't read like Chip's elegant code.
Right now BeScope uses a little more than two cogs worth of ram. To create 8 channels of digital capture would take another cog's worth. This would result in a scope with only 2K sample buffer size. If the idea is to put in a P1v with 4 cogs then the system would be getting pretty full. By today's standards a scope with only 2K of samples is pretty minimal.
Hooking up sample storage to DDR3 ram is probably doable since my Rigol scope manages to do it. However, getting the timing right would probably be tricky.
It's probably a lot more work than it's worth, for me anyway. If I change my mind about qsys after playing around some more I'll make it known.
As it stands I don't see an easy way to avoid using qsys unless an interposer board is designed to allow pulling off some pins for a prop plug or whatever. That's because as it stands there is no way to grab any pins for IO so that only leaves the usbblaster port for IO. And that requires using qsys jtag modules. Installing P1v inside the qsys framework sounds more complicated than I want to take on but Pik or someone else here may be in a better position to offer a knowledgeable opinion about the work involved.
For those interested in exploring the tcpip communications link with the usbblaster I found the following attached pdf. I also attached the example files as a zip.
Thanks for looking further into this.
This board has a FT2232, I found that enabling the VCP option in the main driver, the second channel gets enabled, and a serial port device will pop up.
So all this trickery with JTAG was really unnecessary on this hardware. :frown:
I think I managed to brick my BeMicro CV, the board will now freeze the programmer.
Might be that I selected the wrong chip in the JTAG chain, and paved the MAX V cpld with asphalt?
If it's so "easy", I find it strange that there's no "newbie safety switch" for that... and no way to restore it.
The FTDI controller is still recognized correctly, and the board still holds something that blinks four of the LEDs (possibly the scope firmware since I can't remember successful loading of anything else).
I guess some day I'll get a cheapy usb-blaster clone, and try if it works from the 10pin JTAG header.
Do you remember any details about what you did just before the BeMicro stopped working? I would hope that there are identifiers buried in the JTAG downloads to prevent sending an unintended bitstream to a particular device! Gadzooks!
My impression of the "fit and finish" of the DE0-Nano is much better than the BeMicro CV. It's more expensive but the documentation and support is good. Arrow isn't making much on the BeMicro CV so I expect the effort to produce quality support is not going to be there.
How did you enable the VCP option of the 2232 in the main driver? Were you in the JTAG programmer for that or is it something that can be set from the USB driver setup?
That would be surprising, as JTAG commands for things like erase are quite specific.
Can you try it on another PC, in case the setup morphed ?
Where I've seen FT2232H used, I think one half runs as JTAG (MPSSE?) and one half runs as UART
That bit makes me suspicious, maybe doing that flipped FT modes, and the ISP half may need to be set back to JTAG.
On my ancient XP system page in the usbblaster driver section there is a checkbox for enabling VCP in the driver options. I'm NOT going to enable it at this point. Even if the 2232 has support for an additional serial channel it doesn't mean the BeMicro CV has been wired up to use it even though they might have.
My board has an FT245 which also supports VCP.
Now I'm a little more confused.
The manual I found
Hardware_Reference_Guide_for_BeMicro_CV_A2_v1.05.pdf
lacks searchable SCH, but mentions U3=FT245Q, but maybe that is out of date ?
I also found
hardware_reference_guide_for_bemicro_cv_1.1.pdf
but that also says FT245Q ? (which seems sillier choice than FT2232H, as it is much slower...)
The Lattice Boards I have do have FT2232H, and they have one half for direct JTAG (no MAX V ) and one half as an optional user serial port
Is there a version number on the BeMicro CV ? - maybe a 2014 upgrade gets FT2232H ?
There may be some commonality with the ftdi driver though
Now I pulled out a magnifier lens, and indeed it is an FT245... damn I'm getting old!
Anyway, I had the VCP option enabled only *after* the board was already unresponsive.
I tried completely removal of both the usb blaster and serial port, then reinstalling only usb-blaster from quartus driver directory, but did not help.
I tried with two different PCs, one with Quartus 14 and another laptop with Quartus 9.1 (programmer only 32bit).
I will try another tomorrow, it was the one I used the only time I managed to program the board (Quartus 13).
Thanks all for the suggestions
For what it's worth: I've been having trouble with my BeMicro CV too. It doesn't freeze the programmer as you mention, but when I unplug it and replug it after programming, it doesn't get recognized by the USB controller. I'm running Windows 7 64 bits on a notebook with an Intel ICH9 chipset.
HOWEVER I found out that I can make it work again by going into the device manager (type "devmgmt.msc" without the quotes in the Start menu) by disabling and enabling the USB host controller where the board would normally be connected (in my case: "Intel ICH9 Family USB Universal Host Controller - 2936") while the board is NOT connected, and then connect the board again. It's pretty annoying but other than rebooting my system every time I program the board, there is apparently no other way to fix my problem.
It might not be the same problem as you're having, but I hope it helps...
===Jac
One of our DE0's failed "overnight" and I suspect leaving it doing that for an extended time might have contributed to the failure. At least that's my best guess. I haven't checked whether the same thing happens with the BeMicro. Will get to it eventually. Just a heads up in the meantime.
Here's the response I got this morning:
John,
Thank you for contacting us. Are you saying the zip file Arrow posted is incomplete? We generally would refer support requests like this to Arrow but in this case it sounds like you have already tried that route.
Matt
What I said seems clear enough to me - but then, I wrote it. Matt didn't bother to attach the requested files and I haven't heard back from my response saying that, yes indeed, the zip file was incomplete. I passed him the link to the Arrow hosted zip files and suggested he take a look.
Avery, from Arrow, hasn't called back after promising to "reach out to his colleague" either.
There are now well over a hundred kits sold that can't be used as intended. I realize that a lot of the sales were probably for the BeMicro CV and the scope board board was an extra bonus. But surely some of the people will try to run the software.
Do I have unreasonable expectations? I've never had a problem with Digikey or Mouser over the years but, then again, they don't sell self-produced development kits. Maybe they know better than to get involved in such activities.
Just received a call from a sales rep at Arrow who was following up on the first BeMicro CV I ordered. I pretty much unloaded on her in very frank terms about the difficulties I've encountered with the BeScope software - both in finding it and then discovering that it's missing an essential file. I pointed out that there are a number of people watching this conversation and that it would be a good thing for Arrow and nCk-research to get the problems straightened out. I figure the sales rep is where the rubber meets the road - she's the one who has to make the cold calls and the thought of bad publicity is anathema.
She has my number. Neither Avery at Arrow or Matt at sales@nCk-research.com have gotten back to me.
So I have cancelled our order.