Cairnsmore1 - Quad XC6SLX150 Board

[LazyOtto]

Has cgminer, or anything else, 'touched' the ports before you tried spiprog?

Try:
1) reboot the computer
2) don't start any other programs
3) run spiprog again

--

Another thought. How old / what generation is the board?

If you got it after mid-September, it is probably 1.5. Older than that things / versions get iffy.

Find this doc: "Enterpoint board notes - DIP switches"

The switch definitions are not the same on all versions.

Regardless, turn switch 3 of 8 off and try again.
I.e., 1-on, 3-off, 6-off, rest-<don't care>

-- edit 1

NOTE: That is 3 of 8 of the two switch blocks which are mounted adjacent to each other. With the power and USB connections on your left those switches are 1 through 8 starting with the one closest to you being #1.

This is all in the doc I referenced above.

-- edit 2

Yep, I think page 23 of "Cairnsmore1 Manual – Issue 1.0 20/09/2012" is wrong.
Or at least not universally 'right'. 

Try this pattern on the switches next to the molex power connector:

x
x
    x
x
------
x
    x
x
x

[1714215273]

1714215273

[1714215273]

1714215273

[1714215273]

1714215273

[1714215273]

1714215273

[Beaflag VonRathburg]

I bought both of the boards used from a member on here. I know they had the 1.5 controller on them as they were setup using up / down cables.

Testing different switch settings.

3 and 8 off = BSOD
3 and 6 off = Exactly the same issue as before where it sees the board, but won't flash the controller.

[LazyOtto]

Well, other thoughts. Not necessarily in the order to try them, just a set of more ideas.

a) Ensure the problem board is the only one connected by USB cable and the up/down cable is disconnected.
Also, as always, don't have any mining software running on the machine being used to run the flashing software.

b) Again referring to "Enterpoint board notes - DIP switches", page 8:
Switches:
1 - on - Not in Reset
3 - off - Programming Enabled
4 - on - Master
6 - off - Controller SPI Programming Enable
8 - on - Inbuilt Programmer - (only relevant when flashing the array/four FPGAs)

c) Toggle each of the switches back forth a couple of times. - Sometimes these switch blocks can get somewhat unreliable. I've got a switch on one of my CM1's which sometimes doesn't detect the 'correct' setting. And there has been at least one other person reporting this issue. Ideally, use an ohm meter to prove that each switch position is truly on or off.

d) 1) CM1 powered off. 2) usb cable disconnected. 3) Set the switches as needed. 4) power CM1 on. 5) wait two minutes - until it is *known* the device has 'settled down'. 6) connect usb cable. 7) try spiprog.

d) Prove that there isn't some other yet to be noticed problem inhibiting spiprog usage by flashing the known good board. If you can't flash the good board, you'll not be able to flash the 'bad' one either.

e) Get a compatible JTAG cable and use the xilinx ISE software to directly examine / flash the Controller and four Array FPGAs.

Option (e) is arguably not a sound financial decision. At *today's* mining difficulty level it would take two to three weeks of mining time for the 'restored' CM1 board to recoup the ~ $50 cost of the cable. At this point you might never hit break-even on the cable cost if difficulty rises fast enough. And that's assuming a reflash 'fixes' it. You have every reason to believe the board is mortally wounded.

[ebereon]

I bought both of the boards used from a member on here. I know they had the 1.5 controller on them as they were setup using up / down cables.

Testing different switch settings.

3 and 8 off = BSOD
3 and 6 off = Exactly the same issue as before where it sees the board, but won't flash the controller.

If you don't know what controller you have on the board, try also switch 7 instead of switch 6. If this works, then you have hashvoodoo controller.

I have a problem board also, which I can't flash and does not work from power up only. I have to power up the board, then the controller led illuminates weak red and the fpga leds dont do anything. Then I have to flash the controller via jtag cable and now the board works. If I power down the board I have to do the same process to get it working again.

Greets
Eb

[Entropy-uc]

Newest Issue:



Switches set per Enterpoint recommendations SW1 = On,On,On,On / SW6 = On,Off,On,On , board is detected, driver installed, and trying to flash 1.5 controller. Nothing happens.

Photograph the Dip switches when you think they are in the right state to flash the controller.

