The Chili – 30+GH/s BFL based Bitcoin Miner Assembly

[Cascaders28]

For those who have assembled their chilis with thermal pads instead of paste -

Do you cut small squares for each chip or have you been using one large pad that also covers the open area between the chips?

Thanks!

[Mudbankkeith]

I have just assembled my 7th Chili

On power up, the leds 5,6,7,8, come on and stay on, then leds 1,2,3,4, flash once.
The com port is not found. nothing else happens.

Does anyone have any ideas?

This is one of Lucko's boards?

LEDS 5-8 being on indicate that it is in the hardware initialization phase and if there is a hardware fault it keep those on. This is usually due to the 1V power supply not being able to turn on for whatever reason.

Thanks for the info.

[twib2]

Also, following up on the Chili that died during a reset gone bad (short pins 5-6 but must have also touched something adajacent)...  I replaced the FTDI, so now two parts are working:

1.) The boot up light sequence appears to be functioning correctly, so I would imagine that most of the Chili should be in good order (was working right after I lost comms/hashing, too).
2.) The FTDI seems to work.  I can see the device in the USBs and in Windows I can *try* to read or even flash the firmware, but I get garbage in the results window.

Something else must be dead, but I'm not sure where to go from here.  Ideas, anyone?

I would concur with lightfoot, it sounds like the microcontroller is running fine and the FTDI chip is also working or at least partially working.
When the device shows up in Windows, is it a serial port / serial convertor, or does it show up as a Bitforce SC? If it doesn't show up in Windows and you're getting garbage from the EEPROM in the FT_PROG window, I'd look for a cold solder joint on the FTDI chip.

Good deal - thanks, I'll take a look when I get home from work.  My eyes aren't that good for close up stuff (old!), but I'll see what I can do.  I was wondering if it could be something like that, but couldn't see anything amiss earlier.  This gives me impetus to look again or borrow my wife's eyes.  ;-)

BTW the FTDI shows up in windows as a serial converter IIRC.  Does that help?

[BrimStone]

For those who have assembled their chilis with thermal pads instead of paste -

Do you cut small squares for each chip or have you been using one large pad that also covers the open area between the chips?

Thanks!

I used one large pad which also covers the open area between the chips.  I have had no problems with that technique.

[MrTeal]

Also, following up on the Chili that died during a reset gone bad (short pins 5-6 but must have also touched something adajacent)...  I replaced the FTDI, so now two parts are working:

1.) The boot up light sequence appears to be functioning correctly, so I would imagine that most of the Chili should be in good order (was working right after I lost comms/hashing, too).
2.) The FTDI seems to work.  I can see the device in the USBs and in Windows I can *try* to read or even flash the firmware, but I get garbage in the results window.

Something else must be dead, but I'm not sure where to go from here.  Ideas, anyone?

I would concur with lightfoot, it sounds like the microcontroller is running fine and the FTDI chip is also working or at least partially working.
When the device shows up in Windows, is it a serial port / serial convertor, or does it show up as a Bitforce SC? If it doesn't show up in Windows and you're getting garbage from the EEPROM in the FT_PROG window, I'd look for a cold solder joint on the FTDI chip.

Good deal - thanks, I'll take a look when I get home from work.  My eyes aren't that good for close up stuff (old!), but I'll see what I can do.  I was wondering if it could be something like that, but couldn't see anything amiss earlier.  This gives me impetus to look again or borrow my wife's eyes.  ;-)

BTW the FTDI shows up in windows as a serial converter IIRC.  Does that help?

That would imply that either it's not accessing the EEPROM correctly, or that it wasn't successful when you programmed the FTDI chip.

You did program the FTDI chip, correct?

[twib2]

That would imply that either it's not accessing the EEPROM correctly, or that it wasn't successful when you programmed the FTDI chip.

You did program the FTDI chip, correct?

Aha, I'm guessing that I missed that part of swapping it out.  I don't have a programmer for such things, let alone the program I'd need (assuming you're not talking about the firmware update...).

The question then becomes, what now? 

[MrTeal]

That would imply that either it's not accessing the EEPROM correctly, or that it wasn't successful when you programmed the FTDI chip.

You did program the FTDI chip, correct?

Aha, I'm guessing that I missed that part of swapping it out.  I don't have a programmer for such things, let alone the program I'd need (assuming you're not talking about the firmware update...).

The question then becomes, what now? 

You just program it through USB. I edited the second post in the thread with a link to the template and the programming utility.

[twib2]

That would imply that either it's not accessing the EEPROM correctly, or that it wasn't successful when you programmed the FTDI chip.

You did program the FTDI chip, correct?

Aha, I'm guessing that I missed that part of swapping it out.  I don't have a programmer for such things, let alone the program I'd need (assuming you're not talking about the firmware update...).

The question then becomes, what now? 

You just program it through USB. I edited the second post in the thread with a link to the template and the programming utility.

Perfect, thanks!  I feel like a bonehead for missing that step - I just assumed it was a RTG (ready-to-go) chip...

Crossing my fingers and hope to get back here with good news (either programming or solder fixing it).

Best, and thanks again for your time (and I still want more Chilis!  )
- Tye

[asjfdlksfd]

Do you cut small squares for each chip or have you been using one large pad that also covers the open area between the chips?

I use two stripes for 3 chips and 2 squares for the other 2. The FujiPoly 17W/mK is to expensive to heat the capacities ;-)

Cheers....

[daemonfox]

Do you cut small squares for each chip or have you been using one large pad that also covers the open area between the chips?

I use two stripes for 3 chips and 2 squares for the other 2. The FujiPoly 17W/mK is to expensive to heat the capacities ;-)

Cheers....

4 strips covering a corner and side chip each rectangular piece. Now using the paste that come on my H60 ON TOP of the pads and have much better results... up from sub 33 or lower GH/s to 35 GH/s now.

[twib2]

You just program it through USB. I edited the second post in the thread with a link to the template and the programming utility.

OK, I got the FTDI programmer and the template file, and it recognized my FTDI (good sign), then I aapplied that template file and then hit Program Device.  All seemed to have gone well, but then I go to the Chili Flash Utility, I still get garbage ("EWWOW?%UOOOOWO") when I open COM5 where the device is found.  Same garbage when I cycle the device after trying to flash the chili HEX, too.

I'm happy both utilities seem to recognize the device - makes me think it's definitely salvageable if I do the right repairs, but no joy so far.  I'll look at the solder of the FTDI, but does my description help any more with ideas?

[twib2]

Update, I hand-heated each pin on the FTDI and tried again - no luck, in fact bootup hung.  So, I heated up the FTDI legs using the hot-air station with good pressure on the chip for 20 seconds on each side and tried again.  VOILA'!!  It let me read the firmware and for good luck I reflashed in case it had gotten horked-up with my attempts at flashing earlier.

SUCCESS

Now it works and is hashing away.  Thanks so much to lightfoot and MrTeal - you guys ROCK!

[MrTeal]

Update, I hand-heated each pin on the FTDI and tried again - no luck, in fact bootup hung.  So, I heated up the FTDI legs using the hot-air station with good pressure on the chip for 20 seconds on each side and tried again.  VOILA'!!  It let me read the firmware and for good luck I reflashed in case it had gotten horked-up with my attempts at flashing earlier.

SUCCESS

Now it works and is hashing away.  Thanks so much to lightfoot and MrTeal - you guys ROCK!

Great, nice to hear you got it working. Those 0.5mm pitch chips can be a pain to rework with an iron. Air is definitely the way to go if you have one.

[bx8389]

I have just assembled my 7th Chili

On power up, the leds 5,6,7,8, come on and stay on, then leds 1,2,3,4, flash once.
The com port is not found. nothing else happens.

Does anyone have any ideas?

This is one of Lucko's boards?

LEDS 5-8 being on indicate that it is in the hardware initialization phase and if there is a hardware fault it keep those on. This is usually due to the 1V power supply not being able to turn on for whatever reason.

Thanks for the info.

Hello MrTeal

I have a Lucko's board that hashes normally and after some hours stops with led 4 and 7 steady on. Firmware is 1.1V-because is a "good one" board. Don't seems, at first glance, a temperature problem
I have do a search but haven't found a mean for this led configuration:  can you give an advice on it?

I have another request if possible: Seems strange for boards with restarting problems but is possible to adapt a reset button on chilli board? The reason is because is somewhat difficult to put all boards working together due vrm issues and a reset button can give opportunity to try to restart one particular board without disturbing already running others

Regards

[Mudbankkeith]

The hairdryer trick works wonders, for the low power crash.

as soon as the board completes initialization and starts to count, I switched the hairdryer from cold blow, to hot blow.   
 The fets temp. went up to 46c and NO CRASH   

Now its hashing the fets temp is steady 43c to 44c   

I just need to test out how this will work with 8 Chili on a rPi and hope it stays stable.   


My thanks to the brave man who tried it the first time with a soldering blower.

[GenTarkin]

What temp is being pulled per device as the "lower temperature" in bfgminer? When I go to manage devices, it shows 2 temps, one obviously the highest temp chip, the other is lower, usually in the 30's

Also, Im wondering, when I stopped a device(one of my better ones that usually hashes at 38gh+, using the mining application) .. let it sit for a few minutes, then reenable it..
It slowly climbs up to its normal 38GH, then I saw it go over 40GH as the voltage climbed to 1.15v+ ... then it slowly started going down(both voltage and hashrate) .. back to is normal 38GH range, is this a temp threshold on the power circuitry being hit or OCP or something?
Im wondering if adding cooling to the power area would help it go higher than 38GH =P

[MrTeal]

What temp is being pulled per device as the "lower temperature" in bfgminer? When I go to manage devices, it shows 2 temps, one obviously the highest temp chip, the other is lower, usually in the 30's

Also, Im wondering, when I stopped a device(one of my better ones that usually hashes at 38gh+, using the mining application) .. let it sit for a few minutes, then reenable it..
It slowly climbs up to its normal 38GH, then I saw it go over 40GH as the voltage climbed to 1.15v+ ... then it slowly started going down(both voltage and hashrate) .. back to is normal 38GH range, is this a temp threshold on the power circuitry being hit or OCP or something?
Im wondering if adding cooling to the power area would help it go higher than 38GH =P

Right now it is the general board temperature. That will be changed in the next FW revision to the temperature from the sensor right near the mosfets.

It might, although some of that could also be due to a bunch of effects. When you first start things up the temps are lower. The chips draw less current when the temperature is lower, but as it starts heating up the current goes up. Not only that, but the traces on the substrate and in the chip itself get hotter and their resistance goes up, so your voltage drop increases for two reasons and the actual voltage you see on the silicon is lower. Since the frequency (and hashing speed) of the BFL chips is voltage dependent, all things being equal they will slow down as they heat up.

[GenTarkin]

What temp is being pulled per device as the "lower temperature" in bfgminer? When I go to manage devices, it shows 2 temps, one obviously the highest temp chip, the other is lower, usually in the 30's

Also, Im wondering, when I stopped a device(one of my better ones that usually hashes at 38gh+, using the mining application) .. let it sit for a few minutes, then reenable it..
It slowly climbs up to its normal 38GH, then I saw it go over 40GH as the voltage climbed to 1.15v+ ... then it slowly started going down(both voltage and hashrate) .. back to is normal 38GH range, is this a temp threshold on the power circuitry being hit or OCP or something?
Im wondering if adding cooling to the power area would help it go higher than 38GH =P

Right now it is the general board temperature. That will be changed in the next FW revision to the temperature from the sensor right near the mosfets.

It might, although some of that could also be due to a bunch of effects. When you first start things up the temps are lower. The chips draw less current when the temperature is lower, but as it starts heating up the current goes up. Not only that, but the traces on the substrate and in the chip itself get hotter and their resistance goes up, so your voltage drop increases for two reasons and the actual voltage you see on the silicon is lower. Since the frequency (and hashing speed) of the BFL chips is voltage dependent, all things being equal they will slow down as they heat up.

Well whats interesting is its one of the cooler chilis I have yet hashes the fastest. At 40+ GH its only reaching 61C @ 1.15v+ ... when voltage comes down to 1.112v @ 38.4GH its right around 54C ...lol .. I would like to see it try to stay higher.

[Mudbankkeith]

What temp is being pulled per device as the "lower temperature" in bfgminer? When I go to manage devices, it shows 2 temps, one obviously the highest temp chip, the other is lower, usually in the 30's

Also, Im wondering, when I stopped a device(one of my better ones that usually hashes at 38gh+, using the mining application) .. let it sit for a few minutes, then reenable it..
It slowly climbs up to its normal 38GH, then I saw it go over 40GH as the voltage climbed to 1.15v+ ... then it slowly started going down(both voltage and hashrate) .. back to is normal 38GH range, is this a temp threshold on the power circuitry being hit or OCP or something?
Im wondering if adding cooling to the power area would help it go higher than 38GH =P

Right now it is the general board temperature. That will be changed in the next FW revision to the temperature from the sensor right near the mosfets.

It might, although some of that could also be due to a bunch of effects. When you first start things up the temps are lower. The chips draw less current when the temperature is lower, but as it starts heating up the current goes up. Not only that, but the traces on the substrate and in the chip itself get hotter and their resistance goes up, so your voltage drop increases for two reasons and the actual voltage you see on the silicon is lower. Since the frequency (and hashing speed) of the BFL chips is voltage dependent, all things being equal they will slow down as they heat up.

I have found that some cooling to the back of the board under the power modules, can improve a board like this.(its worth a try for a couple of hours)
The asic temp will probably rise.

[Mudbankkeith]

I have finally got these two bad girls  reasonably stable at asic temp of 68c and power module at 44c/45c

Note the evo 212 coolers are lifted 15mm up. This has reduced the cold airflow over the power modules.

after I used the "Hairdryer Mod" the boards would restart, but the temp. at the power modules would slowly fall.(eventually crashing again)

The cardboard cover is (hopefully) holding the temp. in the power modules and the cold air from the evo is deflected upwards.

The secondary fans are controlling the airflow under the boards, if I move them around then the temp. does change.


https://www.dropbox.com/s/y6dc59y5zzeaub5/IMG_20140110_105218.jpg