cancel
Showing results for 
Search instead for 
Did you mean: 

poweroff command line issue

Eldam
Senior

Hello ST Teams!

We're testing another one stm32MP1 custom board (battery powered), and i've issue with poweroff command line function:

Each time i use this function, board is rebooting instead of poweroffing (...)

With these info from tfa:

INFO:   Reset reason (0x814):

INFO:     Pad Reset from NRST

I've see a similar post on ST Forum, but it doesn't help me!

We are using a STM32MP1 from your Octavo partner, and i will post on their forum too.

Octavo have encapslulated STM32MP1+PMIC+DDR on a single chip, so PMIC should be correctly wired.

We have a PONKEY wired on the board, witch works perfectly, i can shutdown and wakeup by an action on "power" button.

I've tried lot of distribution configuration, looked at PMIC internal registry, but i've no hints on what cause this.

I've tried to use a "generic" Octavo Distribution (BRK one), stopped booting at uboot, to avoid unnecessary software issue, but i've the same behaviour.

I'm feeling that there is an hardware issue, but i don't see where it is?

May someone give me an advice on this problem?

have a nice day!

1 ACCEPTED SOLUTION

Accepted Solutions
PatrickF
ST Employee

Hi,

at least the pull-up on PMIC PONKEY is useless (there is an internal one in the STPMIC1).

Maybe look at any component on your board which could affect NRST during the power-down sequence.

We often see in customer design some NRST direct connections to components which are not powered by VDD (which is the latest supply to shutdown) which generate a NRST low (or close to) when their supply is OFF. This is usually avoided by a diode (and pull-up if required) between NRST and the component reset.

An oscilloscope plot of VDD/etc... supplies and NRST during power off might help you to understand if the system is not going to shutdown at all (i.e. NRST before the power off sequence is really asked to STPMIC1) or if a restart from shutdown occur due to wakeup request (PONKEY or WAKEUP STPMI1 pin).

If needed, see STPMIC1 datasheet for more details on turn_off sequences and options and turn_on conditions.

e.g.

0693W00000DnE5PQAV.png 

Regards,

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

5 REPLIES 5
PatrickF
ST Employee

Hi,

at least the pull-up on PMIC PONKEY is useless (there is an internal one in the STPMIC1).

Maybe look at any component on your board which could affect NRST during the power-down sequence.

We often see in customer design some NRST direct connections to components which are not powered by VDD (which is the latest supply to shutdown) which generate a NRST low (or close to) when their supply is OFF. This is usually avoided by a diode (and pull-up if required) between NRST and the component reset.

An oscilloscope plot of VDD/etc... supplies and NRST during power off might help you to understand if the system is not going to shutdown at all (i.e. NRST before the power off sequence is really asked to STPMIC1) or if a restart from shutdown occur due to wakeup request (PONKEY or WAKEUP STPMI1 pin).

If needed, see STPMIC1 datasheet for more details on turn_off sequences and options and turn_on conditions.

e.g.

0693W00000DnE5PQAV.png 

Regards,

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Eldam
Senior

0693W00000DnKT3QAN.pngWell, first of all, thanks for answering me so fast, with efficiency.

En effet, we use the nrst signal in order to reset emmc chip at the same time.

After removing the connection, i can poweroff my board, and wake it up by button.

Unfortunately emmc chip is powered by +3.3(PMIC_VOUT4), which is the one who get disabled, so nRST is going low because supply is going low (well nRST is an input for emmc, no reason to be drived! weird behavior).

Meanwhile, i've monitored (scoped) nRST,+3.3(PMIC_VOUT4) ,+3.3(VDD) from pmic, and i see that one

3.3(PMIC_VOUT4) is going down, and so nRST, so my chip will reset, and then reboot.(see pic)

I've tried this on BRK'Octavo board (STM32MP1 board with almost only Sdcard connector), and when I send poweroff command,

I don't either see nRST moving. I don't see the cycling of power supplies combined with nRST, like the image you show me.

It's a bit weird, if i have time, i will check this on a DK2 board. Maybe the nRST signal is internal on Octavo devices.

Anyway, thanks a lot, you save our next revision boards!

Apéro!

PatrickF
ST Employee

Hi,

note that eMMC NRST is not always required (it is even not enabled by default in the eMMC), in particular with STPMIC1 where there is a power cycle when NRST is activated (so, eMMC will do a internal power-on reset).

If VCCQ is connected to STM32MP1 VDD (and VCC to +3V3) it would work without this NRST issue. See our STM32MP157F-EV1 board.

Some pull-up are required on data/CLK/CMD lines to avoid eMMC over-consumption in STANDBY (when +3V3 is shutdown but not VDD).

0693W00000DnKVJQA3.pngRegards,

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Eldam
Senior

Indeed, datasheet says that nrst signal for our emmc is disabled by default.

Again, thanks for all the tips!

wish you good luck for answering others lost people!

PatrickF
ST Employee

Just forgot to mention that the STPMIC1 all supply power cycle upon NRST is the default behavior, but could be changed by SW individually for each buck or LDO (check "mask reset" in the STPMIC1 datasheet), but as it is not a non-volatile option, it should be written in STPMIC1 after each power up.

The default power-cycle is usually important (and safest) to be sure the boot Flash is reset in order to allow the platform to boot correctly (e.g. an SD-Card can only be reset with a power cycle after changed to UHS-I mode).

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.