SOPine modules stay off at reboot?
#21
Nice. The 3v3 island is a good find. The whole diode can be hidden underneath the board in that case. Thanks for the tip about the fiberglass brush too!

As for the battery holder, just for future readers who want it off without desoldering it, here is what I did with an Exacto knife tip:

[Image: battery1.jpg]

[Image: battery2.jpg]

[Image: battery3.jpg]

[Image: battery4.jpg]

Then people can take their time with the battery posts. I just use a Dremel now to trim the posts away for my diode fix. Yes, this is a one-way procedure - not getting the battery holder back  Smile .


> By the way, why would you actually need to remove the battery holder and put it back later?  What is not accessible with the holder still in place?  Also, I don't think that an additional barrier diode, for example, can be tucked underneath the battery holder.

I had a thought experiment where the second diode could be soldered to the untouched battery holder +RTC post (maybe at the base) in my third photo, and the other leg could be soldered to a thin square of metal, and an insulator between the original +RTC post and the new thin metal square. Then the battery + side makes contact not with the original post, but with this new interstitial metal square and the diode does its thing. The second diode leg could come up and over from the outside of the holder and enter down from the top. Then the battery holder can still be used. Thought experiment. This is what I was visualizing FWIW.
  Reply
#22
(04-21-2021, 02:28 AM)Pine Wrote: As for the battery holder, just for future readers who want it off without desoldering it, here is what I did with an Exacto knife tip:

Then people can take their time with the battery posts. I just use a Dremel now to trim the posts away for my diode fix. Yes, this is a one-way procedure - not getting the battery holder back  Smile .

Got it now, there's no intention of putting the battery holder back on.  In that case, I agree that a slightly destructive approach is better when it comes to preserving the solder pads for the two battery holder pins.

(04-21-2021, 02:28 AM)Pine Wrote: I had a thought experiment where the second diode could be soldered to the untouched battery holder +RTC post (maybe at the base) in my third photo, and the other leg could be soldered to a thin square of metal, and an insulator between the original +RTC post and the new thin metal square. Then the battery + side makes contact not with the original post, but with this new interstitial metal square and the diode does its thing. The second diode leg could come up and over from the outside of the holder and enter down from the top. Then the battery holder can still be used. Thought experiment. This is what I was visualizing FWIW.

Nice, the goal would be to create a modified battery holder that contains an "invisible", "built-in" barrrier diode.

A less complicated (and possibly cleaner-looking) approach could be to uncrimp only the "+" battery terminal, leaving the "-" terminal untouched.  Then, unsolder the "+" pin, which should be easier to do separately.  Then, use a through-hole Schottky diode as the new "+" pin: simply put the cathode leg through the pin hole and solder it to the pad, and twist the other end into a loop, just like the original "+" pin.  After that, the original "+" battery terminal could be crimped back, finishing the modification. 

There should be more than enough space inside the battery holder for the body of a small Schottky diode.  However, crimping the original terminal back might prove troublesome, as I already noted in my earlier post, but it would need to be tried out.
  Reply
#23
(04-20-2021, 05:48 PM)dsimic Wrote: If you don't need the actual RTC backup functionality and you want to avoid applying hardware modifications to your Clusterboard, you could connect an external regulated 3.3 V DC power supply to the two pins of the battery holder, with a mandatory Schottky diode "inside" the "+" wire that connects the "+" of the external power supply to the "+" pin of the battery holder.  The purpose of the additional diode is to ensure that no current will flow from the PMICs on the SOPine modules into the external power supply, which would be really bad.

Even in this case, you'd need to solder two wires to the battery holder pins, or to somehow affix the wires reliably to the battery terminals inside the battery holder.

Thanks for the reply. I think I will try something like that.

But for my understanding: isn't the problem with the 2xAA batteries that the voltage drops when discharged and at some point it is lower than what it is connected to and thus the flow reverses? So if I have a stable 3.3V external power source, that should in theory never happen and thus a Schottkey diode wouldn't be needed?
  Reply
#24
You're right; at least in theory, a regulated external 3.3 V power source should always win the "battle" with the VCC_RTC PMIC outputs on the SOPine modules, so you might go without the previously described Schottky diode.  However, having even the smallest possibility for the current to start flowing into the external power supply would be unacceptable to me.  Adding a Schottky diode, as already described, should be easy and very cheap.

Edit: Another problem with the AA batteries is that they get rather rapidly discharged when the Clusterboard is powered on, much faster than when the Clusterboard is turned off.  That just makes the first problem, the batteries becoming charged by the PMICs, more pronounced.

Edit #2: According to pages 33 and 34 of the A64 datasheet, these are the electrical characteristics for the VCC-RTC power input of the A64 SoC:
  • Absolute maximum voltage: 3.6 V
  • Recommended maximum voltage: 3.3 V
  • Recommended typical voltage: 3.0 V

Thus, you'd still be fine without the Schottky diode voltage-wise, but I really would't recommend it, as described above.
  Reply
#25
So as a trial (on my v2.2 Clusterboard), I jury-rigged the R351 3.3V port to the battery compartment's + connector and the - port to the other end of the R351 section, and it seems reboot fine now. Pretty cool what a bit of dumb wire can fix Wink Needs a ATX power supply though.
  Reply
#26
Excellent!  This is another confirmation of the already established general way to fix the reboot issue, and to prevent the two AA batteries from discharging while the Clusterboard is powered on.  Of course, fixing the issues properly will also require barrier diodes.
  Reply
#27
Thread stuck
  Reply
#28
For a reference, and for not wasting the images I've already created, Smile attached are three excerpts from the combined schematics of the SOPine, Clusterboard, SOPine Baseboard, and Pine A64-LTS boards.  The images show the wiring diagrams of the RTC power supplies, coming either from the PMICs or the batteries.

It's rather interesting to compare those three excerpts, especially the Schottky barrier diodes.  The SOPine Baseboard shows the OD4 diode (the second barrier dioe) as N/C and shorted using a separate trace, which is correct because the actual second barrier diode (OD4, again) is located on the SOPine module.  Thus, the SOPine Baseboard actually does the thing right with a SOPine module installed, having a total of two barrier diodes in place (OD3 on the Baseboard and OD4 on the SOPine).  The Pine A64-LTS board also does the thing right: it has two barrier diodes, OD3 and OD4.

Then, why does the Clusterboard do it wrong, by having no second barrier diode?  My guess would be that it had the other barrier diode at some point in time, and the testing probably discovered that the reset of SOPine modules didn't work.  As a quick'n'dirty fix (or as a test?), Pine64 removed the second barrier diode, allowing full voltage from the batteries to reach the SOPine modules (and erroneously allowing the batteries to become charged, and to get discharged while the Clusterboard is powered on).  The reset worked after the fix, and they probably simply forgot to make it right later.


Attached Files Thumbnail(s)
           
  Reply
#29
As a note, there's another thread that describes a rather different issue, which  comes up when SOEdge modules are installed in a Clusterboard.  Spoiler alert: unless there's something wrong or missing in the SOEdge schematic, it's really bad. Sad
  Reply
#30
I've added a 1N5819 diode as suggested (https://renzenicolai.nl/clusterboard.jpg), but this solution doesn't seem to work.

I've tried:
- u-boot "reset" works with and without the diode
- Removing all but one SoPine (no effect)

Rebooting from Linux ends with "[  79.856377] reboot: Restarting system", after that the system halts.
I'm using Arch Linux with kernel 5.11.4-1 (the generic rootfs). In the devicetree for LInux I've patched only the ethernet tx delay setting.

What am I missing?

Could someone post a known good Linux image which I can try to make sure it isn't a software issue?

What other things can I try to diagnose / debug this problem?

EDIT: fixed it, it was the coprocessor firmware, disabling that made rebooting work.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Selling Clusterboard + 4 sopine xblack86 7 5,735 09-26-2022, 03:09 AM
Last Post: poVoq
  Buy Cluster and Compute Modules jpotter 1 1,768 01-10-2022, 04:01 PM
Last Post: dcdc
  Clusterboard/Modules shipment arrived in a bag ichibon-brosan 2 4,942 07-09-2020, 12:27 PM
Last Post: shadowhelo
  sopine socket power problem cgiraldo 1 3,267 06-17-2020, 02:10 PM
Last Post: cgiraldo
  Individual SOPINE Power On After Shutdown? Pine 2 3,812 01-30-2019, 08:04 AM
Last Post: mdmbc
  How much force does it take to insert a SOPINE module? jbobspants 0 1,931 01-17-2019, 12:15 PM
Last Post: jbobspants
  Compiling on the Sopine Cluster khaosgrille 3 5,426 08-10-2018, 06:17 AM
Last Post: khaosgrille
  Kubernetes on SoPine cluster part.1 maya.b 3 7,732 04-18-2018, 08:31 AM
Last Post: PigLover
  sopine cluster thermal images maya.b 4 6,676 12-29-2017, 02:51 PM
Last Post: Luke

Forum Jump:


Users browsing this thread: 1 Guest(s)