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

We are starting a Cairnsmore1 specific support email address where we can route problems to the best engineer to be able to sort them out. We will also start a FAQ page in the next few days and try and cover common problems there so hopefully whatever you encounter that there is an answer already waiting for most of you. The support email is bitcoin.support AT enterpoint.co.uk.

Yohan

rampone,
ill run through my process to see if you are doing anything different;
Switch on the unit with SW1 3 off to put in programming mode
Whilst in programming mode, i have yellow/green on all 4 pga (if you switch the SW1 3 off with power applied, the green led doesnt light, but programming still works)
Whilst writing the twin_test programming to -P0 or -P3, the leds next to it change to yellow/blue/red
When programming is complete, the leds change to yellow/blue and the leds on its associated partner (-P1 if programming to -P0 or -P2 if programming to -P3) change to yellow/green/red
I then switch SW1 3 on without removing power inbetween
I then get yellow leds on all pga and red on the -P1/-P2 pgas

So this is the same as you, up to this point

i then disconnect the FTDI Cairnsmore1 from the virtualbox to give it back to windows.
i then switch SW6 1 off to make it 115,200 baud for use with cgminer or mpbm, (if i dont switch it, then cgimner reports the got 00000000 expecting 000187a2 error)

You should then be hashing

It is all too easy to get dip switches wrong. Our slightly longer term aim will be to eliminate most, if not all, dip switch settings and use something a bit more intelligent but more on that when we have it.

Ive just checked with magifying glass and you are right, so my dip settings in my posts should have SW1 and SW6 switched as i have been posting them the wrong way around.

(I have edited my posts to correct my mistake now, i believe ebereon has thought they were the the same way around as i did based on his posts, so perhaps we all confused each other here is a magnified image for clarity -

Okay, tried with the programming option, a green light show up, when finished programming, blue lights up (yellow stays lit). Now it also seems to be programmable on the first run.

After switching back to"run mode", everything lights as before (0,1,2,3 yellow, 1,2 red) but it wont hash. Probably the clock icarus stuff yohan was talking about.

(btw, sw1 are the dips near the usb, sw6 are the one to the green connector at my board? so programming for me is all on, ans sw1 3 off?, running all on and sw6 1 off? Did the labeling change on the board? I doubt it

The way i got mine going is as follows;

Setup dips as follows;

This is as per progamming operation from virtual box, but ignoring the SW6 3 off, once i had updated the firmware to rev 1.1 SW1 3 on works!)


I program each twin_test.bit to -P0 and -P3

PGA's 0 and 3 will have amber led on, 1 and 2 will have amber and red

Then disconnect the Cairsmore1 device from the Virtual Box instance (click "Devices" menu, then "USB Devices" then untick the "FTDI Cairnsmore1")

I then reset the dips as follows (whilst the device is still on) (if you are using the enterpoint provided cgminer, leave SW6 1 on, or if you set mpbm to 57600 leave it on also, else switch SW6 1 off to make the baud rate 115200 to use the standard cgminer in icarus mode or 115200 in mpbm, the red led next to the array will flash faster when SW6 1 is on)


you should then be able to mine using \\.\COM22 and \\.\COM23

Ok after further fiddling it looks as if the programming has not been working and that Ive been resetting it each time back to the shipping.test. As far as feedback goes, if you could go in to more detail on what as successful program looks like and what the lights should be doing when it was successful.

Noob question here but could I in theory develop a bitstream on the side and use the programming chip on the board to send it to the various FPGAs? I ask as I love tinkering with things and I think I'd have fun getting one of these to hash away at something pathetic like 1 MH/s 

Isn't the Icarus bitstream based on Ztex source? Is there any reason to use Icarus-specific stuff?

doff: did everything, that was posted here in the thread, and tried other settings myself, only loading the bitstream permanently i did not do, but that should not change anything, as others worked in "temporary mode".

I am already in waiting mode again

Ramp did your try this from daemonic a few posts back? Although with that programmed im still getting crap all for hash rate, im just happy it does something at all haha

To program, I had;

SW1 all on
SW6 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on
(as per progamming operation from virtual box, but ignoring the SW6 3 off)

then to use standard cgminer, i switched SW1 1 off;

SW1 1 off, 234 on
SW6 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on
(as per normal operation)

(this is for twin_test.bit)

Ok I actually got it to program as per the instructions this time, and noticed you have to flip the switches and wait for the lights to go amber in normal operation. Still hashing at like 25-50mh though with the twin.bit.

Hopefully it will get better as we get more time on the tools and documentation. I'm hoping to have the Linux version for the controller updater tomorrow but can't promise that given the way development sometimes goes.

After we get this sorted we would like to an idea of who isn't on the latest firmware. Whilst I anticipate this being updated again once or maybe more it's going to be our standard working level for 1or 2 weeks whilst we will then be concentrating more on improving the bitstream side. The twin build is an Icarus derivative so does have the twin clock weakness so it is possible that is causing the dropouts one or two of you are seeing. I would like to get a more formal feedback from you once we have a bitstream build that we are much happier about in terms of stability. The current "twin FPGA" running is very much a temporary bitstream as far as we are concerned.

Once we have a better bitstream (almost certainly not the final one but reasonable) we will look to bring in the up/down functionality and that will definately be a controller update again.

Yohan

kay, at least I do not feel that alone  

Okay. XC3 update went well, I think the red led flashes faster now.

Again I tried to temporarily load the faster test bitstream, it seems to load right (0 and 3 are yellow, 1 and 2 are yellow and red).

And still the problem that it wont hash. Reinstalled drivers and hooke up to a second computer. Same Same. It seems to get the work as the #0 and #3 flash red, also yellow switches off for a 100th second. and then it does nothing...
dip switches ae right and also tested different options.

Am I the only one left behind right now, with loaded faster bitstream and no work/hashing done? Or does my board have a defect/HFrequency/Voltage Problem, as the slower bitstream works and the faster does not? Is it the condensators beeing on the side of the fpga and not on the bottom, so flipflopping the gates hard inside the fpga ripples the voltage? Cant be that problematic if they are on the side? Is it the hair under the solder resist on my board? It crosses the connection from xc3 to sp6#2... that would be really strange if it the hair messes it up.

I dunno, and my testing knowledge is over. anyone further ideas?


I guess I will contact enterpoint directly tomorrow and ask them. I know its still early stage, but strange that it seems to run on mostly other boards. (someone had only 1 fpga hashing faster on one board (the 3 out of 8 guy).

Oh well again back to 100Mh/s (I did not load the bitstream in to flash permanently yet, want to easily fallback to "minhash")

Yes, thats the only one I can seem to get to work. Any other configuration gets me a cannot mine all devices disabled in cgminer.

I am only able to get about 50mh with the twintest.bit file in normal cgminer. Mine seems to program without a hitch at least so thats good, but im not at the 380 yet.

Having fun playing with all this stuff though.

After the controller update, that what the pdf say's.

But the whole unit is buggy...

Sometimes it's working only with 100Mh and lower, sometimes ~280Mh/s. The orange led's show much often when the unit is working longer then 2 hours.

aye, my other thought.

The only other thing I can think of is that it is a 32-bit app in a 64-bit environment. Normally, that isn't a problem, but certain folders are treated differently - specifically System32 and Program Files. Both of those are for 64-bit apps only, and SysWOW64 and Program Files (x86) exist for 32-bit apps.

In other words, try moving both files to either the Desktop or the C:\ root and try again.

This is likely not to work and may sound silly. But try typing in the complete path and filename for the .bit file.  i.e.,  SPIProg c:\windows\system32\spiprog\spi.bit

I have not started messing with this yet. Are you running it in the virtual box environment or just from windows?