Pages:
Author

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

legendary
Activity: 1379
Merit: 1003
nec sine labore
July 23, 2012, 02:28:41 AM
Okay now I'm convinced there's something seriously wrong with my two Cairnsmore1 boards.

After trying again today to get them working at full speed, I was flashing Rev 1.2 onto both of my boards using SPIProg.exe, I turned the power off to the boards, then turned it back on. I noticed that one of my boards had different LEDs lit to the other board, even though they were using the exact same documented DIP switch settings

norulezapply,

this is a bug of revision 1.2, sometimes when starting up you get blue/red leds light up.

If you flash revision 1.3 this problem is fixed.

spiccioli.
newbie
Activity: 33
Merit: 0
July 22, 2012, 08:12:04 PM
Today I was able to get the Enterpoint cairnsmore to work with the tricone mining software without needing an isolated stand-alone cable, just the FTDI link.  The code is still early in function, and still suffers from some JTAG errors likely due to noise / reflections on the lines which will need better error handling.  I only performed several tests, but was easily able to get stable function with three rings at 100Mhz. (150 Mh/s).

I will keep you guys updated, I should have more time to work on it on Tuesday.

Here's some brief logs from submitted shares, it's fairly garbled from the ascii formatting for the colors.

Code:
[cairnsmore:1:0.1   ]   pool accepted share


H:0/0,0,0 X:87 C:60,60,55 E:0/0,0,0 T:3m38s   |  H:0/0,0,0 E:0/0,0,0 A:0 R:0 T:3m38s
                                                                                    
H:19/0,19,0 X:87 C:60,60,55 E:0/0,0,0 T:3m40s   |  H:19/0,19,0 E:0/0,0,0 A:1 R:0 T:3m41s requesting name


                                                                                        
[cairnsmore:1:0.1   ] decrypting nonce at address 0x000000b8


H:19/0,19,0 X:87 C:60,60,55 E:0/0,0,0 T:3m40s   |  H:19/0,19,0 E:0/0,0,0 A:1 R:0 T:3m41s requesting name


                                                                                        
[cairnsmore:1:0.1   ]   encrypted nonce = 0x0d210e79


H:19/0,19,0 X:87 C:60,60,55 E:0/0,0,0 T:3m40s   |  H:19/0,19,0 E:0/0,0,0 A:1 R:0 T:3m41s
                                                                                        
H:19/0,19,0 X:87 C:60,60,55 E:0/0,0,0 T:3m42s   |  H:19/0,19,0 E:0/0,0,0 A:1 R:0 T:3m43s requesting name


                                                                                        
[cairnsmore:1:0.1   ]   found a share: 0xe16ddf30


H:19/0,19,0 X:87 C:60,60,55 E:0/0,0,0 T:3m42s   |  H:19/0,19,0 E:0/0,0,0 A:1 R:0 T:3m43s requesting name


                                                                                        
[cairnsmore:1:0.1   ]   pool accepted share


H:19/0,19,0 X:87 C:60,60,55 E:0/0,0,0 T:3m42s   |  H:19/0,19,0 E:0/0,0,0 A:1 R:0 T:3m43s
                                                                                        
H:38/0,38,0 X:87 C:60,60,55 E:0/0,0,0 T:3m44s   |  H:38/0,38,0 E:0/0,0,0 A:2 R:0 T:3m45s
                                                                                        
H:37/0,37,0 X:87 C:60,60,55 E:0/0,0,0 T:3m46s   |  H:37/0,37,0 E:0/0,0,0 A:2 R:0 T:3m47s
                                                                                        
H:37/0,37,0 X:87 C:60,60,55 E:0/0,0,0 T:3m49s   |  H:37/0,37,0 E:0/0,0,0 A:2 R:0 T:3m49s
                                                                                        
H:37/0,37,0 X:87 C:60,60,55 E:0/0,0,0 T:3m51s   |  H:37/0,37,0 E:0/0,0,0 A:2 R:0 T:3m51s
                                                                                        