I had a very nasty time when Enterpoint shipped me 12 out of a 22 board shipment with V1.4 controller on them and no documentation of the different controller even existing!  That cost me most of a day trying to understand, and then a couple weeks where I was on the road with the odd ones that didn't program sitting idle before I could get back to look at them again.

I think I actually ended up trying random dip switch settings until I found one that worked.

[ocminer]

A little update to my board problem..

(The Board did not work at all anymore.. even with a 160MHz bitstream it produced only invalid shares..)

It's working again.. Dont laugh, but i put the board in the fridge, as I've always seen some valid shares, like 2 or 3 valid shares, before only HW errors occured so I always had the feeling it has something todo with temperatures overheating, but when touching the thermalblock or the bottomside of the board it was always handwarm..

Well.. I put it in the fridge, it runs smooth for about an hour with the 160 MHz stream.. I've now installed the 190 MHz bitstream and it is still running in my fridge with 3 degrees C ambient temperature.. As soon as I take it out it produces invalids only within seconds..

As I've mailed Enterpoint for service they replied basically that they have no time for service, it'll take about 12 weeks and I'd have to pay for it too as I've bought the board from a forum member I'll probably take apart the coolers myself and renew the thermal compound. Nice service for such a expensive board..

Very strange problem as temperatures feel totally normal...

oc

[Isokivi]

A little update to my board problem..

(The Board did not work at all anymore.. even with a 160MHz bitstream it produced only invalid shares..)

It's working again.. Dont laugh, but i put the board in the fridge, as I've always seen some valid shares, like 2 or 3 valid shares, before only HW errors occured so I always had the feeling it has something todo with temperatures overheating, but when touching the thermalblock or the bottomside of the board it was always handwarm..

Well.. I put it in the fridge, it runs smooth for about an hour with the 160 MHz stream.. I've now installed the 190 MHz bitstream and it is still running in my fridge with 3 degrees C ambient temperature.. As soon as I take it out it produces invalids only within seconds..

As I've mailed Enterpoint for service they replied basically that they have no time for service, it'll take about 12 weeks and I'd have to pay for it too as I've bought the board from a forum member I'll probably take apart the coolers myself and renew the thermal compound. Nice service for such a expensive board..

Very strange problem as temperatures feel totally normal...

oc

Im sure someone else, with a larger vocabilary in english can explain this better.. but here goes. I believe somewhere in the soldering on the board you have a hair fracture. When this happens for gpu's, motherboards or whatever, the diy-procedure is to bake it in an oven at a specific temperature for a given time. Im not going to suggest any temp or time, as this is a subject I really dont have any first hand experience on.

[ocminer]

Yes could be.. I'll try to contact Enterpoint, maybe they have an idea where, as I have a hot air smd station where I could reflow (part of) the board without big problems, but I dont want to bring "the heat on" now ;-)

[nbtcminer]

Yes could be.. I'll try to contact Enterpoint, maybe they have an idea where, as I have a hot air smd station where I could reflow (part of) the board without big problems, but I dont want to bring "the heat on" now ;-)

If everything is stock on the CM1 (i.e. Fan, Heatsinks) I would try removing the heatsinks to see what kind of thermal compound is on the units. Even reseating the heatsinks with a proper re-application of thermal grease (i.e. arctic silver) may help with your problem as it sounds like something is overheating if it works in a cooler environment. If your heatsinks are attached with push springs I would check to the tension on them to see if they are actually forcing the heatsinks to make proper contact with the spartan chips. If this was a reflow problem you would not be able to run the units in your fridge / freezer.

[crazyearner]

what hash rate do these FPGAs produce ?

[ebereon]

I'm selling my boards also -> https://bitcointalk.org/index.php?topic=157859.0

sorry, Arvicco. I hope I'm not in the way for you now, I just send only to EU, this should keep us a bit different =o)

Greets,
eb

[Newar]

I'm getting errors like these on all my boards. They are connected via USB cables on two powered (1A) USB hubs by Belkin. How can I test / investigate this further?

Code:

 [2013-03-31 00:27:56] ICA0: Comms error
 [2013-03-31 00:27:56] Failed to open Icarus on /dev/ttyUSB2
 [2013-03-31 00:27:56] ICA0: Comms error
 [2013-03-31 00:27:56] ICA1: Comms error
 [2013-03-31 00:27:56] ICA 0 failure, disabling!

Also, I got these flat ribbon cables, but they do not seem to work? I.e. only the board with the USB starts hashing.

[Newar]

I'm getting errors like these on all my boards. They are connected via USB cables on two powered (1A) USB hubs by Belkin. How can I test / investigate this further?

Code:

 [2013-03-31 00:27:56] ICA0: Comms error
 [2013-03-31 00:27:56] Failed to open Icarus on /dev/ttyUSB2
 [2013-03-31 00:27:56] ICA0: Comms error
 [2013-03-31 00:27:56] ICA1: Comms error
 [2013-03-31 00:27:56] ICA 0 failure, disabling!

Also, I got these flat ribbon cables, but they do not seem to work? I.e. only the board with the USB starts hashing.

https://en.bitcoin.it/wiki/CM1Quickstart
... from my quick start guide

You should see a set of 4 new USB comms ports in device manager as shown in the Wiki image.
The 2 highest numbered com ports (Com25, Com26 in the wiki example) are the bottom board FPGAs.  In single board mode these are the com ports you start up in CGMiner.  If you have paired boards the first 2 com ports (COM23, COM24) in the wiki example address the top board pair.  Note what COM port maps to what board.

---
it sounds to me like you are addressing com ports that aren't active.  With the paired bitstream and no up/down, only the 3rd and 4th com ports are called to operate the boards.

I'm sorry, I forgot to mention that everything runs fine for a few hours. Also, this is on Linux,


If I connect the up/down the board that does not have the USB cable connected (only the ribbon)  does nothing (LEDs stay orange).

[Isokivi]

I would like to switch out of my current mining software mpbm with my cairnsmores, what's recomended these days ?

[Doff]

You can use Bfgminer, Luke's version of Cgminer.

[LazyOtto]

bfgminer is the only other one I know of which supports CM1 dynamic speed control if that's the firmware you have loaded.

And it will use less than a tenth of the cpu as mpbm. (Which really counts on a Raspberry Pi.)

My impression when taking it for a test drive was that it didn't get quite as much out of the CM1's as mpbm, however.

If you try bfgminer, on linux, please let me know your experience after a few days of usage / comparison against mpbm.

-- edit

If you are using a reasonably fast computer, however, say one where the mpbm average cpu utilization is less than 10%, I would suggest it isn't worth your hassle / downtime to make the switch.

[Newar]

do you have the top board set to slave mode?

Took some digging how to do that, but that definitely helped :-)   Thanks!

I got rid of one of the hubs and replaced some of the USB cables with shorter ones (1ft). Overall this seemed to have improved things with no more comms errors so far (24hrs).

[jml]

You can use Bfgminer, Luke's version of Cgminer.

Does anyone know which is the latest stable version for ZTEX and CM1? I am running bfgminer 2.9.10 on a pi.

[Newar]

do you have the top board set to slave mode?

Took some digging how to do that, but that definitely helped :-)   Thanks!

I got rid of one of the hubs and replaced some of the USB cables with shorter ones (1ft). Overall this seemed to have improved things with no more comms errors so far (24hrs).

Once you get the bugs beaten down, they run solid for months at a time.  God help you if you have to power them down though.

Whilst I have spoken to soon earlier and the problem since re-occurred with the shorter cables too, I think I now have "fixed" it by moving the USB hub as far away from the CM1s as possible. Running stable for the last 48+ hours.

[tenzor]

Code:

[  582.150000] ftdi_sio ttyUSB23: urb failed to clear flow control
[ 1283.930000] usb 1-1.1: USB disconnect, device number 12
[ 1283.930000] ftdi_sio ttyUSB20: FTDI USB Serial Device converter now disconnected from ttyUSB20
[ 1283.940000] ftdi_sio 1-1.1:1.0: device disconnected
[ 1283.950000] ftdi_sio ttyUSB21: FTDI USB Serial Device converter now disconnected from ttyUSB21
[ 1283.950000] ftdi_sio 1-1.1:1.1: device disconnected
[ 1283.960000] ftdi_sio ttyUSB22: FTDI USB Serial Device converter now disconnected from ttyUSB22
[ 1283.970000] ftdi_sio 1-1.1:1.2: device disconnected
[ 1283.970000] ftdi_sio ttyUSB23: FTDI USB Serial Device converter now disconnected from ttyUSB23
[ 1283.980000] ftdi_sio 1-1.1:1.3: device disconnected

any thoughts how to fix that?