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

negotiable?

Was this Thursday the 18th or 25th?

nevermind, ive got around it myself, using http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html

Anyone have any joy getting the CM1 working in Windows 8?

This is the problem im having;

Anyone got one they wanna give to me?
I'll pay the postage with BTC

It's approaching getting a bit late to bother adding full support to cgminer for the CM1 since it does already work pretty well with changes I made a long while back now with the Icarus bitstream code (and I do wonder if I even have time to get much done before ASIC's start arriving at my door) but anyway, anyone got a spare?
I guess between now and 'then' I may get a chance to do it if I had a CM1.
(however, 'then' isn't 'that' far away)

I am selling mine at 400$ usd, if anyone is interested plz contact me

Someone still looking for a CM1? I'm selling mine for 500€ (@ 800 MH/s, <0.5% invalids)

I don't know if that helps, but i had problems with UP/DOWN too.

Make sure the Master boards turn up first and then the Slave ones. This way it worked for me. I think it has to do with the controller, not PSU, because without UP/DOWN everything works fine with my 680Watt PSU's.

eb

Cheers Glasswalker...appreciate the efforts

Did that, nothing changes. 1-2 boards still failing.

Looks like my PSU can only start 4 boards without any errors. That's strange... If I add 2 boards more, one will fail. I'm using PDB with OCZ ZT 750W PSU
If fails master board, it's slave still works.

During startup there are surges mainly due to the capacitors on the 12V and rails that come up more or less immediately. We have limited these surges by the way we turn on the main power supplies and that is the reasoning for the phased turn on that you will see on the board. That goes a long way to limiting surges. We don't know what the surge current peaks at as it changes dynamically as the boards power up and the highest current peak is extremely short duratiion and very hard to measure.

What do think is sometimes a problem is the rate at which the 12V rises from 0V to normal range. This rise rate depends on the number of CM1 boards in the rig and the power supply being used so it is different for more or less every rig. If is too slow then one of 2 things can happen. The first is that the Controller FPGA fails to configure. The second is that we think that the USB doesn't come out of reset correctly. To see if this is your issue try powering up with only some of your rig say half initially on the power supply. If these all come up ok repeat gradually adding boards to find where issues start to occur. If this does prove to be the root of your problems there are a couple of ways to proceed. The first argueably wasteful way is to either split your power supply into 2 power supplies or just use a bigger supply that might give a better ramp time. More crudely and needs care is to live plug in the power supply of the last few boards and after bringing up whatever of the stack will come up happily with the power supply.

Ok, didn't try exactly that yet, but I always wait some time before testing. USB on host enumerated, correct and presented. I can do a request using kano's python script. I can see during request flashing lights on pair of FPGA's (so they handling incoming request?), I can see even green light on one of them (got nonce?), but no response on host after timeout (70%) or wrong response (30%).
Boards failing after complete reset, when no power at all, even no usb powert to them. Tried starting boards then host, host then boards - no changes. With or without usb connected. Controller red light blinking pretty fast all time when PSU turned on and power cables connected.
So, for now, to resolve this issue, I power down slave, than master. Then power up slave/master or master/slave doesn'y matter.
Usually failing 1-3 boards out of 12, usually different.

Also, I received my boards with controller 1.5, but 6 of 12 didn't work in master/slave - FPGA-s LEDs was red after board boots. So, I flashed controller, it seems to be resolved for now.

Hmmm... How much power each board requires during start process? Have not measure voltage output on PSU during start.

Unfortunately I'm in France on travel for my day job. And I had hoped to have much development time, but unfortunately that hasn't panned out. I've been extremely busy with no time but for work/eat/sleep. Hell this is the first time I've been online in days... I don't even know what's going on as far as recent developments are concerned.

I'm returning to Canada on Thursday, and I'll do my best to dedicate some time to getting some significant bitstream progress made then.

Sorry for the delays everyone. I'm well aware that each day is ticking closer to ROI problems. I'm doing my best to make time. (I have a cluster running myself now, and I need to get ROI on them too, so I feel you pain).

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

After cold start of 12 boards, some of them wan't start mining. Cgminer responds with a 'invalid blah-blah' and doesn't mine on them. Kano's python usb tester responds with empty values after some timeout or invalid response. I'm using master/slave config with up/down cable. So, from this 12 boards I have, random number wan't start. It might be slave or master, does not matter. During request their leds flashs normally, as expected. Yellow off, then green on and fading down. Then yellow again.
After power cycle failed biard and its master/slave board, it might work in about 80%. If not, I just power do cycle again.
Tried to change usb hub, usb cables, miner..

Looks like controller issue? v1.5. Any suggestions?

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

2.8.1 only worked with fixed-frequency bitstreams, not the new dynamic-frequency ones, FYI.

@Doff
It's standard version of Bfgminer 2.8.1

@Luke-Jr
OK. I'm testing the Cairnsmore1 on my another Linux PC. Will know this problem still occur or not soon.


#EDIT: Seems it's computer problem. Didn't get the same error on another PC at present.

Could you make a debug.log file with this failure and upload it somewhere? Add to the end of your bfgminer command: --debuglog 2>debug.log

Is this the dynclock version of Bfgminer, the one Luke-Jr has been working on with the clock settings for the new bitstream?  If it is, setting the clocks to start at 175 fixed that problem for me. if its an older version using makomk bitstream I don't know the answer.