Cairnsmore1 - Quad XC6SLX150 Board - page 67.

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: zefir on July 12, 2012, 01:48:16 PM

Quote from: spiccioli on July 12, 2012, 01:35:59 PM

BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.

Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying Sad

Zefir,

vista 32 bit.

spiccioli

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: yohan on July 12, 2012, 04:02:33 PM

Quote from: zefir on July 12, 2012, 01:48:16 PM

Quote from: spiccioli on July 12, 2012, 01:35:59 PM

BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.

Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying Sad

The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features.

We have been using Win7 and XP here.

What?

30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!?

spiccioli

yohan

sr. member

Activity: 462

Merit: 251

Quote from: testconpastas2 on July 12, 2012, 04:15:20 PM

Quote from: yohan on July 12, 2012, 03:57:06 PM

Controller update zip has been updated to include instructions. Get it at http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html.

Yohan I think you've forgotten to add the controller .exe into the zip.

Thanks. I think that is sorted now.

testconpastas2

full member

Activity: 199

Merit: 100

Quote from: yohan on July 12, 2012, 03:57:06 PM

Controller update zip has been updated to include instructions. Get it at http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html.

Yohan I think you've forgotten to add the controller .exe into the zip.

yohan

sr. member

Activity: 462

Merit: 251

Quote from: zefir on July 12, 2012, 01:48:16 PM

Quote from: spiccioli on July 12, 2012, 01:35:59 PM

BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.

Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying Sad

The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features.

We have been using Win7 and XP here.

yohan

sr. member

Activity: 462

Merit: 251

Controller update zip has been updated to include instructions. Get it at http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html.

yohan

sr. member

Activity: 462

Merit: 251

Quote from: gigantic on July 12, 2012, 11:34:08 AM

is there a guide for the controller setup?

I'll put that back shortly updated. I took off the link to the Rev 1.1 version and forgot it had the only manual.

Quote from: spiccioli on July 12, 2012, 01:35:59 PM

BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.

spiccioli.

We are working on improving SPI programming. Our aim is to get rid of the VM and do something more native. There should be something for Linux as well. It's really just a matter of having the time to do these items currently. Moving the bitstream forward and dealing with CGminer/driver bugs is a higher priority at the moment but these other things will come behind those things.

gigantic

member

Activity: 89

Merit: 10

i got 1 board not getting any shares, and i got 1 board that cgminer refuse to accept altought it is showing in the device manager, 2, out of 6..

zefir

donator

Activity: 919

Merit: 1000

Quote from: spiccioli on July 12, 2012, 01:35:59 PM

BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.

Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying Sad

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: spiccioli on July 12, 2012, 01:34:22 PM

Quote from: gigantic on July 12, 2012, 01:30:39 PM

i did 6 boards, now the red light is blinking faster, that is, after i have done,, and changed the dip switched to the twin_test dips, is that normal?

yes

spiccioli

BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.

spiccioli.

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: gigantic on July 12, 2012, 01:30:39 PM

i did 6 boards, now the red light is blinking faster, that is, after i have done,, and changed the dip switched to the twin_test dips, is that normal?

yes

spiccioli

gigantic

member

Activity: 89

Merit: 10

i did 6 boards, now the red light is blinking faster, that is, after i have done,, and changed the dip switched to the twin_test dips, is that normal?

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: spiccioli on July 12, 2012, 12:49:05 PM

Quote from: yohan on July 12, 2012, 10:54:10 AM

As part of our work on Rev 1.3 of the controller we found an unusual "feature" and is was related to a cheap USB hub we are using in one of system test setups. What we found was that this hub didn't turn power off properly when the host laptop released the port as it should. Indirectly this was causing a lockup of the array FPGAs. We have added an extra reset function to clock startup and this appears to solve the issue.

On our test setups we are now getting a good balance of hashing now on both FPGAs running the twin bitstream so I would recommend anyone with a controller on Rev 1.0/1.1 updates it to Rev 1.3.

Yohan,

I've flashed all my boards to 1.3, now I'm getting

