I have an odd card and was wondering on some feedback on it.
The card takes a VERY long time to self test (2 or 3 minutes, where as the other cards take 10 or 20 seconds)... Also the card will lock up.. And lastly, I just bounded the card and it tested then went to LEDs 5,6,7,8 all being on.. I rebooted it and then it made it thru the self-test ok.
The card seems to hash for about 20 minutes before failing out.
I am using cgminer 3.8.5 compiles for the raspberry pi (this morning), What additional information would be useful for debugging this card?
EDIT : I just watched the card.. It ran for about 2 minutes, then said ZOMBIE and now its at 33c, 0.85v and zero hash.
Thanks
Topic: The Chili – 30+GH/s BFL based Bitcoin Miner Assembly - page 26. (Read 137986 times)
Mr teal you make any new firmware for chilli??
I don't think I even know how to answer that. 
Mr teal you make any new firmware for chilli??
The file you emailed to me seems to have made the problem much better. the miner got sick once since the upload but that may have been pc related. is the file you uploaded "https://www.dropbox.com/s/i4rj2k1m9vrj00e/Chili14e1V1.hex" the same as the one you emailed?
Also i tried the FT_Prog utility http://www.ftdichip.com/Support/Utilities/FT_Prog_v2.8.2.0.zip and it was not able to find that miners usb chip either so i am going to order a replacement for the ftdi chip today or tomorrow from digikey or mouser. which part number is the correct one "FT232HL" or something else?
It is, I just renamed it to avoid confusion when I posted it here. Also i tried the FT_Prog utility http://www.ftdichip.com/Support/Utilities/FT_Prog_v2.8.2.0.zip and it was not able to find that miners usb chip either so i am going to order a replacement for the ftdi chip today or tomorrow from digikey or mouser. which part number is the correct one "FT232HL" or something else?
That's the correct part number.
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!
Edit: the message is
Code:
BFL 0: Received unexpected queue result response:
BFL 0: Error: Get temp returned empty string/timed out
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.
I'll email you the file I used.
Ok I performed the test and it still came up as an unrecognized device. So that means it is the ftdi chip correct? And if so what is the mfg part number?
It sounds like it. You could try opening it up in FTDI's FT Prog utility to see if it's detected there as well.Also i tried the FT_Prog utility http://www.ftdichip.com/Support/Utilities/FT_Prog_v2.8.2.0.zip and it was not able to find that miners usb chip either so i am going to order a replacement for the ftdi chip today or tomorrow from digikey or mouser. which part number is the correct one "FT232HL" or something else?
I was trying BFG miner and all it does is crash with an error about locating the com "FT_GetComPortNumber" I can get the Chili's to hash great (well low to mid 30's) in cgminer..
I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm). but all I get is instant crash.
Any ideas?
Win 8.1 64bit, BFG Miner 64bit 3.8.1 and I tried 3.8.0
I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm). but all I get is instant crash.
Any ideas?
Win 8.1 64bit, BFG Miner 64bit 3.8.1 and I tried 3.8.0
I have never been able to get anything to hash on win8x64
win7x86 works all the time with all my gadgets.
I'm having similar issues as well. The 2 I got from batch 3 auction will reset constantly. The voltage gets up to 1.16 and then they disable themselves. If by chance the voltage stays below 1.16 all is well but it's a crap shoot. I have heat sinks on the MOSFETs.
EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.
As of right now there isn't an option to limit voltage. Below is a version of 14e compiled to limit the voltage to 1.1V instead of 1.15V. Give that a try.EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.
https://www.dropbox.com/s/i4rj2k1m9vrj00e/Chili14e1V1.hex
Over the break for the next couple weeks I plan to get some changes to the firmware done to allow limits to be imposed on different variables like frequency setpoint and voltage through command extensions.
BTW- Not super useful for most people since you can't use it while hashing since the mining software has the port open, but the ZlX command (lowercase "L") will return the temperature of all the chips. If you're compiling your own cgminer, you might want to add in a way to read that.
This is a Linux house no windows here. Is there a way to flash the firmware using Ubuntu?
Edit: Had to partition a space on the drive and install xp (aaarrggg) got them flashed and took a small hit on the hash rate but they are running. Thank You
Sorry for asking you to hold my hand Mr.Teal and thanks for uploading the modified firmware. I look forward to being able to tweak these settings myself thanks again.
*snort*
Actually I think part of the spate of recent jally-usb issues is related to BFL pointing the fan *down* for some reason. If you have the sides off it's a good idea, but with them on what happens is that hot air washes over the FTDI232 chip, which is the fastest way (aside from a massive ground fault) to kill the chip.
On a Chili note, I have one of those super big AL sinks and a $50 water cooling block coming on Tuesday with my new board. Would it be better to put the water block on the top or bottom of the board, and can one mount the fan heat sink to the board without a pad (just thermal grease)?
C
Depends on the water block, probably. I have a Water 2.0 Extreme which is just an AseTek unit, and the base from the factory was actually pretty terrible. It was noticeably convex just eyeballing it with a straight edge. I'd put the waterblock on the top though, you're still dissipating most of the heat that way. Unless you find you really need it, I'd just use grease. Actually I think part of the spate of recent jally-usb issues is related to BFL pointing the fan *down* for some reason. If you have the sides off it's a good idea, but with them on what happens is that hot air washes over the FTDI232 chip, which is the fastest way (aside from a massive ground fault) to kill the chip.
On a Chili note, I have one of those super big AL sinks and a $50 water cooling block coming on Tuesday with my new board. Would it be better to put the water block on the top or bottom of the board, and can one mount the fan heat sink to the board without a pad (just thermal grease)?
C
I'm having similar issues as well. The 2 I got from batch 3 auction will reset constantly. The voltage gets up to 1.16 and then they disable themselves. If by chance the voltage stays below 1.16 all is well but it's a crap shoot. I have heat sinks on the MOSFETs.
EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.
As of right now there isn't an option to limit voltage. Below is a version of 14e compiled to limit the voltage to 1.1V instead of 1.15V. Give that a try.EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.
https://www.dropbox.com/s/i4rj2k1m9vrj00e/Chili14e1V1.hex
Over the break for the next couple weeks I plan to get some changes to the firmware done to allow limits to be imposed on different variables like frequency setpoint and voltage through command extensions.
BTW- Not super useful for most people since you can't use it while hashing since the mining software has the port open, but the ZlX command (lowercase "L") will return the temperature of all the chips. If you're compiling your own cgminer, you might want to add in a way to read that.
*snort*
Actually I think part of the spate of recent jally-usb issues is related to BFL pointing the fan *down* for some reason. If you have the sides off it's a good idea, but with them on what happens is that hot air washes over the FTDI232 chip, which is the fastest way (aside from a massive ground fault) to kill the chip.
On a Chili note, I have one of those super big AL sinks and a $50 water cooling block coming on Tuesday with my new board. Would it be better to put the water block on the top or bottom of the board, and can one mount the fan heat sink to the board without a pad (just thermal grease)?
C
Actually I think part of the spate of recent jally-usb issues is related to BFL pointing the fan *down* for some reason. If you have the sides off it's a good idea, but with them on what happens is that hot air washes over the FTDI232 chip, which is the fastest way (aside from a massive ground fault) to kill the chip.
On a Chili note, I have one of those super big AL sinks and a $50 water cooling block coming on Tuesday with my new board. Would it be better to put the water block on the top or bottom of the board, and can one mount the fan heat sink to the board without a pad (just thermal grease)?
C
I'm having similar issues as well. The 2 I got from batch 3 auction will reset constantly. The voltage gets up to 1.16 and then they disable themselves. If by chance the voltage stays below 1.16 all is well but it's a crap shoot. I have heat sinks on the MOSFETs.
EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.
EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.
I finally found a backplate I'm happy with. They're free, they come in sets of two, and only require one cut and then drilling 4 holes to get them ready. They're only 1mm thick aluminum, but they're curved on two sides which adds to their rigidity. They're also sexy black and the curved sides turn into feet when you flip them over so it makes a convenient stand for the Chili.
Just drill four holes:
Bolt it on (I put a piece of thermal padding in between the board and the backplate, mostly for spacing, though you can't see that here):
Convenient feet!
Where can one find these handy aluminum plates?
Just drill four holes:
Bolt it on (I put a piece of thermal padding in between the board and the backplate, mostly for spacing, though you can't see that here):
Convenient feet!
Where can one find these handy aluminum plates?
I was trying BFG miner and all it does is crash with an error about locating the com "FT_GetComPortNumber" I can get the Chili's to hash great (well low to mid 30's) in cgminer..
I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm). but all I get is instant crash.
Any ideas?
Win 8.1 64bit, BFG Miner 64bit 3.8.1 and I tried 3.8.0
I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm). but all I get is instant crash.
Any ideas?
Win 8.1 64bit, BFG Miner 64bit 3.8.1 and I tried 3.8.0
I have never been able to get anything to hash on win8x64
win7x86 works all the time with all my gadgets.
Is there a non dangerous way to test if a pad is needed or not? Don't want to blow up a chip because it needed a pad and I only used grease.
Honest answer: I use pads on my jallies that have the old and new style chips (the newer ones are lower profile) on the new chips only. On the old ones I use a dab of Radio Shack $2.00 thermal grease.Where I win is putting thermal grease on the bottom of the jally, then either putting the bottom plate on or another heat sink. Do not underestimate how much heat you can draw off the bottom of these things.
C
I was trying BFG miner and all it does is crash with an error about locating the com "FT_GetComPortNumber" I can get the Chili's to hash great (well low to mid 30's) in cgminer..
I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm). but all I get is instant crash.
Any ideas?
Win 8.1 64bit, BFG Miner 64bit 3.8.1 and I tried 3.8.0
I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm). but all I get is instant crash.
Any ideas?
Win 8.1 64bit, BFG Miner 64bit 3.8.1 and I tried 3.8.0
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!
Edit: the message is
Code:
BFL 0: Received unexpected queue result response:
BFL 0: Error: Get temp returned empty string/timed out
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.
I'll email you the file I used.
[/quote]
It sounds like it. You could try opening it up in FTDI's FT Prog utility to see if it's detected there as well.
ok, first (of 10) chili's setup.
This is with an h80 water cooler, and mosfet heatsinks (that are at 150 degrees (f) so we know those are working).
That being said, does this output from cgminer look "good" or right?
cgminer version 3.8.5 - Started: [2013-12-21 13:42:38]
--------------------------------------------------------------------------------
(5s):32.54G (avg):34.68Gh/s | A:7268 R:0 HW:386 WU:458.8/m
ST: 2 SS: 0 NB: 1 LW: 7497 GF: 0 RF: 0
Connected to stratum.mining.eligius.st diff 16 with stratum as user 18eSm9qE51Y
Block: 89ca1981... Diff:1.18G Started: [13:42:38] Best share: 45.9K
--------------------------------------------------------------------------------
Pool management Settings Display options Quit
BAL 0: max 49C 1.04V | 34.19G/34.85Gh/s | A:7300 R:0 HW:387 WU:460.2/m
--------------------------------------------------------------------------------
The setup has been running for about 15 minutes.
Thanks
EDIT: The commandline is just the hostname, username & password no special flags.
This is with an h80 water cooler, and mosfet heatsinks (that are at 150 degrees (f) so we know those are working).
That being said, does this output from cgminer look "good" or right?
cgminer version 3.8.5 - Started: [2013-12-21 13:42:38]
--------------------------------------------------------------------------------
(5s):32.54G (avg):34.68Gh/s | A:7268 R:0 HW:386 WU:458.8/m
ST: 2 SS: 0 NB: 1 LW: 7497 GF: 0 RF: 0
Connected to stratum.mining.eligius.st diff 16 with stratum as user 18eSm9qE51Y
Block: 89ca1981... Diff:1.18G Started: [13:42:38] Best share: 45.9K
--------------------------------------------------------------------------------
Pool management Settings Display options Quit
BAL 0: max 49C 1.04V | 34.19G/34.85Gh/s | A:7300 R:0 HW:387 WU:460.2/m
--------------------------------------------------------------------------------
The setup has been running for about 15 minutes.
Thanks
EDIT: The commandline is just the hostname, username & password no special flags.
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.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?
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.
Is there a non dangerous way to test if a pad is needed or not? Don't want to blow up a chip because it needed a pad and I only used grease.
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.
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
This happens to me sometimes and unplugging power for a few seconds helps.
Jump to: