gigantic : try to plug only clairnsmore's (cm) to one usb hub , if cm disconnects then unplug all of them and uninstall the usb hub from windows...
after uninstalling check for new hardware and usb hub will be installed again. Then plug cm's one by one and after that you should have all com ports available .
if you have just programmed your cm then turn it off after you had changed the sw1 3 to on.
Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 76. (Read 286370 times)
Hi 
ok, at this stage i eliminate all other possibilites, the problem is CGminer for me,, when i downloaded it from enterpoint, it had 2 files, the twin and shipping, but when try to run it, it says libcurl.DLL is missing, so i downloaded the regular cgminer, and placed all the files inside the enterpoint cgminer, and its working for several minutes, after that, the USB is disappearing completly, with no way but to shutdown the computer in order to see the crairnsmore1 again on the device manager, so the problem is CGMiner! any help i appreciate!
oh, and this is the command i am runing-
cgminer_twintest -o pit.deepbit.net:8332 -u xxxxxxxxxxxx -p xxxxxx --disable-gpu -S \\.\COM20 -S \\.\COM21 -S \\.\COM22 -S \\.\COM23
Please help!
Thanks
ok, at this stage i eliminate all other possibilites, the problem is CGminer for me,, when i downloaded it from enterpoint, it had 2 files, the twin and shipping, but when try to run it, it says libcurl.DLL is missing, so i downloaded the regular cgminer, and placed all the files inside the enterpoint cgminer, and its working for several minutes, after that, the USB is disappearing completly, with no way but to shutdown the computer in order to see the crairnsmore1 again on the device manager, so the problem is CGMiner! any help i appreciate!
oh, and this is the command i am runing-
cgminer_twintest -o pit.deepbit.net:8332 -u xxxxxxxxxxxx -p xxxxxx --disable-gpu -S \\.\COM20 -S \\.\COM21 -S \\.\COM22 -S \\.\COM23
Please help!
Thanks
most of my first problems were my usb hubs.
i had to "Un-power" mine becouse when they were powered i couldnt plug more than 4 or 5.
I disconected all unused devices to free IRQs ( bluethooth, motherboard COM and LPT ports...) i dont know what was but now things are working better. ( at least i can plug all my boards)
Sometimes usb fails and i have to unplug all of them and then start pluging one by one
ebereon twin_test is working for me. ( more or less)
It's true it isn't too stable. After some time one or some of them stops accepting shares. they seems to be hashing ( according to cgminer) but no shares are acepted. usually the fpga/boards failing are always the same.
I'm begining to think its some kind of overheating (it seems to fail more without Air Condit.) or usb issue ( sometimes usb makes sounds like installing.) when enterpoint implement temperature control and up/down cable we could check it.
Im grouping boards to try to find a pattern.
my 12 boards running before they began to fail
http://img443.imageshack.us/img443/2310/cairnsmore12.jpg
It's true it isn't too stable. After some time one or some of them stops accepting shares. they seems to be hashing ( according to cgminer) but no shares are acepted. usually the fpga/boards failing are always the same.
I'm begining to think its some kind of overheating (it seems to fail more without Air Condit.) or usb issue ( sometimes usb makes sounds like installing.) when enterpoint implement temperature control and up/down cable we could check it.
Im grouping boards to try to find a pattern.
my 12 boards running before they began to fail
http://img443.imageshack.us/img443/2310/cairnsmore12.jpg
Hi
ok, at this stage i eliminate all other possibilites, the problem is CGminer for me,, when i downloaded it from enterpoint, it had 2 files, the twin and shipping, but when try to run it, it says libcurl.DLL is missing, so i downloaded the regular cgminer, and placed all the files inside the enterpoint cgminer, and its working for several minutes, after that, the USB is disappearing completly, with no way but to shutdown the computer in order to see the crairnsmore1 again on the device manager, so the problem is CGMiner! any help i appreciate!
oh, and this is the command i am runing-
cgminer_twintest -o pit.deepbit.net:8332 -u xxxxxxxxxxxx -p xxxxxx --disable-gpu -S \\.\COM20 -S \\.\COM21 -S \\.\COM22 -S \\.\COM23
Please help!
Thanks
ok, at this stage i eliminate all other possibilites, the problem is CGminer for me,, when i downloaded it from enterpoint, it had 2 files, the twin and shipping, but when try to run it, it says libcurl.DLL is missing, so i downloaded the regular cgminer, and placed all the files inside the enterpoint cgminer, and its working for several minutes, after that, the USB is disappearing completly, with no way but to shutdown the computer in order to see the crairnsmore1 again on the device manager, so the problem is CGMiner! any help i appreciate!
oh, and this is the command i am runing-
cgminer_twintest -o pit.deepbit.net:8332 -u xxxxxxxxxxxx -p xxxxxx --disable-gpu -S \\.\COM20 -S \\.\COM21 -S \\.\COM22 -S \\.\COM23
Please help!
Thanks
After some more testing I'm stuck at 79Mh/s with the shipping bitstream.
twin_test don't work in temp or SPI mode. I get ~20 shares really fast, then the unit turn on the orange led and I get no more shares. The red led on the fpga's is still flashing but not hashing.
SPI programming is working without any problems.
twin_test don't work in temp or SPI mode. I get ~20 shares really fast, then the unit turn on the orange led and I get no more shares. The red led on the fpga's is still flashing but not hashing.
SPI programming is working without any problems.
Pricing structure post a standard performance level bitstream is now published on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1.html. I will post here in this thread when the changeover happens.
Anyone who has ordered already remains at the offer price even if delivery is later and is paid for July-September.
The re-order offer remains in place until the end of September. For anyone that doesn't know about it you can order the same amount again July to September as what you have ordered and paid for under the current pre-order offer. This offer is closed now to new orders. Only orders already placed will benefit.
Anyone who has ordered already remains at the offer price even if delivery is later and is paid for July-September.
The re-order offer remains in place until the end of September. For anyone that doesn't know about it you can order the same amount again July to September as what you have ordered and paid for under the current pre-order offer. This offer is closed now to new orders. Only orders already placed will benefit.
I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html .
I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
yohan,
on page 11, of Virtual Box Installation Windows, there still is a space between -I and xc6lx150.bit.
spiccioli
It's sorted and I also changed the bistream filename to be correct as well. Changed font as well to make spaces more obvious.
I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html .
I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
yohan,
on page 11, of Virtual Box Installation Windows, there still is a space between -I and xc6lx150.bit.
spiccioli
I have just put what I think is the simplified instructions for Windows users to flash the Twin build into Cairnsmore1. It's linked on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html .
I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
I have not tested the flow yet of this document so there might be something I missed but I will test it on myself probably in the morning. If anyone using it spots anything let me know and I will update it accordingly.
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.
Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it
I'm sure its just software as well, but since I don't have the full picture I just don't know what else try.
Do I need to resend any of my info to you for that, or are you all set?
Thank you for the awesome customer service Yohan.
You are nearly in Canada if I pulled up the right record. If I am wrong let me know. Hopefully we can get it there for Tuesday.
But let's work out what the problem is. No point being frustrated if we can do something about it. It might be that you have a board that has a real fault. It is very unusual for one of our standard boards to fail in the field having been though one of our tests. I think it's about 2-3 boards in the last 9 years but it's still always a possibility.
We are still at the stage of being bit of rough and ready in terms of documentation, software and bitstreams and we will do our best to get you all past that bit as fast as we can. Hopefully this coming week will see the next major step forward and we will meet at least some of the expectations out there.
I am nearly finshed the document that will hopefully make this simplier for Windows users and that will have dip switch settings. 90% of that will still be useful to you as a Linux user so you could try and follow that. It some be available tonight or early tomorrow. I will have some more dip switch setting pictures that I am doing for that now and I will try and post those here shortly as a short term help.
Yeah, I'm not to far from the Canadian border, so that sounds correct.
Ive tried programing with the exact settings you have listed as well with no Luck maybe I did get the 1 off board. Ive spent a few hours on it this morning and decided to put it aside, I may give it a go later but I don't think its going to change much.
Thank you again for the prompt response.
Doff
Ok before programming the twin bitstream set dip switches as this picture. I would recomend programming the SPI flash as you can do power cycles etc without pain. It's just slow to do.
Once it is verified ok set dip switches like this
Once it is verified ok set dip switches like this
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.
Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it
I'm sure its just software as well, but since I don't have the full picture I just don't know what else try.
Do I need to resend any of my info to you for that, or are you all set?
Thank you for the awesome customer service Yohan.
You are nearly in Canada if I pulled up the right record. If I am wrong let me know. Hopefully we can get it there for Tuesday.
But let's work out what the problem is. No point being frustrated if we can do something about it. It might be that you have a board that has a real fault. It is very unusual for one of our standard boards to fail in the field having been though one of our tests. I think it's about 2-3 boards in the last 9 years but it's still always a possibility.
We are still at the stage of being bit of rough and ready in terms of documentation, software and bitstreams and we will do our best to get you all past that bit as fast as we can. Hopefully this coming week will see the next major step forward and we will meet at least some of the expectations out there.
I am nearly finshed the document that will hopefully make this simplier for Windows users and that will have dip switch settings. 90% of that will still be useful to you as a Linux user so you could try and follow that. It some be available tonight or early tomorrow. I will have some more dip switch setting pictures that I am doing for that now and I will try and post those here shortly as a short term help.
One thing I have noticed Yohan when I program the Twin test my SW 3-4 seem to have the wrong program on them. The reason I say this is because one stays on with a blue/red/amber light on the whole time and the other just has amber/red, no clue what they should be. If I could somehow get the right program on those switches it may save you the trouble of shipping a new unit.
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.
Wow, yes that would be great. I really wasn't angry with the Hardware, I was I guess more just frustrated that everyone else was having some success with the twin bitstream and mine well just doesn't seem to like it
I'm sure its just software as well, but since I don't have the full picture I just don't know what else try.
Do I need to resend any of my info to you for that, or are you all set?
Thank you for the awesome customer service Yohan.
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.
Ok at this point I'm just completely frustrated. I re-flashed the controller update just in case, then tried adding the twin test to SPI a few time, it works just fine. Then I go to mine and it finds one share and dies.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
Only p0 works anyhow, p3 just errors out in Cgminer, so only 1 FPGA is even attempting to hash. Ive tried the switch 6 on and off trick and it does nothing for me unfortunately.
The question is how to I go back to the shipping_test.bit when I try to change it to load it to spi it errors out each time with verify failure.
... I'm guessing this will load the SPI with the twin_flash.bit? So it won't need to be reprogrammed everytime I power off.
Yep! And it's working
ebereon if you get that error where it cuts out after about 14 hours you might look at BFGminer, its a fork of cgminer and in his patch notes a while back it mentioned fixing that error in his build of cgminer. So it may have nothing to do with the cairnsmore programing.
One little tip for people running Linux and programming is that we have found the xc3sprog is more stable running as a VM under the main Linux. There also seems to be a machine speed relationship as well. This all suggests that there might be software timing loops in xc3sprog and that is part of the problems some of you have.
On the Windows side I am about alter/create a set of instructions specifically for loading the SPI Flash with the twin design. These should be available later today. It's not really any new info but hopefuly it's in a better format to follow and maybe less chance to make a mistake.
On the Windows side I am about alter/create a set of instructions specifically for loading the SPI Flash with the twin design. These should be available later today. It's not really any new info but hopefuly it's in a better format to follow and maybe less chance to make a mistake.
Code:
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0xb9c83ffc56e627ff
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
readusb waiting too long for 9 bytes, only 0 read
error Resource temporarily unavailable
terminate called after throwing an instance of 'io_exception'
Hi again it was the USB hub port and/or usb cable, moving the card to a different cable/hub port fixed the problem and I was able to program this cards as well as the other ones.
spiccioli.
So I updated the controller FPGA on board serial n. 8 and it went withouth problems.
Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA.
Less than 3 minutes per FPGA.
spiccioli.
Then I started flashing twin_test.bit into my boards and I've found that outside of virtual box it takes a lot less to flash a FPGA.
Code:
user@t5570:~$ time sudo ./xc3sprog -c cm1 -p 3 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0x390dc1e841c73bf1
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
Verify: Success!
real 2m50.569s
user 0m4.340s
sys 0m10.517s
Less than 3 minutes per FPGA.
spiccioli.
Doing the direct programming of the FPGA is fast but won't stay when you power cycle. Loading ointo the SPI Flash takes longer but is there every time you power up the board.
Yohan,
I'm loading it into the SPI, I'm using -I see my command above, but I'm not doing it from VirtualBox, but from a linux pc using your xc3sprog.
I have a different problem, though, when I try to flash board serial nr. 136, it throws this error:
Code:
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 -Ixc6lx150.bit twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0xb9c83ffc56e627ff
JEDEC: 20 20 0x18 0x00
Found Numonyx Device, Device ID 0x2018
256 bytes/page, 65536 pages = 16777216 bytes total
readusb waiting too long for 9 bytes, only 0 read
error Resource temporarily unavailable
terminate called after throwing an instance of 'io_exception'
for both FPGA0/3.
I can program them without problems if I don't try to flash the SPI memory.
Code:
user@t5570:~$ sudo ./xc3sprog -c cm1 -p 0 twin_test.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 674 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
DNA is 0xb9c83ffc56e627ff
Are there differences from board 136 on? I had no problems with board 8 and 104.
spiccioli
Jump to: