Glasswalker
|
|
August 24, 2012, 01:34:50 PM |
|
Hi everybody - I'm having some problems with my cm1 board (arrived today)
Here's what I did:
Plugged it all in and installed the drivers (Win7 X64) - all ports, etc. created ok
Tried cgminer to com ports 25-28 - nothing working - I assumed it was because the shipping controller runs at 57600 and cgminer assumes 115200 (i read that on the thread)
Used spiprog.exe to update to controller 1.5 - 0 errors and flashing red controller led,so disconnected usb and psu to cm1 and reconnected with all dip switchs on. led still flashing (?)
The red controller led stops flashing if the board is back in programming mode (sw3 & sw6 off), but isn't responding at all
Do I need a JTAG cable to reprogram the controller?
The led on the controller should flash during normal operation. You do not need a JTAG, you can program the controller and bitstream via USB (there are several "mini-howto" in this thread, and the instructions from enterpoint should work fine). It sounds like you flashed it successfully. You didn't mention which bitstream you have installed? (did you install a bitstream after receiving it?) the shipping bitstream is likely not ideal to use, as MUCH development has happened. If you're using controller 1.5, I reccomend one of makomk's new dcmwd bitstreams, that seems to currently be getting the best overall performance from the board. If you have any stability problems, you can fall back to my HashVoodoo bitstream from github at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads specifically you want the 08_16 release not the 08_20 one. (08_20 is faster but has stability issues). You may want to download both though, as the readme in the 08_20 one has some added tips/tricks for flashing in it. The 08_16 is rock solid, but only performs at 175Mhash per chip. Where makomk's bitstreams reach upwards of 200 or 210 right now (and his newer ones should solve the stability problems). I have yet to release one with his newest fixes. Hope that helps.
|
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
August 24, 2012, 02:12:38 PM |
|
Hi everybody - I'm having some problems with my cm1 board (arrived today)
Here's what I did:
Plugged it all in and installed the drivers (Win7 X64) - all ports, etc. created ok
Tried cgminer to com ports 25-28 - nothing working - I assumed it was because the shipping controller runs at 57600 and cgminer assumes 115200 (i read that on the thread)
Used spiprog.exe to update to controller 1.5 - 0 errors and flashing red controller led,so disconnected usb and psu to cm1 and reconnected with all dip switchs on. led still flashing (?)
The red controller led stops flashing if the board is back in programming mode (sw3 & sw6 off), but isn't responding at all
Do I need a JTAG cable to reprogram the controller?
The led on the controller should flash during normal operation. You do not need a JTAG, you can program the controller and bitstream via USB (there are several "mini-howto" in this thread, and the instructions from enterpoint should work fine). It sounds like you flashed it successfully. You didn't mention which bitstream you have installed? (did you install a bitstream after receiving it?) the shipping bitstream is likely not ideal to use, as MUCH development has happened. If you're using controller 1.5, I reccomend one of makomk's new dcmwd bitstreams, that seems to currently be getting the best overall performance from the board. If you have any stability problems, you can fall back to my HashVoodoo bitstream from github at https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner/downloads specifically you want the 08_16 release not the 08_20 one. (08_20 is faster but has stability issues). You may want to download both though, as the readme in the 08_20 one has some added tips/tricks for flashing in it. The 08_16 is rock solid, but only performs at 175Mhash per chip. Where makomk's bitstreams reach upwards of 200 or 210 right now (and his newer ones should solve the stability problems). I have yet to release one with his newest fixes. Hope that helps. Thanks for the help. I wasn't sure what the purpose of the red flashing light was (it's usually not good ) I've got it talking to my pc again by plugging it into a different USB port (?) and sucessfully flashed the controller with hashvoodoo_controller_25.bit I'll start with hashvoodoo_nodynclock_175.bit, following the wipe forward/ program reverse procedure - i've got SW3 and SW6 one question though: what are the correct running dip switch positions for the the ones near the FPGA's ? all on?
|
|
|
|
Glasswalker
|
|
August 24, 2012, 02:26:04 PM |
|
Thanks for the help. I wasn't sure what the purpose of the red flashing light was (it's usually not good ) I've got it talking to my pc again by plugging it into a different USB port (?) and sucessfully flashed the controller with hashvoodoo_controller_25.bit I'll start with hashvoodoo_nodynclock_175.bit, following the wipe forward/ program reverse procedure - i've got SW3 and SW6 one question though: what are the correct running dip switch positions for the the ones near the FPGA's ? all on? The flashing red LED is the clock heartbeat. Shows that the clock is actually running (on my bitstreams the red LEDs next to the FPGAs blink too) Please make sure you're using the right one, as I said there are 2 releases, the newest one (08_20_2012 I believe) is unstable, it includes a 175 up to 210 roughly I think, and all of them are unstable. They mine, but only for anywhere from 1 hour to 1 day before failing randomly. The older release 08_16_2012 has a 175oc bit file in it, that one is rock solid stable. Make sure you're using the right one I hope to release one with the full stability and fast speeds (up to 210) soon (hopefully). Anyway, as long as that's right... Using the HashVoodoo bitstreams, it ignores the dip switches at the FPGA. So it doesn't matter. But on the ones based more closely on Icarus (using an Icarus Pair), on the "front" fpga (the ones closest to the connectors on the board) they are all on I believe, and the back pair have 2 on and 2 off. Enterpoint has a diagram up on the cairnsmore support page that shows the exact positions I suggest referencing that to ensure they are in the right spot. It's best to set it to the "original" setup (with the back 2 having 2on 2off in the proper config) so that if you decide to flash any of makomk's bitstreams it should work seamlessly. My HashVoodoo bitstreams ignore the fpga specific dips anyway. Does that help?
|
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
August 24, 2012, 04:51:40 PM |
|
The flashing red LED is the clock heartbeat. Shows that the clock is actually running (on my bitstreams the red LEDs next to the FPGAs blink too) Please make sure you're using the right one, as I said there are 2 releases, the newest one (08_20_2012 I believe) is unstable, it includes a 175 up to 210 roughly I think, and all of them are unstable. They mine, but only for anywhere from 1 hour to 1 day before failing randomly. The older release 08_16_2012 has a 175oc bit file in it, that one is rock solid stable. Make sure you're using the right one I hope to release one with the full stability and fast speeds (up to 210) soon (hopefully). Anyway, as long as that's right... Using the HashVoodoo bitstreams, it ignores the dip switches at the FPGA. So it doesn't matter. But on the ones based more closely on Icarus (using an Icarus Pair), on the "front" fpga (the ones closest to the connectors on the board) they are all on I believe, and the back pair have 2 on and 2 off. Enterpoint has a diagram up on the cairnsmore support page that shows the exact positions I suggest referencing that to ensure they are in the right spot. It's best to set it to the "original" setup (with the back 2 having 2on 2off in the proper config) so that if you decide to flash any of makomk's bitstreams it should work seamlessly. My HashVoodoo bitstreams ignore the fpga specific dips anyway. Does that help? Yes, very much so! I've managed to get p0 & p1 permaflashed with nodynclock_175, but p2 & p3 fail to verify, but a temp flash seems to succeed. I'm having com port problems so cgminer only sees on usable device, but starts to mine. I think I'd be better off doing this with Linux...
|
|
|
|
Lethos
|
|
August 24, 2012, 06:52:25 PM |
|
The flashing red LED is the clock heartbeat. Shows that the clock is actually running (on my bitstreams the red LEDs next to the FPGAs blink too) Please make sure you're using the right one, as I said there are 2 releases, the newest one (08_20_2012 I believe) is unstable, it includes a 175 up to 210 roughly I think, and all of them are unstable. They mine, but only for anywhere from 1 hour to 1 day before failing randomly. The older release 08_16_2012 has a 175oc bit file in it, that one is rock solid stable. Make sure you're using the right one I hope to release one with the full stability and fast speeds (up to 210) soon (hopefully). Anyway, as long as that's right... Using the HashVoodoo bitstreams, it ignores the dip switches at the FPGA. So it doesn't matter. But on the ones based more closely on Icarus (using an Icarus Pair), on the "front" fpga (the ones closest to the connectors on the board) they are all on I believe, and the back pair have 2 on and 2 off. Enterpoint has a diagram up on the cairnsmore support page that shows the exact positions I suggest referencing that to ensure they are in the right spot. It's best to set it to the "original" setup (with the back 2 having 2on 2off in the proper config) so that if you decide to flash any of makomk's bitstreams it should work seamlessly. My HashVoodoo bitstreams ignore the fpga specific dips anyway. Does that help? Yes, very much so! I've managed to get p0 & p1 permaflashed with nodynclock_175, but p2 & p3 fail to verify, but a temp flash seems to succeed. I'm having com port problems so cgminer only sees on usable device, but starts to mine. I think I'd be better off doing this with Linux... Steve, if you having problems flashing just some of them, erasing them in full before you flash does work for me. I wrote a full up guide on this a few pages back. https://bitcointalk.org/index.php?topic=78239.msg1110647#msg1110647
|
|
|
|
toxicocean
Newbie
Offline
Activity: 24
Merit: 0
|
|
August 25, 2012, 09:00:45 AM Last edit: August 25, 2012, 09:26:51 PM by toxicocean |
|
dcmwd4e_210 is running great on my #0005 board (with 1.3 controller).
Status after running for about 11 hours:
(5s):1014.5 (avg):839.2 Mh/s | Q:900 A:7256 R:36 HW:0 E:806% U:11.6/m ICA0 | (5s):419.3 (avg):419.5 Mh/s | A:3663 R:18 HW:0 U:5.9/m ICA1 | (5s):419.0 (avg):419.8 Mh/s | A:3590 R:18 HW:0 U:5.8/m
|
|
|
|
Keninishna
|
|
August 26, 2012, 10:09:47 AM |
|
I'm putting up a 2 btc bounty if anyone can help me program my cm1 controller with a usb blaster cable. I got the drivers for the cable and made a svf file in impact now I'm just trying to get a connection going with urjtag but not getting very far. I have the usb blaster plugged into the up/down port as it uses the same cable (I assume its just a jtag port) but maybe I'm off here.
|
|
|
|
Lethos
|
|
August 26, 2012, 10:40:37 AM |
|
I'm putting up a 2 btc bounty if anyone can help me program my cm1 controller with a usb blaster cable. I got the drivers for the cable and made a svf file in impact now I'm just trying to get a connection going with urjtag but not getting very far. I have the usb blaster plugged into the up/down port as it uses the same cable (I assume its just a jtag port) but maybe I'm off here.
Is this the sort of USB blaster cable you have? http://www.suntekstore.co.uk/goods.php?id=14003019&utm_source=gbukJust to confirm.
|
|
|
|
testconpastas2
|
|
August 26, 2012, 10:42:02 AM |
|
in my limited knowledge the two jtag ports in cm1 are the 14pines ones: one next to the usb cable ( for the fpga array) and the second next to the phoenix connector (for the controller).
|
|
|
|
Keninishna
|
|
August 26, 2012, 11:08:14 AM |
|
I'm putting up a 2 btc bounty if anyone can help me program my cm1 controller with a usb blaster cable. I got the drivers for the cable and made a svf file in impact now I'm just trying to get a connection going with urjtag but not getting very far. I have the usb blaster plugged into the up/down port as it uses the same cable (I assume its just a jtag port) but maybe I'm off here.
Is this the sort of USB blaster cable you have? http://www.suntekstore.co.uk/goods.php?id=14003019&utm_source=gbukJust to confirm. Yup thats the one, I got off ebay for about 10$ in my limited knowledge the two jtag ports in cm1 are the 14pines ones: one next to the usb cable ( for the fpga array) and the second next to the phoenix connector (for the controller).
This is what I thought and the cable that comes with the usb blaster doesn't fit in that port, blah. I may just buy a cheap xilinx cable.
|
|
|
|
Lethos
|
|
August 26, 2012, 11:29:59 AM |
|
I'm putting up a 2 btc bounty if anyone can help me program my cm1 controller with a usb blaster cable. I got the drivers for the cable and made a svf file in impact now I'm just trying to get a connection going with urjtag but not getting very far. I have the usb blaster plugged into the up/down port as it uses the same cable (I assume its just a jtag port) but maybe I'm off here.
Is this the sort of USB blaster cable you have? http://www.suntekstore.co.uk/goods.php?id=14003019&utm_source=gbukJust to confirm. Yup thats the one, I got off ebay for about 10$ in my limited knowledge the two jtag ports in cm1 are the 14pines ones: one next to the usb cable ( for the fpga array) and the second next to the phoenix connector (for the controller).
This is what I thought and the cable that comes with the usb blaster doesn't fit in that port, blah. I may just buy a cheap xilinx cable. I just realised. ( also yes you'll want to make sure it's got the right number of pins ) http://www.enterpoint.co.uk/cairnsmore/cm1_rev_1_5_dip_sw.jpgYou'll notice at the bottom it says something to the effect off, if you want to program it, you have to have it plugged in directly to that board. So you can't plug the cable into the master board and flash program the slave one. I guess this is either not yet a feature or a hurdle that can't be done.
|
|
|
|
Keninishna
|
|
August 26, 2012, 12:03:59 PM |
|
I have 7 flying leads and from what I understand a standard jtag header only uses 6 pins. The usb blaster has 10 pins and the jtag port on the cm1 has 14. So now I just gotta figure out what pin goes where
|
|
|
|
|
Lethos
|
|
August 26, 2012, 01:01:23 PM |
|
Probably a good thing, when I saw that, I was thinking... if he tries this won't end well.
|
|
|
|
Glasswalker
|
|
August 26, 2012, 02:52:08 PM |
|
check out: http://www.jtagtest.com/pinouts/xilinxProvided you can get the right end, you *should* be able to adapt it just fine. BUT be extremely careful in doing it. Though I doubt you'd do physical damage (As long as you're not directly shorting pins) since jtag is powered by the board, and uses fairly low voltage signals. Still, it's possible to permanently damage the board, so be careful if you attempt this. The "safe" route, is to buy a xilinx compatible usb jtag (platform cable as xilinx calls it) for $30-$40 on ebay plus shipping.
|
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
August 26, 2012, 10:07:26 PM |
|
Yes, very much so!
I've managed to get p0 & p1 permaflashed with nodynclock_175, but p2 & p3 fail to verify, but a temp flash seems to succeed. I'm having com port problems so cgminer only sees on usable device, but starts to mine.
I think I'd be better off doing this with Linux...
Steve, if you having problems flashing just some of them, erasing them in full before you flash does work for me. I wrote a full up guide on this a few pages back. https://bitcointalk.org/index.php?topic=78239.msg1110647#msg1110647Lethos - I was following your guide of erase 0,l, 2, 3 but programming 3 & 2 always gave a verify error, hence me only permflashing 0&1. I can and have tempflashed 2&3 and can hash badly (e.g. 15min gives): [2012-08-26 22:54:20] ICA0 | (5s):380.0 (avg):378.9 Mh/s | A:3 R:0 HW:0 U:0.2/m [2012-08-26 22:54:20] ICA1 | (5s):169.4 (avg):184.8 Mh/s | A:36 R:0 HW:0 U:2.4/m [2012-08-26 22:54:20] ICA2 | (5s):0.0 (avg):272.9 Mh/s | A:5 R:1 HW:0 U:0.3/m [2012-08-26 22:54:20] ICA3 | (5s):10.0 (avg):253.8 Mh/s | A:7 R:0 HW:0 U:0.5/m
trying the erase command on 0&1 reports success: Cable cm1 type ftdi VID 0x0403 PID 0x8350 dbus data 00 enable 0b cbus data 00 data 00 Using Libftdi, Using JTAG frequency 1500000 from undivided clock JTAG chainpos: 0 Device IDCODE = 0x3401d093 Desc: XC6SLX150 USB transactions: Write 9 read 6 retries 0 but doesn't seem to do anything - the amber & red LED remain lit as if the FPGA is still waiting for work permflashing 2&3 report errors such as: DNA is 0x192fe44a926474f0 JEDEC: 20 20 0x18 0x00 Found Numonyx Device, Device ID 0x2018 256 bytes/page, 65536 pages = 16777216 bytes total
Page Program failed for flashpage 3073 But the failed flashpage has also been 1, 11265 (p2) & 1, 2049, 3073, 7169, 16385 (p3) Is this an indicator of a hardware problem? Should I try reverting to the enterpoint rev 1.5 controller and flash each fpga with a makomk bitstream? Any help here is much appreciated, thanks! (edit: for reference, my board SN is 62-0444)
|
|
|
|
Doff
|
|
August 26, 2012, 11:03:09 PM |
|
Yes, very much so!
I've managed to get p0 & p1 permaflashed with nodynclock_175, but p2 & p3 fail to verify, but a temp flash seems to succeed. I'm having com port problems so cgminer only sees on usable device, but starts to mine.
I think I'd be better off doing this with Linux...
Steve, if you having problems flashing just some of them, erasing them in full before you flash does work for me. I wrote a full up guide on this a few pages back. https://bitcointalk.org/index.php?topic=78239.msg1110647#msg1110647Lethos - I was following your guide of erase 0,l, 2, 3 but programming 3 & 2 always gave a verify error, hence me only permflashing 0&1. I can and have tempflashed 2&3 and can hash badly (e.g. 15min gives): [2012-08-26 22:54:20] ICA0 | (5s):380.0 (avg):378.9 Mh/s | A:3 R:0 HW:0 U:0.2/m [2012-08-26 22:54:20] ICA1 | (5s):169.4 (avg):184.8 Mh/s | A:36 R:0 HW:0 U:2.4/m [2012-08-26 22:54:20] ICA2 | (5s):0.0 (avg):272.9 Mh/s | A:5 R:1 HW:0 U:0.3/m [2012-08-26 22:54:20] ICA3 | (5s):10.0 (avg):253.8 Mh/s | A:7 R:0 HW:0 U:0.5/m
trying the erase command on 0&1 reports success: Cable cm1 type ftdi VID 0x0403 PID 0x8350 dbus data 00 enable 0b cbus data 00 data 00 Using Libftdi, Using JTAG frequency 1500000 from undivided clock JTAG chainpos: 0 Device IDCODE = 0x3401d093 Desc: XC6SLX150 USB transactions: Write 9 read 6 retries 0 but doesn't seem to do anything - the amber & red LED remain lit as if the FPGA is still waiting for work permflashing 2&3 report errors such as: DNA is 0x192fe44a926474f0 JEDEC: 20 20 0x18 0x00 Found Numonyx Device, Device ID 0x2018 256 bytes/page, 65536 pages = 16777216 bytes total
Page Program failed for flashpage 3073 But the failed flashpage has also been 1, 11265 (p2) & 1, 2049, 3073, 7169, 16385 (p3) Is this an indicator of a hardware problem? Should I try reverting to the enterpoint rev 1.5 controller and flash each fpga with a makomk bitstream? Any help here is much appreciated, thanks! (edit: for reference, my board SN is 62-0444) Steveme are you using a powered USB hub when doing the programming? I have found many times that a Powered USB helps smooth out the programming. Also make sure you check the USB cable, the problem you are describing is usually fixed by one of these two things if not both.
|
|
|
|
Keninishna
|
|
August 26, 2012, 11:17:19 PM |
|
check out: http://www.jtagtest.com/pinouts/xilinxProvided you can get the right end, you *should* be able to adapt it just fine. BUT be extremely careful in doing it. Though I doubt you'd do physical damage (As long as you're not directly shorting pins) since jtag is powered by the board, and uses fairly low voltage signals. Still, it's possible to permanently damage the board, so be careful if you attempt this. The "safe" route, is to buy a xilinx compatible usb jtag (platform cable as xilinx calls it) for $30-$40 on ebay plus shipping. I just bought a xilinx cable on ebay for 36$ from china. Although I imagine it woulden't be too hard to make a 10 pin to 14 pin connector for cheap.
|
|
|
|
Lethos
|
|
August 26, 2012, 11:19:15 PM |
|
Yes, very much so!
I've managed to get p0 & p1 permaflashed with nodynclock_175, but p2 & p3 fail to verify, but a temp flash seems to succeed. I'm having com port problems so cgminer only sees on usable device, but starts to mine.
I think I'd be better off doing this with Linux...
Steve, if you having problems flashing just some of them, erasing them in full before you flash does work for me. I wrote a full up guide on this a few pages back. https://bitcointalk.org/index.php?topic=78239.msg1110647#msg1110647Lethos - I was following your guide of erase 0,l, 2, 3 but programming 3 & 2 always gave a verify error, hence me only permflashing 0&1. I can and have tempflashed 2&3 and can hash badly (e.g. 15min gives): [2012-08-26 22:54:20] ICA0 | (5s):380.0 (avg):378.9 Mh/s | A:3 R:0 HW:0 U:0.2/m [2012-08-26 22:54:20] ICA1 | (5s):169.4 (avg):184.8 Mh/s | A:36 R:0 HW:0 U:2.4/m [2012-08-26 22:54:20] ICA2 | (5s):0.0 (avg):272.9 Mh/s | A:5 R:1 HW:0 U:0.3/m [2012-08-26 22:54:20] ICA3 | (5s):10.0 (avg):253.8 Mh/s | A:7 R:0 HW:0 U:0.5/m
trying the erase command on 0&1 reports success: Cable cm1 type ftdi VID 0x0403 PID 0x8350 dbus data 00 enable 0b cbus data 00 data 00 Using Libftdi, Using JTAG frequency 1500000 from undivided clock JTAG chainpos: 0 Device IDCODE = 0x3401d093 Desc: XC6SLX150 USB transactions: Write 9 read 6 retries 0 but doesn't seem to do anything - the amber & red LED remain lit as if the FPGA is still waiting for work permflashing 2&3 report errors such as: DNA is 0x192fe44a926474f0 JEDEC: 20 20 0x18 0x00 Found Numonyx Device, Device ID 0x2018 256 bytes/page, 65536 pages = 16777216 bytes total
Page Program failed for flashpage 3073 But the failed flashpage has also been 1, 11265 (p2) & 1, 2049, 3073, 7169, 16385 (p3) Is this an indicator of a hardware problem? Should I try reverting to the enterpoint rev 1.5 controller and flash each fpga with a makomk bitstream? Any help here is much appreciated, thanks! (edit: for reference, my board SN is 62-0444) Generally speaking once one of the chips starts needing a pre-emptive erase it doesn't matter changing to another bitstream or controller. Try both erasing with and without restarting in between a perma-flash, eventually you might luck out and it works. But I agree with Doff's advice, a reliable usb hub does make a big difference here.
|
|
|
|
ebereon
|
|
August 26, 2012, 11:40:41 PM |
|
Short Info about Makomk's new bitstreams:
I'm using dcmwd4e bitstreams from 200 to 220Mh on 50 boards with controller rev. 1.5 now. Invalids reach from 0.0% up to max. 3%. And again i got "tested" USB cables from enterpoint and 3! not working with controller 1.5 but with 1.3?!?...
One hour average reported from pool is 42.44GH/s (~848Mh/Board).
Update Power Consumption: 50x CM1(every FPGA! opticed with dcmwd4e bitstream to reach <3% invalids in MPBM) 1x PDB 3x LogiLink 10 Port USBHub (12,95€) 5x PSU Super-Flower SF650P14XE Golden Green Pro 80plus gold - 54 Ampere max. on 12V 2x ASUS Netbook (Win7 32bit, 1GB, Atom N450/Atom N2600) ... I can't run all 50 boards on one Win7 Netbook, Interupts taking up to 100% CPU :-/ ... I think I have to switch to Linux... 2x Windmachines (30cm(50W) + 45cm(130W) Fans) I need this at the moment to keep temps in the rig-room at 28°C. Without it I had temps 38°C-44°C in this room(Window open!). But I will move the rigs to a room in the basement(cellar). ---------- Total: 2212 Watt @ 224 Volt
eb
|
|
|
|
|