Code:

 [2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB2: get 00000000, should: 000187a2
 [2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB3: get 00000000, should: 000187a2

port numbers are nearly random, sometimes it's ttyUSB26/27, sometimes just a FPGA out of a couple like ttyUSB15 right now.

ttyUSB2/3 fail nearly always.

Is the new revision requiring more power from the USB port?

I'm on two usb hubs, a 2.5A 7 port hub and a 2.5A 4 port hub from Belkin for my ten boards.

spiccioli

Can it be a timining issue? After a dozen restarts, ttyUSB2/3 are now OK (three restarts and no problem on them), but ttyUSB14 fails...

spiccioli

edit: linux ubuntu 12.04 64 bit, cgminer 2.4.3 32 bit, twin_test.bit on all FPGAs (0/3) in permanent mode. This system has been hashing for more than 10 days without problems on controller 1.1 and last two days on 1.2.

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: yohan on July 12, 2012, 10:54:10 AM

As part of our work on Rev 1.3 of the controller we found an unusual "feature" and is was related to a cheap USB hub we are using in one of system test setups. What we found was that this hub didn't turn power off properly when the host laptop released the port as it should. Indirectly this was causing a lockup of the array FPGAs. We have added an extra reset function to clock startup and this appears to solve the issue.

On our test setups we are now getting a good balance of hashing now on both FPGAs running the twin bitstream so I would recommend anyone with a controller on Rev 1.0/1.1 updates it to Rev 1.3.

Yohan,

I've flashed all my boards to 1.3, now I'm getting

Code:

 [2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB2: get 00000000, should: 000187a2
 [2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB3: get 00000000, should: 000187a2

port numbers are nearly random, sometimes it's ttyUSB26/27, sometimes just a FPGA out of a couple like ttyUSB15 right now.

ttyUSB2/3 fail nearly always.

Is the new revision requiring more power from the USB port?

I'm on two usb hubs, a 2.5A 7 port hub and a 2.5A 4 port hub from Belkin for my ten boards.

spiccioli

gigantic

member

Activity: 89

Merit: 10

is there a guide for the controller setup?

yohan

sr. member

Activity: 462

Merit: 251

As part of our work on Rev 1.3 of the controller we found an unusual "feature" and is was related to a cheap USB hub we are using in one of system test setups. What we found was that this hub didn't turn power off properly when the host laptop released the port as it should. Indirectly this was causing a lockup of the array FPGAs. We have added an extra reset function to clock startup and this appears to solve the issue.

On our test setups we are now getting a good balance of hashing now on both FPGAs running the twin bitstream so I would recommend anyone with a controller on Rev 1.0/1.1 updates it to Rev 1.3.

yohan

sr. member

Activity: 462

Merit: 251

Rev 1.3 of the controller will be on the temporary support webpage http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html shortly. It's should sort out the clock start up problem introducted in Rev 1.2.

Rev 1.3 also has a new thermal protection feature that senses if the fan is operating in the correct speed range. This feature will turn off the array power supplies if the fan does not show as being in the correct speed range. That covers fan failures, something blocking the fan rotation, or even an extreme voltage drop on the 12V supply.

If you use a different fan other than the standard F12 or don't use a fan connection in all boards i.e. in side blow configuration this may/will force the turn off the relevant board power supplies. However there is an override using SWITCH2 of the controller dip switches. This is not recommended to use unless you really have to. It is as much a safety feature as it is damage limitation feature for the boards.

yohan

sr. member

Activity: 462

Merit: 251

Quote from: ebereon on July 11, 2012, 09:19:31 AM

Yohan:

SWITCH1: what dip switch bank of the 6 we have is the one you mean?

It's the first bit of SW1.

ebereon

sr. member

Activity: 397

Merit: 500

Yohan:

SWITCH1: what dip switch bank of the 6 we have is the one you mean?

yohan

sr. member

Activity: 462

Merit: 251

We found one minor issue with Rev 1.2 controller and there is a circumstance were the clock outputs don't start after the board is powered. You can work around this in a temporary fashion by toggling SWITCH1 off then on of the Controller dip switches. This is a reset function and the clocks should start then and be ok until you turn the board off.

Rev 1.3 is being prepared to sort this properly and should be available later today or early tomorow.

Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 67. (Read 286370 times)