So I’ve had a hash board down for a few weeks and just now finally got a chance to take the unit down and see what we’ve got. Upon boot up the L3+ sometimes shows a missing hash board in HIVEOS (L3+_HashBoard_72_V1.6.1), as well as the stock firmware. Other times it comes up as anywhere from 2-72 chips (under ASIC status) found. I swapped cables and PS units and it still appears that way. Of note it also shows 0 for the PCB and chip temperatures, 0.00 for the MH/s (RT and avg), and strangely enough “Infinity” under W/MH.
December 1, 2021
I decided to start down the path of measuring various voltages and found the following after I inspected the 14V boost circuit (most common fault it seems:)
- C1074 missing (no idea if it was ever there but the hash board did work fully at one point)
- Voltage across C1072 – 11.98V
- Voltage ground to L1 – 7V
- Voltage across C1221 – 7.02V
So I started wondering if I’ve got a bad switching power supply in U111. I reached out to the Reddit world to see if anyone else experienced this on a hash board. I had a few folks reach out, but most the times it was to point me to the Bitmain L3+ repair guide (translated to EN.) This is a great general resource for L3+ troubleshooting, however it’s somewhat dated and really only deals with the V1.0 hash board which has different part numbering on the PCB and some completely different IC packages.
So time to get dirty again, I traced back to the DC/DC converter and found that there’s only a 7V output from there (which runs through L1), Q3/Q4 and across L2 only shows 6.94V so where do I go from here. I can’t find the V1.6.1 schematic anywhere online and can’t read the DC/DC part number to figure out what part it is. The PIC inputs are correct and it’s sending the keep alive every minute, so I think it’s somewhere between there and the boost circuit.
Update December 2, 2021
I think I have it narrowed down to before the boost circuit in the 10VDC rectifier. The big difference, other than the PCB numbering changing, is that the V1.6.1 uses a up9305W sync-rectified buck controller for the 10VDC and the older versions (1.5 and below) use the LM27402. Completely changes the circuit so the older schematics don’t help. Somehow either the up9305W is bad, or possibly a res or cap. I also verified the Schottky barrier rectifiers (MBR540MFS) on the output of the 10VDC circuit. Q1 and Q5 are tied between 12VDC and 10VDC (output) and Q3 and Q4 are tied between GND and 10VDC (output.) These then run through L2 before hitting the 14VDC boost circuit as well as other components.
Here’s a sample of what the circuit design should look like on the V1.6.1 version hash board, and the 10VDC should be generated by the internal Vref x (R1+R2)/R2.
(*From the data sheet) The output voltage can be programmed to any level between the reference voltage VREF up to the 90% of VIN supply. The lower limitation of output voltage is caused by the internal reference. The upper limitation of the output voltage is caused by the maximum available duty cycle (90% typical). This is to leave enough time for over current detection. Output voltage out of this range is not allowed. A voltage divider sets the output voltage (refer to theTypical Application Circuit on page 3 for detail). In real applications, choose R1 in 1kΩ ~ 10kΩ range and choose appropriate R2 according to the desired output voltage.
Update December 3, 2021
I decided to go ahead and install a new 14V boost circuit. This is an easy addition to the hash board, actually much simpler and cheaper than trying to replace the components on the board itself. It’s a relatively simple part to add, I used step-up boost converters I found on Amazon for just about $1 a piece.
When adding these in the key is to have a quality soldering iron as the temps needed to reflow the solder on the L2 lead is significant. Also insure you remove D1 so you isolate your new 14V boost circuit from the existing components and set Vout to 14V before soldering the wire to the D1 pad (you should solder to the D1 pad furthest away from L1.)
Now the big test, make sure you have both the power cables and comm cable to your control board attached as the processor is required to send the signal to the hash board to operate properly. Forget this step and you’ll just be chasing “ghosts in the computer.”
Did it work, well, yes now I measure 14V however that didn’t fix my hash board issue. Next step, well, I’m going back a step and will attempt to replace the sync-rectified buck controller to see if that’s causing the low voltage (7V) instead of the holy grail of 10V. It’s strange given all the faults on the board, but it’s a good next step given the fact that if the base core voltage is off, that can have a ripple effect across other components.
Update December 23, 2021
I put together a DIY test kit for the L3 and ran some diagnostics. It appears that my temperature sensor is most likely bad (flaky, which is bad.) So my next step is to replace that and see where that takes us!
In reviewing the schematic of the temperature sensor, we can see that the TMP451 uses I2C to communicate on the hash board as well as having its own built in temperature sensor that is attached externally (pin 2 (D+) and pin 3 (D-)).
TEMP_P and TEMP_N are the PNP or NPN transistor in the ASIC (BM1485) itself that read the temperature. What I’m not sure of is which specific ASIC is it getting the temperature from as they operate in. I believe they use a thermal substrate transistor in one of the nearby BM1485 ASIC’s and have it wired to pin 6 (TEMP_N) and pin 7 (TEMP_P.) According the limited schematics I’ve seen they only show one representative sample of the BM1485 wiring and those pins are unconnected. I also see there are pads across the board for numerous TMP451’s, probably an enhanced feature they never implemented?
Luckily the TMP451 is in a WSON package, which makes it a complete pain to replace unless you have the right equipment and a steady hand. I suggest low temp solder paste in a syringe and a heat gun. I’ll try and video the process and post it when I’m done.
Update January 1, 2022
Finally success! I racked my brain for hours and finally decided that the buck controller wasn’t putting out the proper voltage. I inspected the PIC and since I could get some hashing I knew it was programmed properly, so I went back to PCB (printed circuit board) manufacturing 101, when it doesn’t work, rule #1 – reflow those solder joints.
I reflowed the PIC and the buck controller and viola! She’s hashing up a storm once again.
Reflow those joints, these circuit boards weren’t manufactured in the best possible environment
Howdy Mr. Myers,
I just got into mining and purchased a fully functional L3+. All fault to myself, I hit the reset button inside Hiveos and when the unit came back on, only 3 of the 4 boards were working. I found a site that spoke of similar instances and gave a fix that involved unplugging all ribbon wires and routing “chain 0″(far left) directly to the board with the issue and flashing said board with a version of Blissz. No joy at all. I’ve restarted it several times and still, no joy. Just curious if that could have caused a hardware failure? Just seems too coincidental with the reset. It was literally a “what does this button do?” situation. Almost have to laugh about it. Maybe I will when I recover the $289 I spent on a refurbished board. Below are the steps that I were instructed on for your viewing pleasure. If you have any ideas on what this might be and could give some advice, I might just send you a Christmas card this year.
Thanks so much,
Jason
“1. Simply unzip to contents of this zip (from the l3+ L3++ Bypass folder) file to a freshly formatted MicroSD card not larger than 8GB
2. Power off miner, put MicroSD card into the cardreader of the miner
3. Power on miner and wait for a few minutes or until miner has an ip adress
4. Power down miner and remove sd card.
5. Power on miner and search for the ip adress using “TP Reporter” avaliable from
Bitmans web site, or any other methode you prefer to find miners ip adress
Your good to go!
To troubleshoot,
Make sure to set the miner back to factory default settings before flashing. Also use a
freshly formatted sd card, make sure it is formatted to fat32. Make sure there is nothing
else on the card also when unzipping it. Make sure it is on the root of the sd card as it
appears when opening the zip file, as sometimes when unzipping, an extra folder is added
to store all the uncompressed files in.
If this is the case, all the files must be taken out of that extra folder that was created.
Move the zip file contents to your sd card, turn the power off to the miner, put the card
in and turn the power on, let it sit for atleast 3-5 minutes. Turn power off, remove
card and turn miner back on. Find the new IP addresses you normally would with antminers
ip finder. Also, make sure you clear all your browser data to make sure you are not
looking at old cached data from your previous firmware. I have had a few customers say
they had to try to flash multiple times before it works, but they also have sucess after
trying a few times. If it still does not work then
you may have a defective sd card slot reader in your miner.”
It sounds like those are instructions for reprogramming the PIC on an individual board. If you only have one board plugged into chain 0 and use the Blissz fix that’s generally due to a PIC issue. I doubt that’s what happened when you reset your unit. What I would suggest is to reset it back to stock firmware or reinstall HiveOS. I would use the Bitmain control board recovery firmware and process: https://support.bitmain.com/hc/en-us/articles/115000216034-L3-L3-and-L3-Control-Board-Program-Recovery
This will reset your unit to stock Bitmain firmware so you have a known starting point. If all 4 boards don’t come up after this then I would look at your kernel log to see if it finds them all. Feel free to shoot me a copy of it (info@asicbasics.com) and I’ll take a look as well.
Hi Andy, got a L3+ board that has me puzzled. I’ve installed new 14v boost module and get 14v. Get 12v at c943 and 10v at c948. Mosfets are not shorted. I’ve checked all the ldo’s and they are not blown. Do you have any other ideas what could be the problem. On the ARC tester it picks up 0 ASIC chips. Thanks
What is your kernel log showing as errors beyond 0 asics? Often times there is correlating information, such as a temp error, that would lead to shutting down hashing. I would also try swapping I/O cables just to be sure it’s a specific problem to the board. Lastly I would check out this video (https://www.youtube.com/watch?v=ZLQ4lK_p6-Q) to verify the voltages at each ASIC to ensure you don’t have a short across one that’s killing the entire chain.