Bitcoin Forum
December 06, 2016, 07:55:21 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251238 times)
Isokivi
Hero Member
*****
Offline Offline

Activity: 924


Items flashing here available at btctrinkets.com


View Profile WWW
July 10, 2012, 08:26:57 PM
 #1221

All I need to know is if I have the  unmarked SW's  correct when programing the controller. SW 1 and 6 are marked, if you could quickly tell me if they are all on or all off for SW,2, 3, 4, and 5 I would be set.

Or if someone has successfully updated theirs could tell what position they had theirs in that would help too. The board we suspect is broken anyhow always stated the update was successful although I have my doubts.
Twin_test bitstream running settings on the swiches not indicated in the picture worked for me.

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481054121
Hero Member
*
Offline Offline

Posts: 1481054121

View Profile Personal Message (Offline)

Ignore
1481054121
Reply with quote  #2

1481054121
Report to moderator
1481054121
Hero Member
*
Offline Offline

Posts: 1481054121

View Profile Personal Message (Offline)

Ignore
1481054121
Reply with quote  #2

1481054121
Report to moderator
1481054121
Hero Member
*
Offline Offline

Posts: 1481054121

View Profile Personal Message (Offline)

Ignore
1481054121
Reply with quote  #2

1481054121
Report to moderator
Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
July 10, 2012, 08:31:20 PM
 #1222

All I need to know is if I have the  unmarked SW's  correct when programing the controller. SW 1 and 6 are marked, if you could quickly tell me if they are all on or all off for SW,2, 3, 4, and 5 I would be set.

Or if someone has successfully updated theirs could tell what position they had theirs in that would help too. The board we suspect is broken anyhow always stated the update was successful although I have my doubts.
Twin_test bitstream running settings on the swiches not indicated in the picture worked for me.

So you had SW 2, 3, 4, and 5 set to on?
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 10, 2012, 08:47:18 PM
 #1223

All I need to know is if I have the  unmarked SW's  correct when programing the controller. SW 1 and 6 are marked, if you could quickly tell me if they are all on or all off for SW,2, 3, 4, and 5 I would be set.

Or if someone has successfully updated theirs could tell what position they had theirs in that would help too. The board we suspect is broken anyhow always stated the update was successful although I have my doubts.

SW2-5 can be any setting for Controller programming. SW1/6 as below.


Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
July 10, 2012, 08:53:35 PM
 #1224

Ok, that clarifies it, thank you Yohan.
DutchBrat
Hero Member
*****
Offline Offline

Activity: 868


View Profile
July 10, 2012, 09:05:08 PM
 #1225

Quote

Single board will get through customs without problems as my first board did but this is a shipment of 23 boards.

$400 for 23 boards ? that's less than $20 per board, on a value of $640

That's a steal if you ask me.... the other way around from the USA to Europe DHL would want $130 per board minimum (20%) !

Count yourself lucky  Cheesy
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 10, 2012, 09:07:13 PM
 #1226

Ok we don't know if this will fully fixes all problems because as yet we don't setups here that show the same problems some of you have and that is why we need work on each problem individually. We do need each board that you have a problem with to be reported to the bitcoin support email with the full circumstances. Not everyone on the team has the time to wade through the forum and they don't unless they stop work on new features or support work so that means problems can be missed. I will try to patch the gaps but I also have a limit in what I can find time to do. It's much better if the information arrives at the correct place and several people get to see it. It also acts as a log we can go back through then also.

Yohan,

I'd really like to provide you with valuable error reports to help your team sorting out the problems, but after the last incident I need to start from the beginning Sad

As I reported, I had a setup with 26 almost stable working CM1 boards in dual Icarus mode. Over the weekend I disassembled the setup to stack the boards and after re-assembling it I found the non deterministic behavior I already saw with the defunct units I sorted out. Some boards failed the golden nonce test, others caused Linux to hang while trying to set COM parameters, or others that start mining with a very low hashrate.

Being aware that the units worked before, I started again monkey testing: varying USB cables, hubs, ports, etc. in a fully random manner. For me it turned out that some boards work with a very specific setup, like: only with one specific USB cable connected to a passive hub that is connected to a powered hub at a given port Huh As soon as I change cable or plug into a different USB port, the golden nonce test fails or other errors occur.

If I had a clue on HW design I would check whether the FTDI chip is correctly assembled, but since I don't I can only speculate that there is some systematic problem with this component. It is hard to believe that you did not encounter this issue during your testing, when from my batch every second board is fragile.

I spent so much time now getting my boards to work, but since it turned out to be such fragile and non deterministic, I lost motivation to dig deeper. Hope this will be solved once the up/down functionality is supported.


Have a nice day.


Can you send us a board by board report on email "bitcoin.support" of what you seeing and we will go through it all on the next daily support review.
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
July 11, 2012, 10:15:11 AM
 #1227

I have made some progress on the tml bitstream, not far but better then nothing  Cheesy

Please read here -> https://bitcointalk.org/index.php?topic=49971.msg1021077#msg1021077

eb
gigantic
Member
**
Offline Offline

Activity: 90



View Profile
July 11, 2012, 01:28:07 PM
 #1228

Whoops, sorry, never mind.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 11, 2012, 01:55:54 PM
 #1229

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.
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
July 11, 2012, 02:19:31 PM
 #1230

Yohan:

SWITCH1: what dip switch bank of the 6 we have is the one you mean?
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 11, 2012, 02:20:47 PM
 #1231

Yohan:

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

It's the first bit of SW1.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 12, 2012, 01:34:40 PM
 #1232

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
****
Offline Offline

Activity: 448



View Profile
July 12, 2012, 03:54:10 PM
 #1233

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.
gigantic
Member
**
Offline Offline

Activity: 90



View Profile
July 12, 2012, 04:34:08 PM
 #1234

is there a guide for the controller setup?
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 12, 2012, 05:49:05 PM
 #1235

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
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 12, 2012, 06:07:43 PM
 #1236

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.
gigantic
Member
**
Offline Offline

Activity: 90



View Profile
July 12, 2012, 06:30:39 PM
 #1237

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
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 12, 2012, 06:34:22 PM
 #1238

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
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 12, 2012, 06:35:59 PM
 #1239

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.

zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
July 12, 2012, 06:48:16 PM
 #1240

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

Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!