H:36/0,36,0 X:87 C:60,60,55 E:0/0,0,0 T:3m53s   |  H:36/0,36,0 E:0/0,0,0 A:2 R:0 T:3m53s
                                                                                        
H:36/0,36,0 X:87 C:60,60,55 E:0/0,0,0 T:3m55s   |  H:36/0,36,0 E:0/0,0,0 A:2 R:0 T:3m55s
                                                                                        
H:36/0,36,0 X:87 C:60,60,55 E:0/0,0,0 T:3m57s   |  H:36/0,36,0 E:0/0,0,0 A:2 R:0 T:3m58s
                                                                                        
H:35/0,35,0 X:87 C:60,60,55 E:0/0,0,0 T:3m59s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m requesting name
requesting name


                                                                                      
[cairnsmore:1:0.1   ] prediction: optimalFreq=229mhz, errorrate=40%, hashrate=67MH/s, alpha=0.329 beta=5.887 gamma=-5601.734


H:35/0,35,0 X:87 C:60,60,55 E:0/0,0,0 T:3m59s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m requesting name


                                                                                      
[cairnsmore:1:0.1   ] setting clock to 65 Mhz, mult=13 div=10


H:35/0,35,0 X:87 C:60,60,55 E:0/0,0,0 T:3m59s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m requesting name


                                                                                      
[cairnsmore:1:0.1   ]     ramping clock: mult=13 div=10


H:35/0,35,0 X:87 C:60,60,55 E:0/0,0,0 T:3m59s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m requesting name
requesting name


                                                                                      
[cairnsmore:1:0.2   ] setting clock to 60 Mhz, mult=6 div=5


H:35/0,35,0 X:87 C:60,60,55 E:0/0,0,0 T:3m59s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m requesting name


                                                                                      
[cairnsmore:1:0.2   ]     ramping clock: mult=6 div=5


H:35/0,35,0 X:87 C:60,60,55 E:0/0,0,0 T:3m59s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m
                                                                                      
H:35/0,35,0 X:90 C:60,65,55 E:0/0,0,0 T:4m2s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m2s requesting name


                                                                                      
[cairnsmore:1:0.1   ] decrypting nonce at address 0x0000005c


H:35/0,35,0 X:90 C:60,65,55 E:0/0,0,0 T:4m2s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m2s requesting name


                                                                                      
[cairnsmore:1:0.1   ]   encrypted nonce = 0x9a6c87ca


H:35/0,35,0 X:90 C:60,65,55 E:0/0,0,0 T:4m2s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m2s
                                                                                      
H:35/0,35,0 X:90 C:60,65,55 E:0/0,0,0 T:4m4s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m4s requesting name


                                                                                      
[cairnsmore:1:0.1   ]   found a share: 0x615b9649


H:35/0,35,0 X:90 C:60,65,55 E:0/0,0,0 T:4m4s   |  H:35/0,35,0 E:0/0,0,0 A:2 R:0 T:4m4s requesting name


                                                                                      
[cairnsmore:1:0.1   ]   pool accepted share

hm
member
Activity: 107
Merit: 10
July 22, 2012, 08:07:17 PM
I did not yet switch over to my linux machine (igel-5/3 (via c3 1ghz passive cooled) thin client with debian squeeze on sd card).

After some hours of stable hashing rates using a dual usb cable on a Thinkpad T500, I accidentally disconnected the dual usb cable from the micro usb cable. I did not succeed in reaching stable hashrates again.
So I tried a powered hama usb 2.0 4-port switch, again using dual usb cable for more usb power, but no success in reaching a stable hashrate.
I don't think my cheap chinese ac adapter is the cause of my unstable hashrates, because a friend of mine is using the same ac adapter model and has stable hash rates.

Tomorrow, I'll switch over to the linux box. If this won't help, I'll buy some RAM to revive my now defunct desktop PC.
sr. member
Activity: 476
Merit: 250
Keep it Simple. Every Bit Matters.
July 22, 2012, 05:57:54 PM
I went from a Win7 (64) Llano APU laptop, that had a usb port for each CM1 I have.
- It was unstable and would be lucky to last 1-2 hours before com ports disappeared and it stopped mining.

I changed over to a Ubuntu 12.04 Open case Intel Atom, that had to use a 4 port hub (no seperate power) to operate them, due to low number of unused usb ports.
- It has been stable for 24 hours+ first attempt. It's still mining and has been no hassle since.

So the things that changed;
- I changed the OS (Win -> Linux), this obviously effected the system it worked it alot, aswell the drivers.
- I went from a Laptop to a more traditional PC board. It is a lot less powerful of a system, but for the first 12 hours was dedicated to just mining. Later it proved it didn't need to be dedicated, since it still worked fine multiple times to play films, music etc fine while also mining.
- Direct Usb cable to usb port to having a usb hub (this should of been a negative), but appears to had no effect. However their is only 2, maybe the effect would of been worse had I had more on this hub and it not having it's own power source.

For me, It worked moving to linux. For others it works to change their usb cables etc, that was all they needed to do.
Cgminer team has actually made a guide or two on this, if your unsure what or how to do it, check the software subforum.
member
Activity: 108
Merit: 10
July 22, 2012, 04:51:38 PM
Since changing the USB cable as suggested, I've been running the board pretty solid.  I grabbed it from my WD external drive from a few years ago with a USB extension since it's a short cable.  I ordered some new ones and will try those out when they come in.

Are you sure it was the cables? i have boards that disapearing every several hours, i also tried other cables, but it didnt help.

I had the issue where they would disappear every 15-30 minutes.  Once I changed out the cable, each chip is up to 4500 shares with no issues.  Prior to that, I would be lucky if it hit 1500 shares. 
member
Activity: 89
Merit: 10
July 22, 2012, 04:39:01 PM
Since changing the USB cable as suggested, I've been running the board pretty solid.  I grabbed it from my WD external drive from a few years ago with a USB extension since it's a short cable.  I ordered some new ones and will try those out when they come in.

Are you sure it was the cables? i have boards that disapearing every several hours, i also tried other cables, but it didnt help.
member
Activity: 108
Merit: 10
July 22, 2012, 04:30:53 PM
Since changing the USB cable as suggested, I've been running the board pretty solid.  I grabbed it from my WD external drive from a few years ago with a USB extension since it's a short cable.  I ordered some new ones and will try those out when they come in.
hero member
Activity: 481
Merit: 502
July 22, 2012, 03:38:25 PM
Okay now I'm convinced there's something seriously wrong with my two Cairnsmore1 boards.

After trying again today to get them working at full speed, I was flashing Rev 1.2 onto both of my boards using SPIProg.exe, I turned the power off to the boards, then turned it back on. I noticed that one of my boards had different LEDs lit to the other board, even though they were using the exact same documented DIP switch settings (http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_SPI_PROGRAMMING_DIP_SWITCHES_SETTING.jpg).

I tried powering off and on again, and strangely enough, the LEDs matched this time.

I tried it again and they were different again.


To be honest I have no idea what is going on now with my boards. It appears that the controller is not being flashed correctly and that it is reverting back controller revisions after power cycling? Or something possibly could be wrong with my DIP switches and they are malfunctioning?

Either way, all I have at the moment is two very strange boards that net 100Mhash/s each if i'm lucky.
I hope Enterpoint can get this sorted out soon??
hm
member
Activity: 107
Merit: 10
July 22, 2012, 08:56:32 AM
thank you for the tip, eb. this time, the FAIL was sitting in front of the computer... it was me not knowing what my elbow does ... (edited original post)

I should fix it a-team style with some panzertape or move my setup from my desktop to a dedicated rack.. away from cats and children and stray elbows
sr. member
Activity: 397
Merit: 500
July 22, 2012, 08:43:34 AM
hm,

i had the same problem with 2 units, i just used a different usb cable and it's running now for 3 days without disconnecting. With the original usb it was disconnecting every day 1-2 times.

eb
hm
member
Activity: 107
Merit: 10
July 22, 2012, 08:30:08 AM
Over night I still kept it running on the win7 machine.
BUT this time I used a dual usb cable that gets power fom two usb ports.
The dual usb cable seems to have solved the instability issues regarding the hashrate:





