The Chili – 30+GH/s BFL based Bitcoin Miner Assembly - page 27.

Spieder

member

Activity: 66

Merit: 10

Quote from: Hands on December 21, 2013, 08:45:32 AM

Silly question on thermal pads..

1 40mm solid thermal pad to cover all 8 chips

OR

8 small thermal pads (one for each chip)?

Does anyone have any opinions?

I've done both, no difference either way. I always add a dab of grease between the pad and heatsink if I use a pad. For most boards the pad wasn't necessary though.

Spieder

member

Activity: 66

Merit: 10

Quote from: i3luefire on December 20, 2013, 10:39:57 PM

Quote from: MrTeal on December 20, 2013, 09:40:09 PM

Quote from: i3luefire on December 20, 2013, 09:32:32 PM

i may just try and replace the ftdi chip

Before doing that, try shorting the center two pins on the unpopulated 0.1" connector labeled PROG. Pin 5 is MCU reset and pin 6 is ground, so it will hold the microcontroller in reset. If it's an MCU issue holding it in reset should cause the device to pop up on your computer as the FTDI chip will be able to connect. If it doesn't show up, it likely is the FTDI.

It still shows as an unrecognized device with the MCU held in reset. So it is probably the ftdi chip then.

Have you tried plugging it into a different computer or loading the windrivers? I had this problem with one of my pc's, the units would randomly drop out of device manager and list unknown device. It turned out to be an issue with the usb hub and maybe funky with the win 8 install. After replacing hub and reformatting the problem went away.

Hands

member

Activity: 67

Merit: 10

Silly question on thermal pads..

1 40mm solid thermal pad to cover all 8 chips

OR

8 small thermal pads (one for each chip)?

Does anyone have any opinions?

asjfdlksfd

full member

Activity: 128

Merit: 100

Hi,

I want to ask for that bfgminer can read and shows processor (chip) like stats from each board for Jally, Little Single.

Is it possible to read all the stats to each chip?
Is it possible to read the status of each chip (how many engines, temp, freq?)
Is it possible to disable seperate chips e.g. for debugging or disabling?
Is it possible to limit/set frequency, voltage of each chip(s) for tuning?
Is there a list/description of all commands for the board?
I remember about I'd more questions, but can't remember which :-)

My problems at the moment is decribed here:

Code:

ST:14 F:3 NB:720 AS:0 BW:[ 63/ 67 B/s] E:264.26 I: 1.29mBTC/hr BS:76.7M
3 69.0C | 76.91/76.95/72.88Gh/s | A:167238 R:1036+213(.72%) HW:274615/4.9%
--------------------------------------------------------------------------------
BFL 0 : 69.0C | 19.43/19.35/18.83Gh/s | A: 43253 R: 288+ 60(.77%) HW: 42887/3.0%
BFL 1 : 44.0C | 28.22/28.24/26.49Gh/s | A: 60839 R: 355+ 83(.69%) HW:117376/5.7%
BFL 2 : 51.0C | 29.35/29.36/27.56Gh/s | A: 63151 R: 393+ 70(.71%) HW:114359/5.3%
--------------------------------------------------------------------------------
BitFORCE SHA256 SC from MrTeal and ChipGeek
Serial: FTWZA0UW
Kernel: bulk queue
Temperatures: 32.0C 51.0C
Voltages: 3.290 / 1.160 / 12.015

The ambient temperature is between 6 and 8 °C. BFL0 has a poor heatsink connected,
but BFL1 should have enough space to get a higher rate. It looks like only that the initialization has to disabled to much enignes, but the frequency looks like increased more and more over the time to th 26,49 effective GH/s.

Code:

[2013-12-21 12:26:12] Acquired exclusive advisory lock on /dev/ttyUSB1
[2013-12-21 12:26:12] BFL: Attempting to open /dev/ttyUSB1
[2013-12-21 12:26:12] Found BitForce device on /dev/ttyUSB1
[2013-12-21 12:26:12] DEVICE: Chili SC
[2013-12-21 12:26:12] MANUFACTURER: MrTeal and ChipGeek
[2013-12-21 12:26:12] FIRMWARE: 1.2.14e
[2013-12-21 12:26:12] CHIP PARALLELIZATION: NO
[2013-12-21 12:26:12] QUEUE DEPTH:40
[2013-12-21 12:26:12] PROCESSOR 0: 15 engines @ 181 MHz -- MAP: EFFF
[2013-12-21 12:26:12] PROCESSOR 1: 16 engines @ 185 MHz -- MAP: FFFF
[2013-12-21 12:26:12] PROCESSOR 2: 12 engines @ 143 MHz -- MAP: 87FF
[2013-12-21 12:26:12] PROCESSOR 3: 10 engines @ 132 MHz -- MAP: F0F9
[2013-12-21 12:26:12] PROCESSOR 4: 14 engines @ 147 MHz -- MAP: FBFD
[2013-12-21 12:26:12] PROCESSOR 5: 10 engines @ 135 MHz -- MAP: 86BF
[2013-12-21 12:26:12] PROCESSOR 6: 11 engines @ 136 MHz -- MAP: F8DE
[2013-12-21 12:26:12] PROCESSOR 7: 16 engines @ 153 MHz -- MAP: FFFF
[2013-12-21 12:26:12] THEORETICAL MAX: 16.05 GH/s
[2013-12-21 12:26:12] ENGINES: 104
[2013-12-21 12:26:12] FREQUENCY: 154 MHz
[2013-12-21 12:26:12] CRITICAL TEMPERATURE: 0
[2013-12-21 12:26:12] TOTAL THERMAL CYCLES: 0
[2013-12-21 12:26:12] XLINK MODE: MASTER
[2013-12-21 12:26:12] XLINK PRESENT: NO
[2013-12-21 12:26:12] Devices detected:
[2013-12-21 12:26:12] BitFORCE SHA256 SC by MrTeal and ChipGeek (driver=bitforce_queue; procs=1; serial=FTWZA38H; path=/dev/ttyUSB1)
1

Here the initialisation stat from the BFL2 which have higher frequencies but less engines enabled.

Code:

[2013-12-21 12:28:05] Acquired exclusive advisory lock on /dev/ttyUSB0
[2013-12-21 12:28:05] BFL: Attempting to open /dev/ttyUSB0
[2013-12-21 12:28:05] Found BitForce device on /dev/ttyUSB0
[2013-12-21 12:28:05] DEVICE: Chili SC
[2013-12-21 12:28:05] MANUFACTURER: MrTeal and ChipGeek
[2013-12-21 12:28:05] FIRMWARE: 1.2.14e
[2013-12-21 12:28:05] CHIP PARALLELIZATION: NO
[2013-12-21 12:28:05] QUEUE DEPTH:40
[2013-12-21 12:28:05] PROCESSOR 0: 16 engines @ 313 MHz -- MAP: FFFF
[2013-12-21 12:28:05] PROCESSOR 1: 7 engines @ 311 MHz -- MAP: F00B
[2013-12-21 12:28:05] PROCESSOR 2: 12 engines @ 330 MHz -- MAP: FFF0
[2013-12-21 12:28:05] PROCESSOR 3: 9 engines @ 323 MHz -- MAP: 2FB2
[2013-12-21 12:28:05] PROCESSOR 4: 10 engines @ 318 MHz -- MAP: 85FB
[2013-12-21 12:28:05] PROCESSOR 5: 15 engines @ 337 MHz -- MAP: FFF7
[2013-12-21 12:28:05] PROCESSOR 6: 8 engines @ 306 MHz -- MAP: 0FF0
[2013-12-21 12:28:05] PROCESSOR 7: 16 engines @ 336 MHz -- MAP: FFFF
[2013-12-21 12:28:05] THEORETICAL MAX: 30.11 GH/s
[2013-12-21 12:28:05] ENGINES: 93
[2013-12-21 12:28:05] FREQUENCY: 323 MHz
[2013-12-21 12:28:05] CRITICAL TEMPERATURE: 0
[2013-12-21 12:28:05] TOTAL THERMAL CYCLES: 0
[2013-12-21 12:28:05] XLINK MODE: MASTER
[2013-12-21 12:28:05] XLINK PRESENT: NO
[2013-12-21 12:28:05] Devices detected:
[2013-12-21 12:28:05] BitFORCE SHA256 SC by MrTeal and ChipGeek (driver=bitforce_queue; procs=1; serial=FTWZA0UW; path=/dev/ttyUSB0)
1 devices listed

And for additional information here the one from the poor heatsink connection:

Code:

[2013-12-21 12:30:28] Acquired exclusive advisory lock on /dev/ttyUSB2
[2013-12-21 12:30:28] BFL: Attempting to open /dev/ttyUSB2
[2013-12-21 12:30:28] Found BitForce device on /dev/ttyUSB2
[2013-12-21 12:30:28] DEVICE: Chili SC
[2013-12-21 12:30:28] MANUFACTURER: MrTeal and ChipGeek
[2013-12-21 12:30:28] FIRMWARE: 1.2.14e
[2013-12-21 12:30:28] CHIP PARALLELIZATION: NO
[2013-12-21 12:30:28] QUEUE DEPTH:40
[2013-12-21 12:30:28] PROCESSOR 0: 11 engines @ 219 MHz -- MAP: FEB2
[2013-12-21 12:30:28] PROCESSOR 1: 8 engines @ 326 MHz -- MAP: 0FF0
[2013-12-21 12:30:28] PROCESSOR 2: 16 engines @ 164 MHz -- MAP: FFFF
[2013-12-21 12:30:28] PROCESSOR 3: 11 engines @ 327 MHz -- MAP: 07FF
[2013-12-21 12:30:28] PROCESSOR 4: 15 engines @ 155 MHz -- MAP: BFFF
[2013-12-21 12:30:28] PROCESSOR 5: 9 engines @ 276 MHz -- MAP: 40FF
[2013-12-21 12:30:28] PROCESSOR 6: 9 engines @ 265 MHz -- MAP: 40FF
[2013-12-21 12:30:28] PROCESSOR 7: 15 engines @ 143 MHz -- MAP: FFEF
[2013-12-21 12:30:28] THEORETICAL MAX: 20.57 GH/s
[2013-12-21 12:30:28] ENGINES: 94
[2013-12-21 12:30:28] FREQUENCY: 218 MHz
[2013-12-21 12:30:28] CRITICAL TEMPERATURE: 0
[2013-12-21 12:30:28] TOTAL THERMAL CYCLES: 0
[2013-12-21 12:30:28] XLINK MODE: MASTER
[2013-12-21 12:30:28] XLINK PRESENT: NO
[2013-12-21 12:30:28] Devices detected:
[2013-12-21 12:30:28] BitFORCE SHA256 SC by MrTeal and ChipGeek (driver=bitforce_queue; procs=1; serial=FTWZA0XN; path=/dev/ttyUSB2)
1 devices listed

Comments are welcome.

Cheers...

twib2

sr. member

Activity: 280

Merit: 250

Helperizer

Quote from: ChipGeek on October 25, 2013, 08:15:52 AM

When a board first starts up, the firmware makes sure the board and chips are cooled down before it starts the self test. This helps ensure the maximum number of engines (cores) will pass self test.

LED decoder ring

The LEDs are numbered 1 to 8 with #1 closest to the USB connector and #8 closest to the power and fan connectors. During first power up, LEDs 5, 6, 7, and 8 will light up and LEDs 1, 2, 3, and 4 will indicate a failure code if anything is wrong with the hardware. This happens VERY quickly - in less than a second.

If the initial hardware checks are good, #7 will blink indicating it is waiting for the board to cool down. This will always blink for a few seconds even if the board is cold.

Then #7 and #8 will blink indicating ASIC self test.

After that, 1, 2, 3, 4 will indicate how many jobs from cgminer are waiting to run in the input queue. LED 5 is just a debug output for me but it roughly indicates a job has completed - but sometimes blinks too fast for the human eye to see. Just ignore LED 5.

I am working on some firmware updates that will fix most (or all?) of the problems the boards are having. For example, one failure I think I have figured out is occasionally a board will jump to more than 100 GH/s but have 100% hardware errors. I have one board that does this once per day or so and needs to be rebooted. After chasing this for a while, I believe I have finally figured out what is going on and will have a fix in the next release.

My new Chili has been hashing well for a few days now, and I fairly often stop bfgminer and restart it with a different coin. However, just recently, it's gotten stuck in the startup process - #7 is blinking and it never gets farther than that. I've reseated the cooling solution 212EVO and even tried my H60 to no avail. I've reflashed the firmware 14e again to no avail. If I go ahead and try to use it after waiting "forever" of course bfgminer finds it just fine, but it's doing no hashing: 0 GH/s.

The weird thing is that nothing changed. Without me even being near it (ssh'd from upstairs to the miner computer), one time when I was switching coins it starting giving 0 GH/s. So I went downstairs to check on it. Rebooted the computer, and it, and all sorts of combinations, but nothing.

EDIT: Of course after I posted this, it decided to start working again. Not sure why, unless one of my many automatic resets of the USB bus slapped it around enough to realize that it was indeed cool enough. It's running below 70C now and hashing at 35GH/s with the cheap refurbished Corsair H60 on it - sweet!

Sorry for the "false" alarm, but I'm leaving it here in case a) someone might also benefit from knowing that they can wake up again on their own, or b) someone can help us avoid this altogether.

Cheers,
- Tye

i3luefire

member

Activity: 86

Merit: 10

Quote from: MrTeal on December 20, 2013, 09:40:09 PM

Quote from: i3luefire on December 20, 2013, 09:32:32 PM

i may just try and replace the ftdi chip

Before doing that, try shorting the center two pins on the unpopulated 0.1" connector labeled PROG. Pin 5 is MCU reset and pin 6 is ground, so it will hold the microcontroller in reset. If it's an MCU issue holding it in reset should cause the device to pop up on your computer as the FTDI chip will be able to connect. If it doesn't show up, it likely is the FTDI.

It still shows as an unrecognized device with the MCU held in reset. So it is probably the ftdi chip then.

MrTeal

legendary

Activity: 1274

Merit: 1004

Quote from: i3luefire on December 20, 2013, 09:32:32 PM

i may just try and replace the ftdi chip

Before doing that, try shorting the center two pins on the unpopulated 0.1" connector labeled PROG. Pin 5 is MCU reset and pin 6 is ground, so it will hold the microcontroller in reset. If it's an MCU issue holding it in reset should cause the device to pop up on your computer as the FTDI chip will be able to connect. If it doesn't show up, it likely is the FTDI.

i3luefire

member

Activity: 86

Merit: 10

i may just try and replace the ftdi chip

MrZambonie

newbie

Activity: 13

Merit: 0

I have one that goes all crazy on me once and awhile, I just reflash it and seems to correct the issue. Have you tried that yet?

Quote from: MrTeal on September 28, 2013, 04:51:36 PM

Current Firmware: https://www.dropbox.com/s/zoewijezzhfl3bs/Chili14e.hex
Flash Utility: https://www.dropbox.com/s/xpccbhfkbpinov8/ChiliFlash.exe
Utility Source: https://www.dropbox.com/s/zn8gkojly2f87wx/ChiliFlash.rar

Previous FW
https://www.dropbox.com/s/8qhhoqmvtk6i6jj/Chili14d.hex

i3luefire

member

Activity: 86

Merit: 10

Quote from: Bargraphics on December 20, 2013, 08:49:00 AM

Quote from: i3luefire on December 20, 2013, 12:30:58 AM

i have 14 chilis and 10 of them have been running for weeks and weeks without problems. the other 4 are new. 1 of the new ones runs fine for about 1-2 minutes then starts showing an error messages then it goes sick. in the midst of starting and stopping bfgminer a million times while trying to get that one working 1 of the 10 that had been running fine stopped working and now it never shows up in bfgminer even after power cycling it and switching usb ports and switching power supplies.

What do the LED lights on the chili that has the issue look like.

Remember when you power cycle, etc.. you should wait until all of the LED lights on the chili stop blinking before starting the mining software. This can cause it to hang and not be found.

What error messages are you seeing with your other chili? Have you tried switching it to a different USB port/running it solo to see if it continues with those same issues?

Hopefully we can help you out!

the one that never shows up in bfgminer goes through the normal led bootup sequence but after the leds go out and i start bfgminer nothing happens. i have not tried that one by itself yet but i did change usb ports and cables. i am trying the one that goes sick by itself right now and am waiting on it to fail to copy the error message. but it always runs at ~41-42gh with 10-15% hw.

Edit: the message is

Code:

BFL 0: Received unexpected queue result response:
BFL 0: Error: Get temp returned empty string/timed out

Edit2: the miner that does not get recognized by bfgminer shows up as an unknown device on windows. does that mean the ftdi chip is toast? because i have never had this problem before. my normal mining machine is xubuntu but i have mined with these on windows before. and i am currently mining with the other problem child on windows currently so i dont think it is a driver issue. also the one that was getting sick before has not gotten sick for over an hour. so... i am not sure what the problem was there. but eventually i will need to move it back to the mining room and out of my living room.

Bargraphics

hero member

Activity: 518

Merit: 500

Every man is guilty of all the good he did not do.

Quote from: i3luefire on December 20, 2013, 12:30:58 AM

i have 14 chilis and 10 of them have been running for weeks and weeks without problems. the other 4 are new. 1 of the new ones runs fine for about 1-2 minutes then starts showing an error messages then it goes sick. in the midst of starting and stopping bfgminer a million times while trying to get that one working 1 of the 10 that had been running fine stopped working and now it never shows up in bfgminer even after power cycling it and switching usb ports and switching power supplies.

What do the LED lights on the chili that has the issue look like.

Remember when you power cycle, etc.. you should wait until all of the LED lights on the chili stop blinking before starting the mining software. This can cause it to hang and not be found.

What error messages are you seeing with your other chili? Have you tried switching it to a different USB port/running it solo to see if it continues with those same issues?

Hopefully we can help you out!

i3luefire

member

Activity: 86

Merit: 10

i have 14 chilis and 10 of them have been running for weeks and weeks without problems. the other 4 are new. 1 of the new ones runs fine for about 1-2 minutes then starts showing an error messages then it goes sick. in the midst of starting and stopping bfgminer a million times while trying to get that one working 1 of the 10 that had been running fine stopped working and now it never shows up in bfgminer even after power cycling it and switching usb ports and switching power supplies.

nexus99

legendary

Activity: 910

Merit: 1000

I'll look to see if there is a way I can set that in BFG.

Found this:

--temp-cutoff Temperature where a device will be automatically disabled, one value or comma separated list (default: 95)
--temp-hysteresis Set how much the temperature can fluctuate outside limits when automanaging speeds (default: 3)
--temp-overheat Overheat temperature when automatically managing fan and GPU speeds, one value or comma separated list (default: 85)
--temp-target Target temperature when automatically managing fan and clock speeds, one value or comma separated list

Maybe Ill try 130 and see what happens.

MrTeal

legendary

Activity: 1274

Merit: 1004

Quote from: nexus99 on December 19, 2013, 09:35:33 PM

Hi all - i have 1 Chili that just stumps me.

The behavior it exhibits is that it runs fine at about 60c for a while. Then it instantly jumps to 120c and is shut off by BFG miner. It then immediately drops back down to 60c and spins its GH/S back up. It will randomly and continually repeat the cycle. I have attached several different coolers that work on other chilis... but I get the same behavior. Is this a problem with the temp sensor? Anyone know a way to avoid the turn off?

I have also tried thermal pads as well as paste. I am fairly confident its not an issue with cooling.

***I just noticed a similar issue posted immediately prior to mine. At least I'm not alone!

That is extremely strange. Can you raise the cutoff in BFGMiner so that it doesn't throttle and allow the Chili to throttle it?

nexus99

legendary

Activity: 910

Merit: 1000

Hi all - i have 1 Chili that just stumps me.

The behavior it exhibits is that it runs fine at about 60c for a while. Then it instantly jumps to 120c and is shut off by BFG miner. It then immediately drops back down to 60c and spins its GH/S back up. It will randomly and continually repeat the cycle. I have attached several different coolers that work on other chilis... but I get the same behavior. Is this a problem with the temp sensor? Anyone know a way to avoid the turn off?

I have also tried thermal pads as well as paste. I am fairly confident its not an issue with cooling.

***I just noticed a similar issue posted immediately prior to mine. At least I'm not alone!

GrapeApe

sr. member

Activity: 476

Merit: 250

Quote from: Bargraphics on December 19, 2013, 02:31:52 PM

Quote from: GrapeApe on December 19, 2013, 02:24:49 PM

I'm having an issue getting one of my chilis built. I am using the CoolerMaster Hyper 212evo cooler with paste vs. pads and the backplate recommended by PhDMiner. Got one built using same parts it works fine but the other one starts to hash, shoots up to 39 GH/s and the temp goes to 70 C and then it shuts down and when the temp gets to 29 C it starts all over again same thing. Have rebuilt it twice should clean off the paste and try pads?

It doesn't actually shut down right? Just keeps saying it on the mining software correct?

This is normal, it keeps throttling until it finally equalizes and is happy. I've had one do it for a couple hours once. Just give it time and it should find the sweet spot!

No, shutdown wasn't the right description disabled would be a better term for it.

I've got a few of these boards and none of them have done this. Why would one act so differently?

I had considered just leaving it running before I posted but wasn't sure if I should or not, will do now and report back.

Thanks

EDIT: I let it do it's thing for a little while and it's now hashing away. Mr.Teal suggested I add cooling to the MOSFETs and that should be finished tonight when the parts arrive. All is well at the moment...

Bargraphics

hero member

Activity: 518

Merit: 500

Every man is guilty of all the good he did not do.

Quote from: GrapeApe on December 19, 2013, 02:24:49 PM

I'm having an issue getting one of my chilis built. I am using the CoolerMaster Hyper 212evo cooler with paste vs. pads and the backplate recommended by PhDMiner. Got one built using same parts it works fine but the other one starts to hash, shoots up to 39 GH/s and the temp goes to 70 C and then it shuts down and when the temp gets to 29 C it starts all over again same thing. Have rebuilt it twice should clean off the paste and try pads?

It doesn't actually shut down right? Just keeps saying it on the mining software correct?

This is normal, it keeps throttling until it finally equalizes and is happy. I've had one do it for a couple hours once. Just give it time and it should find the sweet spot!

GrapeApe

sr. member

Activity: 476

Merit: 250

I'm having an issue getting one of my chilis built. I am using the CoolerMaster Hyper 212evo cooler with paste vs. pads and the backplate recommended by PhDMiner. Got one built using same parts it works fine but the other one starts to hash, shoots up to 39 GH/s and the temp goes to 70 C and then it shuts down and when the temp gets to 29 C it starts all over again same thing. Have rebuilt it twice should clean off the paste and try pads?

Bargraphics

hero member

Activity: 518

Merit: 500

Every man is guilty of all the good he did not do.

Just thought I would post this here.

My BFGMiner has been running for a little over 16 Days straight without any issues on the chilis. Once you get these things running, if you don't touch them they seem to have no issues at all.

Great! Product MrTeal/ChipGeek

ipxtreme

sr. member

Activity: 262

Merit: 250

My 5 chili's at their final resting location:

Topic: The Chili – 30+GH/s BFL based Bitcoin Miner Assembly - page 27. (Read 137904 times)