Changing default BUCK3 voltage

[gil_he]

hello,
We will be using the OSD32MP157C-512M-BAA.
The default voltage for BUCK3 and BUCK4 is 3.3V.
I want to change it to 1.8V.
In the design, BYPASS_REG1V8 and VDDA1V8_REG pins connect to VDD, and will get 1.8V.
this is correct for a VDD=1.8V.
However, on first power-up of the system, 3.3V will be present there.
This will put VDDA1V8_REG in bypass mode, but will connect 3.3V (through the VDDA1V8_REG pin) to the USB HS PHY which is wrong.

How should I handle this?
Manually (or electrically) connect GND to BYPASS_REG1V8 and leave VDDA1V8_REG floating, change BUCK3 to 1.8V through the STM and once it is 1.8V, connect these two pins to VDD?

thanks
Gil

[gil_he]

hello,

Please ignore the first post on this thread and consider the following (I edited the post, but something went wrong):

We will be using the OSD32MP157C-512M-BAA.
The default voltage for BUCK3 and BUCK4 is 3.3V.
I want to change it to 1.8V.
In the design, BYPASS_REG1V8 and VDDA1V8_REG pins connect to VDD, and will get 1.8V.
This is correct for a VDD=1.8V.
However, on first power-up of the system, 3.3V will be present there by default.
This will put VDDA1V8_REG in bypass mode and will connect 3.3V (through the VDDA1V8_REG pin) to the USB HS PHY, which is wrong.

How should I handle this?
BYPASS_REG1V8 will connect to VDD, thus in bypass mode.
VDDA1V8_REG pin will be floating. Thus, VDDA1V8_REG is not powered and USB PLL (in USB HS PHY) will not be get its 1.8V.
VDD3V3_USBHS will be disabled on power-up by default (fulfil the “VDDA1V8_REG must be present before VDD3V3_USBHS” requirement)
BUCK3 will change to 1.8V through the STM and once it is 1.8V, connect VDD to VDDA1V8_REG pin (either power-down the system and do that, or electrically relay VDD to this pin).
Enable VDD3V3_USBHS and change its power-up state to the appropriate rank.

Is that a valid way?

Any better way to do that?

thanks
Gil

[Neeraj Dantu]

Gil,

You can reprogram the PMIC to set the output voltage of BUCK3 to 1.8V permanently. Please see https://octavosystems.com/app_notes/stpmic1-non-volatile-memory-programming-guide/ for a method to reprogram STPMIC. “NVM_BUCKS_VOUT_SHR”(https://www.st.com/resource/en/datasheet/stpmic1.pdf) can be used to set output of BUCK3.

Please also note that you will have to set PMIC outputs in TF-A device tree(https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.4-stm32mp/fdts/stm32mp15xx-dkx.dtsi#L102), U-Boot(https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/arch/arm/dts/stm32mp15xx-dkx.dtsi#L360) and Linux(https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi#L360).

Best,
Neeraj

[gil_he]

Hi Neeraj,

The situation I described is for a board with the SiP assembled on it.
Default BUCK3 voltage is 3.3V (on first power-up, before any programming) and the connections on the board are as I described (BYPASS_REG1V8 and VDDA1V8_REG pins connect to VDD=3.3V).
So, it will put VDDA1V8_REG in bypass mode and will connect 3.3V (on first power-up), through the VDDA1V8_REG pin, to the USB HS PHY, which is wrong (it should get 1.8V).

Will the guide you referred me to, answer this scenario?

thanks
Gil

• This reply was modified 2 years, 10 months ago by gil_he.

[Neeraj Dantu]

Gil,

This can be a little tricky. According to the PMIC programming document from ST(https://www.st.com/resource/en/application_note/dm00682242-the-stpmic1-ic-programming-guide-stmicroelectronics.pdf), the minimum circuitry needed for the PMIC re-programming is power input on VIN, VIO and I2C line connections.

Can you try pulling NRST LOW and seeing if the PMIC responds to I2C commands? NRST disables the power outputs. So, you should be able to program the PMIC if it responds to I2C commands. If this does not work, and you cannot change the circuit configuration to not connect VDD to VDDA1V8_REG, you could try letting it set to 3.3V by default. Although, it is not clear whether the part will survive this.

As described in the PMIC programming document linked above, we recommend adding some configuration around VDDA1V8_REG and BYPASS_REG1V8 to be able to program the PMIC during manufacturing.

Best,
Neeraj

[gil_he]

Hi Neeraj,

When connecting to the SIP through JTAG:
Can the NVM of the PMIC be programmed via JTAG?
Which SW can be used for that?

thanks
Gil

• This reply was modified 2 years, 10 months ago by gil_he.

[gil_he]

Hi Neeraj,

In addition to the above, if I hold NRST low and PMIC outputs are disabled, VDD (BUCK3) will also be disabled, thus I will not have VIO which is mandatory for PMIC NVM programming (VIO is connected to VDD internally in the SIP).

This is the first power-up of the SIP. Later power-ups will not need to do that.
1. BYPASS_REG1V8 is connected to GND.
VDDA1V8_REG is floating.
2. The system powers up.
3. Now, I am looking for a mechanism/method to do the following in the PMIC: disable VDD3V3_USBHS, change VDD (BUCK3) to 1.8V in the PMIC NVM.
How do you suggest I do that?
I can use an I2C header as described in dm00682242-the-stpmic1-ic-programming-guide-stmicroelectronics.pdf and program the PMIC NVM externally.
I can connect through JTAG to the SIP and access/program the PMIC NVM – is that feasible?
Any other way? What do you think?
4. Once VDD is changed to 1.8V in the NVM, I am powering the system off. Connecting BYPASS_REG1V8 and VDDA1V8_REG to VDD (resistors).
From now on, all power-ups are according to the PMIC NVM.

thanks
Gil

[Neeraj Dantu]

Gil,

“VIO is connected to VDD internally in the SIP” – Yes, this is a problem.

Since PMIC comes up by default according to the programming in NVM, you cannot stop the power up midway.

You can program the PMIC using ST’s Cube Programmer(https://www.st.com/en/development-tools/stm32cubeprog.html), but that requires the device to be powered up as well. There is no JTAG port on the PMIC, so programming through JTAG would need to be done through the M4.

We previously had success pulling NRST low and supplying VIO via VDD externally to re-program the PMIC. Please let us know here if you can try that with the current spin of your board.

Best,
Neeraj

[gil_he]

hello Neeraj,

1. According to STM32CubeProgrammer data, it supports debug through ST-LINK debug probe (JTAG).
I know the PMIC doesn’t have a JTAG interface, but it connects through I2C4 to the STM SOC, and that allows the SOC access to the PMIC NVM.
That is my path to the PMIC NVM. The STM32CubeProgrammer uses this path to access and program this NVM (via JTAG).
Am I correct?
Does using JTAG require BOOTn=100 or does the JTAG anyway takes control once a debug probe is connected at power up?

2. I see I2C4 is accessed through APB5 bus which is accessed by the AHB bus master, M4.
The DAP (JTAG/SWD) is accessed via the DAP bus which connects to M4.
Is that why M4 is being used for accessing the NVM?
The DAP (JTAG/SWD) is also accessed by the AXI bus master, A7.
Am I correct?
Is the STM32CubeProgramme JTAG access transparent to the user, or should I take ay design measures to support that?

3. Programming the PMIC NVM procedure:
– Allowing the system to power up fully.
– Either by an I2C header or STM32CubeProgrammer (via JTAG):
disable VDD3V3_USBHS (PMIC LDO4).
change VDD (BUCK3) to 1.8V
– VDDA1V8_REG gets 1.8V as an input (internally). Its output is not regulated but will not cause any damage or affects MTBF of the SIP. Is that correct?
– Power off. Connecting BYPASS_REG1V8 pin to VDD and connecting VDD externally to VDDA1V8_REG pin.
– Power on.
Is the procedure ok?

thanks
Gil

[Neeraj Dantu]

Gil,

Please take a look here: https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_STPMIC1_NVM_management. The page states that PMIC NVM programming is only supported in USB/serial boot mode.

If you want to, you can probably create an M4 program to flash the PMIC NVM, but this mode is not different from normal boot in terms of the power up of the PMIC and power rails.

Best,
Neeraj

[gil_he]

hello Neeraj,

I am re-opening this thread.

You wrote we can program the PMIC NVM using the STM32CubeProgrammer.

We ran the programmer (connected to the board via USB) and I did not find the PMIC NVM partition (identified by the reserved Id 0xF4).

Documentation states it is supported only in U-BOOT and since we are in the SiP boot stage (no FSBL, SSBL, etc), I guess we cannot see it.

Is there any other way I can view the PMIC NVM and program it? (besides using the M4).

I understand JTAG cannot help us here.

I2C perhaps? If yes, using which software?

This is my 1st question.

2nd Q: The reason I am asked the 1st Q, is that PMIC_VOUT4 outputs the wrong voltage in one of our boards (it worked fine and suddenly something changed).

I would like to see whether, somehow,  the PMIC NVM changed its content, thus a different voltage on PMIC_VOUT4.

Is anything like this happened to you?

Adding to that:

If a voltage is forced on PMIC_VOUt4 output before it is regulated (2.5V from another source): can it damage the PMIC_VOUT4 output stage?

thanks,

Gil

 

[Neeraj Dantu]

Gil,

on Q1: I believe this is linked above, but take a look at https://octavosystems.com/app_notes/stpmic1-non-volatile-memory-programming-guide/. The app note has scripts that you can run on PoecketBeagle(https://beagleboard.org/pocket) to interface with the PMCI inside OSD32MP1. This is done through connecting the I2C interface of the PMIC externally to the PocketBeagle.

You can also read registers from the PMIC directly if you are able to boot the board from the STM32MP1 core at u-boot command line or at Linux command line. See section 6.4.1 for BUCK control registers in PMIC datasheet(https://www.st.com/resource/en/datasheet/stpmic1.pdf).

on Q2: We did not experience a random change on VOUT4 like what you are describing. We do not recommend back-feeding any current on the PMIC output rails when they are not active. I would also read some of the status registers(Section 6.2 in the PMIC datasheet) to see if you can gain some information about the PMIC status and errors.

Best,

Neeraj

[gil_he]

hello Neeraj,

I connected the I2C port of the PMIC in our board (Pz4, Pz5 in the Octavo) to the Octavo RED evb to JP20, pins 3,5,6, which connect to I2C5 of the Octavo in the RED evb.

Our board is not running any code. Power-up and that’s it (no FSBL, SSBL, etc.).

We connected to the RED evb using SSH (to the IP of the RED). We used the I2C tools to detect and dump the registers of the I2C devices.

I was unable to read anything from the PMIC. Not from the faulty SiP (wrong PMIC_VOUT4) and not from a working SiP.

I2C detect did not find any slave devices on this bus. Then, I specifically searched for I2C address 0x33. Nothing there.

What was I doing wrong?

thanks

Gil

[Neeraj Dantu]

Gil,

1. Please make sure the GNDs for both board are connected.

2. Probe the SCL and SDA pins to see if they are pulled up to 3.3V.

3. Probe the SCL and SDA activity when you exercise the i2cdetect command. Can you see activity?

4. Please make sure the right I2C device is being used. The Linux I2C numbering can be different from the hardware I2C numbering.

best,

Neeraj

[Author]

Posts