I use a laptop (ThinkPad T500) for running cgminer. I assume it does not deliver enough power on usb or it reduces usb-power at will even though I disables all the energy management settings regarding USB and PCIe.

A friend of mine uses a siemens lifebook s series (old pentium m, win7) using standard usb cable (same energy management settings as me) and does not have any stability issues regarding hash rates.

In short, my problems seem to have been caused by bad usb powering of the controller part of the board.

but STOP... I am writing this and suddenly, both ICA fail....  Huh



I don't understand Cry I just wanted to read power comsumption from the watt-meter and moved it some inches when the FAIL happened at the same time... strange coincidence.. wouldn't the board reinitialize on a milliseconds power outage (which i could have caused by moving the watt-meter) ?

sorry... seems I was the cause of the FAIL by touching the usb cable with my elbow and loosening a little bit the connection between dual usb adapter cable and original usb cable... Roll Eyes
cgminer is running again Cheesy
sr. member
Activity: 476
Merit: 250
Keep it Simple. Every Bit Matters.
July 22, 2012, 02:52:06 AM
It was stable all night, lasted a good 8 hours. Something that is a good 4x longer than was ever acheived in windows.
I think it was Ubuntu that made the difference, I will do my best to answer any queries in this.
sr. member
Activity: 476
Merit: 250
Keep it Simple. Every Bit Matters.
July 21, 2012, 06:06:17 PM
Good problem, I saw it over in the bounty thread first.

I've finally got my little Ubuntu atom computer running these now.
We'll see if windows was the cause of the stability issues or not.
It's only been 10-15 minutes so tomorrow morning will tell me weither it worked or not.
However it's was always going to end up here, so it's good to get it setup eventually.

Take ages to get it sorted, I only use this as my HTPC (via XBMC), so it only has a wireless mouse.
On-screen keyboards suck when you actually got a lot of typing to do.

Thanks to spiccioli, your earlier posts proved quiet useful in getting it working under linux.
hm
member
Activity: 107
Merit: 10
July 21, 2012, 01:22:10 PM
good to hear news from the bitstream front.

my board #62-0017 is hashing between ~100 and ~200MH/s and only periodically reaches 380MH/s (controller rev. 1.3 & twin_test bitstream). no usb problems though (no disconnects).
i have set up a linux box in the hope that it will allow the cairnsmore to run more stable than on win7. i'll give it a try tomorrow.
in the case that my new linux setup won't fix the hashing instability, i'll contact enterpoints bitcoin.support.
happy weekend.
sr. member
Activity: 462
Merit: 251
July 21, 2012, 06:22:08 AM
Ok guys just to let know I'm not ignoring you all for any other reason than I am working on something interesting and won't be on the forum for the rest of the weekend and may be also limited in my visits during the coming week for the following reason:

Courtesy of one of our development partners, who has been working on this since we started, we now have a bitstream running a golden nonce test at 200MHz clock and without issue on all 4 FPGAs on a couple of boards for 30mins+. Now don't get too excited yet as this build still has problems running a full nonce range for mining and we are looking to see if we can stabilise this to run full range or to see if our partner can improve timing. Technically at the moment timing isn't met yet for 200MHz but there is a reasonable possibility that timing can be totally closed for 200 MHz or at 175MHz that is our 2nd fallback target level. We also have to expand testing to a wider number of boards to be more certain of design stability. The new build can run Icarus pair style or individually with the pinout we are using but we are getting better results running as individual processing units on 4 individual com channels.

Our own native development bitstream continues in parallel.

I know there will be a pile of questions ypu all want to ask on this but I am going dark, on all forms of contact, for at least the rest of the weekend so i stand a chance of progressing the design through to better stability and being more useful.

legendary
Activity: 1379
Merit: 1003
nec sine labore
July 21, 2012, 02:15:49 AM
This is dmesg output.

...
I have to say, that doesn't look like a bitstream problem. It looks very much like there's some problem with the USB hub that you're connecting the boards to - it's dropping off the bus, failing to enumerate at USB 2.0 speeds, and eventually falling back to USB 1.1. Try a different hub or connecting them directly?
Well that's certainly a good suggestion - but of course, spiccioli, note that they will get different USB numbers so be sure to compare the old and new correctly
i.e. plug a few directly into the computer and compare to the ones in the hubs - but unplug them, then first take a listing of 'ls /dev/ttyUSB*' then plug them in and compare to what it was before - the new numbers not present in the previous listing (which can be higher or in the middle of the old numbers) are of course the direct connected ones.

Also, certain old linux kernels have a problem with sending/receiving > 64 bytes over Serial+USB and literally chop off a byte at 64
Seeing the number 64 in there reminded me of that - but I don't know the kernel numbers.

makomk, kano

I don't think I have the old kernel issue,

Code:
uname -a
Linux t5570 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

It could be a usb hub issue, I'll buy a new hub soon, just to see if it makes some difference.

I can't connect them directly, though, since my HP thin client 5570 which I'm using as host pc can handle a maximum of three units since the boards require powered ports which it has not.

spiccioli
newbie
Activity: 55
Merit: 0
July 20, 2012, 09:51:55 PM
You can also rename the files to x.bit and t.bit to save on repetitive typing.
donator
Activity: 162
Merit: 100
July 20, 2012, 09:33:42 PM
Based on the post below I checked the directory and I don't have a xc6lc150.bit file. Am I in the wrong directory, or doing something else wrong? I tried to follow the PDF guide from enterpoint to the letter. Thanks for any help anyone can offer me.

When copying the twin_test.bit and shipping_test.bit files, did you not run;
Code:
Type: cp /mnt/*.bit . 

Although thinking about it, looks like you mustve downloaded "Twin Bitstream Update (Windows Version)" (http://www.enterpoint.co.uk/cairnsmore/twin_test.zip) from looking at that zip, it isnt included in there, so you will also need to download the older version "Cairnsmore1 Bitstreams and Instructions" (http://www.enterpoint.co.uk/cairnsmore/CairnsmoreProgramming.zip) which does include the necessary .bit file Cheesy

That was it, thanks for the help. Downloaded the other zip and copied the files over and it's working now. I guess I just assumed all the files I needed would be included in the zip associated with the PDF. Silly me.
newbie
Activity: 55
Merit: 0
July 20, 2012, 09:13:32 PM
I'm trying to get mpbm working on windows using windows-runtime-v0.1.0beta.zip and I get an error when trying to run mpbm.exe from the command line. I've never used mpbm before so I'm probably making a basic error.
Hey "this time",

Please make sure you can type "python -h" as a command line. If yes you have to type "python run-mpbm.py" to start MPBM. If not you have to put the installation directory of python in the %PATH% variable and start a new command line window and try again.

I have installed:
- python 2.7.x
- pyserial win32 (additional package)
- pyusb win32 (additional package)
- latest git mpbm (not 0.1.0beta!)

If you need more help just PM me and I can help you also via skype in german Wink

eb

Thanks for the offer. I don't speak german, the german file reference was just part of the error. I've now got my boards going on mpbm. I couldn't figure what was causing that error and I wound up installing python 2.6 and the standard version of mpbm from github.
newbie
Activity: 49
Merit: 0
July 20, 2012, 08:59:32 PM
Based on the post below I checked the directory and I don't have a xc6lc150.bit file. Am I in the wrong directory, or doing something else wrong? I tried to follow the PDF guide from enterpoint to the letter. Thanks for any help anyone can offer me.

When copying the twin_test.bit and shipping_test.bit files, did you not run;
Code:
Type: cp /mnt/*.bit . 

Although thinking about it, looks like you mustve downloaded "Twin Bitstream Update (Windows Version)" (http://www.enterpoint.co.uk/cairnsmore/twin_test.zip) from looking at that zip, it isnt included in there, so you will also need to download the older version "Cairnsmore1 Bitstreams and Instructions" (http://www.enterpoint.co.uk/cairnsmore/CairnsmoreProgramming.zip) which does include the necessary .bit file Cheesy
Pages:
Jump to: