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

Yes could be.. I'll try to contact Enterpoint, maybe they have an idea where, as I have a hot air smd station where I could reflow (part of) the board without big problems, but I dont want to bring "the heat on" now ;-)

Im sure someone else, with a larger vocabilary in english can explain this better.. but here goes. I believe somewhere in the soldering on the board you have a hair fracture. When this happens for gpu's, motherboards or whatever, the diy-procedure is to bake it in an oven at a specific temperature for a given time. Im not going to suggest any temp or time, as this is a subject I really dont have any first hand experience on.

A little update to my board problem..

(The Board did not work at all anymore.. even with a 160MHz bitstream it produced only invalid shares..)

It's working again.. Dont laugh, but i put the board in the fridge, as I've always seen some valid shares, like 2 or 3 valid shares, before only HW errors occured so I always had the feeling it has something todo with temperatures overheating, but when touching the thermalblock or the bottomside of the board it was always handwarm..

Well.. I put it in the fridge, it runs smooth for about an hour with the 160 MHz stream.. I've now installed the 190 MHz bitstream and it is still running in my fridge with 3 degrees C ambient temperature.. As soon as I take it out it produces invalids only within seconds..

As I've mailed Enterpoint for service they replied basically that they have no time for service, it'll take about 12 weeks and I'd have to pay for it too as I've bought the board from a forum member I'll probably take apart the coolers myself and renew the thermal compound. Nice service for such a expensive board..

Very strange problem as temperatures feel totally normal...

oc

Photograph the Dip switches when you think they are in the right state to flash the controller.

I had a very nasty time when Enterpoint shipped me 12 out of a 22 board shipment with V1.4 controller on them and no documentation of the different controller even existing!  That cost me most of a day trying to understand, and then a couple weeks where I was on the road with the odd ones that didn't program sitting idle before I could get back to look at them again.

I think I actually ended up trying random dip switch settings until I found one that worked.

If you don't know what controller you have on the board, try also switch 7 instead of switch 6. If this works, then you have hashvoodoo controller.

I have a problem board also, which I can't flash and does not work from power up only. I have to power up the board, then the controller led illuminates weak red and the fpga leds dont do anything. Then I have to flash the controller via jtag cable and now the board works. If I power down the board I have to do the same process to get it working again.

Greets
Eb

Well, other thoughts. Not necessarily in the order to try them, just a set of more ideas.

a) Ensure the problem board is the only one connected by USB cable and the up/down cable is disconnected.
Also, as always, don't have any mining software running on the machine being used to run the flashing software.

b) Again referring to "Enterpoint board notes - DIP switches", page 8:
Switches:
1 - on - Not in Reset
3 - off - Programming Enabled
4 - on - Master
6 - off - Controller SPI Programming Enable
8 - on - Inbuilt Programmer - (only relevant when flashing the array/four FPGAs)

c) Toggle each of the switches back forth a couple of times. - Sometimes these switch blocks can get somewhat unreliable. I've got a switch on one of my CM1's which sometimes doesn't detect the 'correct' setting. And there has been at least one other person reporting this issue. Ideally, use an ohm meter to prove that each switch position is truly on or off.

d) 1) CM1 powered off. 2) usb cable disconnected. 3) Set the switches as needed. 4) power CM1 on. 5) wait two minutes - until it is *known* the device has 'settled down'. 6) connect usb cable. 7) try spiprog.

d) Prove that there isn't some other yet to be noticed problem inhibiting spiprog usage by flashing the known good board. If you can't flash the good board, you'll not be able to flash the 'bad' one either.

e) Get a compatible JTAG cable and use the xilinx ISE software to directly examine / flash the Controller and four Array FPGAs.

Option (e) is arguably not a sound financial decision. At *today's* mining difficulty level it would take two to three weeks of mining time for the 'restored' CM1 board to recoup the ~ $50 cost of the cable. At this point you might never hit break-even on the cable cost if difficulty rises fast enough. And that's assuming a reflash 'fixes' it. You have every reason to believe the board is mortally wounded.

I bought both of the boards used from a member on here. I know they had the 1.5 controller on them as they were setup using up / down cables.

Testing different switch settings.

3 and 8 off = BSOD
3 and 6 off = Exactly the same issue as before where it sees the board, but won't flash the controller.

Has cgminer, or anything else, 'touched' the ports before you tried spiprog?

Try:
1) reboot the computer
2) don't start any other programs
3) run spiprog again

--

Another thought. How old / what generation is the board?

If you got it after mid-September, it is probably 1.5. Older than that things / versions get iffy.

Find this doc: "Enterpoint board notes - DIP switches"

The switch definitions are not the same on all versions.

Regardless, turn switch 3 of 8 off and try again.
I.e., 1-on, 3-off, 6-off, rest-

-- edit 1

NOTE: That is 3 of 8 of the two switch blocks which are mounted adjacent to each other. With the power and USB connections on your left those switches are 1 through 8 starting with the one closest to you being #1.

This is all in the doc I referenced above.

-- edit 2

Yep, I think page 23 of "Cairnsmore1 Manual – Issue 1.0 20/09/2012" is wrong.
Or at least not universally 'right'. 

Try this pattern on the switches next to the molex power connector:

x
x
    x
x
------
x
    x
x
x

Newest Issue:



Switches set per Enterpoint recommendations SW1 = On,On,On,On / SW6 = On,Off,On,On , board is detected, driver installed, and trying to flash 1.5 controller. Nothing happens.

A board of mine has stopped worked a few days ago as well :/ the thing will just endlessly power cycle. Power up for a minute hash some invalids then turn off then turn on. I also have another board with one fpga producing invalids. I wonder if enterpoints warranty is still valid? I may try makomk's bitstream on them just to see if it makes a difference.

Yes, something along that line.

But I'm pretty sure that one will not work with these boards.

If you search through my postings you'll find where I found one which works for me. (I'm sure you can find one cheaper than I did if you go through eBay.)

However, I do suggest you just try flashing the firmware using your existing USB connection before you go through the hassle and expense of gearing up to use JTAG. (I'm a developer, so I had additional justifications for the tool / toy.)

Enterpoint has given complete instructions on how to update / flash the firmware on the CM1's. Search and ye shall find.

Something along the lines of? http://www.ebay.com/itm/USB-Blaster-Programmer-Cable-For-Mini-Altera-FPGA-CPLD-JTAG-Development-Board-/190789410429?pt=LH_DefaultDomain_0&hash=item2c6bef5e7d


That's how I found out mine stopped working. It wouldn't allow the rig to submit any value shares.

A board of mine stopped working two days ago..

It is now only producing invalid shares.. It was running for months without a problem..

Temperatures seem ok, fan also, maybe some power issue.. All my other boards are running fine, tried a new power source and new usb cable, it only makes 1-2 valid shares, then only invalids.. very odd...

Can only be done with a JTAG cable connection.

-- edit

But you might as well just try re-flashing it anyway, without bothering to check if the current image is corrupted.

Took some time, but I have been working on this again lately. I cleaned the board off to give it another go at getting it to work. This is what it was doing when it decided to go crazy and stop working:



Still using the molex fan adapter I plug the board in and it gets detected as:


When both boards were working COMs 24-27 were what were used to get them mining. Without either board plugged in they are still there. The board is detected by USB and lights up fine, but I can't get CGMiner to detect it to start mining. How would I got about checking the controller firmware and flash storage?

So, you're using Windows it looks like.

Have you looked to see if the OS detects the USB device? (System Properties | Device Manager)

If you don't get that far then the board is dead in the water.

I assume you cleaned up around the fried part to ensure no shorts still exist in that area.

Bottom line, if the OS won't even see it as a USB device, your next step will have to be if it can be recognized on a JTAG cable. If you can get a JTAG connection, from there see if the controller firmware / flash is corrupted or needs to be re-flashed.

I need a little help troubleshooting an issue with one of my CM1 boards. One of the unused fan headers managed to get some moisture on it and burnt out. The middle pin actually burnt through the board and has left that typical black mark everyone who's mined long enough is used to seeing on hardware. When it happened the board was still mining, but reporting 100% hardware errors, and stopped the rig from accepting shares. Resetting CGMiner caused the board not to be recognized, reporting COM errors. When, I plug in the USB cable the power light comes on, but the fan doesn't spin. I tried the fan on all of the remaining headers, but they don't work either. Instead, I used a molex adapter to get the fan to turn on and set switch 2 to off:



That still reports COM errors with CGMiner and it won't pickup the board. If anyone has any other ideas on things I could test let me know. Any help would be greatly appreciated.

A ha! So you have something going on, consider the pressure to be on

For the moment we not releasing what we have. This is a background project for us and our time is mainly being spent elsewhere. Basically we don't want any pressure of releasing, building, shipping and supporting a product at this time. I think we will continue that way for a while with Goliath going into test at a pace that suits us.

Thanks Yohan.

Any decisions yet regarding whether you guys plan to venture into an ASIC miner?
I live about 8 miles from Malvern so would prefer to buy from someone in the UK.