Beta board distribution -- action requested

You run the risk of blowing the processor if the turn off sequence was not per the datasheet.

Gerald

You run the risk of blowing the processor if the turn off sequence was not per the datasheet.

Well, that was my point. Currently we cannot do a full TPS shutdown because of this issue:

>*> 3. All BeagleBones have a mismanaged external regulator for the*
>*> "3v3exp" (BBW) / "3v3b" (BBB) rail, which remains enabled longer than*
>*> the AM335x's 3.3V supplies ("3v3a").*

My proposal was to shutdown the 3v3b regulator before initiating a TPS shutdown.

Regards,
John

There should not be any smps/ldo active at all after on-to-off transition is complete.

Further, comparing to bbb or am437x and x15 is not correct. They are very different system power architectures. Rtc offmode which am33x or am437x is capable of is not a target on x15 arch. So, PMIC on x15 does automatic “shut all off” sequence in the right prescribed order. This is not possible on am33x or am43x due to various levels of “off” and software optimization is done.

I am all interested in seeing if anything new can be done though… Just highlighting that expectations should be tempered based on architecture.

I think this is an artifact of:

ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage - kernel/git/torvalds/linux.git - Linux kernel source tree

bit long discussion about it..

That is very interesting. I wonder if it would be possible to power off individual regulator outputs before initiating a TPS65217C shutdown. Could this be a work around for this issue? Also, is this going to be an issue with the BeagleBoard-x15?

We have a fancy new PMIC on the x15.. :wink:

Regards,

Only way to do that is to shut off the 3.3VA regulator.

Gerald

Fancy? Not exactly my words…

Gerald

Only way to do that is to shut off the 3.3VA regulator.

Yeah, and that kills everything. Oh well, it was just a thought. Would this have worked if 3V3B regulator was enabled from 3V3AUX?

Regards,
John

Not sure.

Gerald

I have two BBB A5A boards which I believe have the 3V3B regulator enable pin connected to 3V3AUX.

Running TI’s 4.1.6-ti-r14 kernel, after doing a halt, I get 0mA on one board and 136mA on the other. I am booting from SDCard (holding S2 during boot) and I’m using the same SDCard to boot both boards. The only difference I can see is the one board shows “rtc_power_ff failed, bailing out” on the last line and that board doesn’t power down fully.

Regards,
John

Wait, please don't tell me you still have a 3.3V regulator enabled by
another 3.3V rail on the x15 ?

Note btw that pressing the power button for 10 seconds on the BBB is
supposed to trigger a reboot, not a powerdown. The only reason it powers
down is because, bizarrely, the TPS65217 always switches the main power
path to battery power at the *start* of the shutdown sequence, even if
there's no battery. The SYS_5V capacitors drain too fast (unless you have
no external I/O and disable the HDMI framer), the power supplies lose
regulation before sequenced powerdown, and the PMIC enters FAULT state,
hence once second later OFF state.

http://elinux.org/BeagleBone_Power_Management#Power_down

The good news is that the failing SYS_5V seems to mostly prevent damage
being done by the 3V3B, although I've already seen several people whose
UART0_RXD started to fail on an older BBB (this cpu pin is the worst victim
of the 3V3B on a CAPE-less BBB).

Actually, we have a FET controlled by the PMIC to turn on the 3.3V It is called power sequencing, something you don’t need in an Arduino.

On the BBB the external 3.3V is the same rail as the 3.3V power output of the PMIC. The power on the PMIC was insufficient, so I added more power capacity with an external LDO. .

Gerald

Actually, we have a FET controlled by the PMIC to turn on the 3.3V It is
called power sequencing, something you don't need in an Arduino.

Thank you Gerard, but I spend many days doing nothing but power up and down
a BBB with so many scope probes attached it looked like it was on an
intensive care unit, and I've previously participated in a hardware design
with another TI SoC. I'm well aware of their power sequencing needs, and
wrote some lengthy posts about the BBB's on the beaglebone list, e.g.:
https://goo.gl/TjnRzN

On the BBB the external 3.3V is the same rail as the 3.3V power output of

the PMIC.

Ehh, no, since as you point out:

The power on the PMIC was insufficient, so I added more power capacity with

an external LDO. .

But had trouble finding a suitable enable signal for it, hence in rev A6
returned to the same scheme used on the BBW dispite the known issue that it
fails to shut off if there's any significant leakage from the regulator
output to vdd_3v3a (which required a CAPE on the BBW but is provided by
on-board hardware on the BBB), with as result that part of the considerable
capacitance on sys_5v is discharged through protection diodes on am335x
i/os every time you poweroff. https://goo.gl/yeqnmR

That's why I was worried a bit when it sounded for a moment you had a
similar scheme on the x15.

Matthijs

P.S. the move of vdds to ldo1 in rev A6A also seems like a bad one to me,
even though it was advised by TI so I may be overlooking something.
Unfortunately, my attempt to get clarification from TI failed:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/421756/1517544#1517544

We had to change the PMIC outputs on BBB to support the DDR3 configuration. AlI I had to work with was the TPS65217. There we some challenges there.

The 3.3V supply on the X15 is a 4A supply, and only one. It is enabled by an output of th ePMIC, so we have no dual supply scenario there.

X15 is not a BBB. Not even close.The power challenges are a whole lot different, like a dedicated 3.0A just for the three USB3 ports.

Gerald

We had to change the PMIC outputs on BBB to support the DDR3
configuration. AlI I had to work with was the TPS65217. There we some
challenges there.

I know, power supply schemes can be a real headache. Still, it would have
been nice if a solution for the 3v3b had been found that didn't hose those
wanting to hook up a li-ion to the tps. (The only easy fix we found was
removing the regulator and placing it by a wire tying 3v3b to 3v3a.)

Sorry I snapped a bit at you, but the "It is called power sequencing,
something you don't need in an Arduino" wasn't exactly nice either.

The 3.3V supply on the X15 is a 4A supply, and only one. It is enabled by

an output of th ePMIC, so we have no dual supply scenario there.

Good to hear :slight_smile:

Only 4A ? But a PCIe card already reserves 3A of that! :wink: *duck and cover*

X15 is not a BBB. Not even close.The power challenges are a whole lot

different, like a dedicated 3.0A just for the three USB3 ports.

Hehe, joy.

Matthijs

Just remember, these conversations are for anyone that reads them, so education can apply to those that have not yet had it.Sometimes I just ay yes or no, and sometimes I try to explain it a little . Power sequencing has caused me more issues than I care to think about.

Gerald

I should be getting a tiny number of beta X15 boards on Wednesday. I’d like to minimize the turn-around from arrival with me to boards in key developer hands, I’d like for people anxious for boards to reply to this list with:

  1. What your plans for the boards would be.

Test remoteproc/rpmsg implementation on V4.1.6-bone15. I have this working on BBB and have already added the code necessary to support BeagleBoard-x15. The code includes all the updated platform code for all processors, updated devicetree and updated devices (spinlock, mailbox, rpmsg, remoteproc). The test comprises of loading PRU firmware and loading rpmsg_client_sample.ko, which sends 100 “Hello World” messages to PRU1 which receives and interrupt, copies the message and sends it back to the ARM which initiates a callback.

  1. What open source repositories (URLs please) will host your contributions.

I will be sending Robert Nelson patches for his V4.1.6-bone15 Kernel.

  1. What expertise you have to accomplish your goals.

I have this code working on BBB with the same kernel version.

  1. What your plans for the boards would be.

Front questions on #beagle freenode during Europe daylight hours. Being unemployed gives me lots of time for that.
It really helps to have used the hardware for a while and have run into some problems. cough ROMBL partition table on OMAP4 weirdness cough - my run in and some observations got AV500 to find the #exactsteps to the problem.

Also I’d like to revisit my Internet-of-Toilets project. I have some TI CC2530 boards to do various measurements (including the world famous flush) and would like to try the AT86RF233 IE³ 802.15.4 receiver and BT-smart with the X15 and test the Linux kernel 6lowpan drivers for the 233 on X15.

Maybe later some I²S hacking, but no promises on that.

  1. What open source repositories (URLs please) will host your contributions.

If I find anything in the Linux driver, then it will enter through bluetooth-next, but all my personal stuff is mostly on dm8tbr (Thomas B. Ruecker) · GitHub and some on git.xiph.org (Icecast and related sources)

  1. What expertise you have to accomplish your goals.

Own and have hacked on OMAP1, 3 generations of OMAP3 silicon (Archos Gen6, Gen7, Gen8, Nokia N900, N950, N9), OMAP4 (Pandaboard, Archos Gen9, Gen10), AM335x BBW&BBB.
Prototype @IoToilets on a BBB. Some work on MQTT and other IoTish protocols.

Hello Jason,

  1. MikroElektronika would like to be one of the first to create a mikroBUS Cape for the X15, making sure developers have a huge portfolio of add-on boards to use (click boards)
  2. We don’t plan to create a new Linux distribution, but rather share source code for click board drivers on GitHub
  3. We are a renowned company with 15 years of experience in hardware and software design.

If you can send us a board sample we can create a selection of 4-5 demoes to run at the launch date.

Best regards,
Aleksandar

X15 does not support capes. This is a whole different bear. Bigger board size and different connectors.

Gerald