[gil_he]

Hi Neeraj,

Mystery solved.

I think.

 

I removed the STUSB1600.

I measured the ALERT# pin as I wrote to you and found it behaves as nothing is connected to it.

Plus, UBOOT commands did not affect it.

 

So, I opened the layout file.

And it is DIFFERENT than my schematics.

My last action in the layout was to change the interrupt signal from GPIOI11 to GPIOE8.

The layout guy did it. And I approved the change.

BUT: he produced final production files from the version before that change.

So, the ALERT# pin connects to GPIOI11 and not GPIOE8.

And that explains everything.

 

We will produce a new image, using GPIOI11 and test it.

 

I will update.

 

Thank you for your patience and time !!!

 

Gil

• This reply was modified 2 weeks, 2 days ago by gil_he.

[gil_he]

Hi Neeraj,

An addition:

GPIOE8 is defined as a GPIO with a bias-pull-up.

 

stusb1600_pins_mx: stusb1600-0 {

pins {

pinmux = <STM32_PINMUX(‘E’, 8, GPIO)>

bias-pull-up;

 

In the &i2c4, stusb1600 child node, it is defined as interrupt-parent:

 

typec: stusb1600@28 {

compatible = “st,stusb1600”;

reg = <0x28>;

interrupt-parent = <&gpioe>;

 interrupts = <8 IRQ_TYPE_LEVEL_LOW>;

pinctrl-0 = <&stusb1600_pins_mx>;

 

What is the default behavior of GPIOE8 in UBOOT? input? output?

 

I removed the STUSB1600 from the board.

So, GPIOE8 from the SiP is not connected to anything.

If it is an input, I should measure High since it has an internal pull-up.

I am not measuring a High. I am measuring a low voltage between 0.2-0.3V. Not fixed. Like a not-defined pin.

When I am inputting gpio clear or gpio set commands on UBOOT CLI, I get:

STM32MP> gpio clear GPIOE8

gpio: pin GPIOE8 (gpio 72) value is 0

STM32MP> gpio set GPIOE8

gpio: pin GPIOE8 (gpio 72) value is 1

 

Still, I measure the same 0.2-0.3V.

The commands have no effect.

 

It think the issue I have is with GPIOE8 and not the STUSB1600.

 

STUSB1600 ALERT# is not penetrating the SoC/system and not reaching the driver.

I am also unable to control PE8 from UBOOT CLI.

 

What is malfunctioning here?

 

thanks,

Gil

• This reply was modified 2 weeks, 2 days ago by gil_he.
• This reply was modified 2 weeks, 2 days ago by gil_he.

[gil_he]

Hi Neeraj,

Clarifications:

1. I see a Low level on the ALERT# pin.

The dts file defines an IRQ_TYPE_LEVEL_LOW, so we are fine in that aspect.

However, I never saw the ALERT# going High. No activity there. Only Low.

And, all the interrupts are masked (reg 0x0c=0x3f). Changing it to enable them didn’t make a difference.

One question to you on that: Octavo uses the same STUSB1600. Why do you define the ALERT# as IRQ_TYPE EDGE_FALLING ?

2. So, ALERT# seems to work fine. Low level is there.

However, the system sees High on PE8 (read it through UBOOT CLI).

Perhaps this is our problem.

Why do I measure one level on the pin and UBOOT sees another level?

thanks

Gil

[gil_he]

Hi Neeraj,

I face two symptoms:

1. The STUSB1600 is not generating an interrupt when I connect/disconnect the USB cable.

An “interrupt” means an activity on the ALERT# signal.

The device does respond, correctly, to a connect/disconnect with all its internal registers. They reflect it accurately.

Still, no ALERT# change.

If 0x0c is to blame, I changed its setting, so the interrupts are unmasked.

Still, I don’t see any change in the scope when I connect/disconnect the USB cable.

2. Reading PE8 via UBOOT is not returning the value I measure with a scope.

 

These two symptoms, I assume, are connected to the issue we face: dynamic change of the USB connection between Host and device is not detected.

When I connect, on power-up, a Host or device, it is detected perfectly.

Then, when I disconnect and connect the other type: Nothing.

 

thanks,

Gil

 

 

[gil_he]

hello Neeraj,

The USB controller, STUSB1600 hasn’t changed between the two kernel versions.

The USB implementation, in general, hasn’t changed.

So, why should the GPIO type and IRQ_TYPE change between kernel versions?

It makes sense to use the GPIO type as GPIO and not ANALOG, since in ANALOG, the weak pull-up and pull-down resistors are disabled by hardware and we use this internal pull-up.

With regard to IRQ_TYPE, it depends on the ALERT# signal definition in the STUSB1600, which I could not find in the datasheet.

The Linux kernel we use is 5.10.

What do you suggest we do?

Thanks,

Gil

 

[gil_he]

Hi Neeraj,

On our system, VDD pin of the STUSB1600 is connected to 5V (same 5V that power the Octavo SiP).

The same connection exists in the Octavo DK2 ref design (attached picture).

We don’t have a Sink capability, in the sense that an external USB Host powers our system.

We can act as a USB Host with power sourcing and as a USB Device.

So, we don’t have a power Sink circuit (as the RED has).

I attached also our circuit design.

What do you think?

Thanks,

Gil

Attachments:

1. 

   Octavo_DK2_ref_USB_C_DRP.png
   

2. 

   Tabor_USB_C_DRP.png
   

[gil_he]

Hi Neeraj,

Adding some data:
I changed STUSB1600 register 0x0c to 0x93 to unmask the interrupts.

 

I reset the board with a USB Host connected to it.

All registers’ values reflect the state correctly.

 

I disconnected the USB Host.

All registers’ values reflect the state correctly.

 

I connected a USB Device.

All registers’ values reflect the state correctly.

 

But, the ALERT# pin (interrupt) is not changing. Scope shows Low level all the time.

No activity whatsoever.

And gpio input GPIOE8 reads High.

STM32MP> gpio input GPIOE8

gpio: pin GPIOE8 (gpio 72) value is 1

 

Maybe something is wrongly defined with GPIO PE8.

I sent you the dts files.

What are we missing here?

 

Thanks,

Gil

• This reply was modified 3 weeks, 4 days ago by gil_he.
• This reply was modified 3 weeks, 4 days ago by gil_he.
• This reply was modified 3 weeks, 4 days ago by gil_he.
• This reply was modified 3 weeks, 4 days ago by gil_he.

[gil_he]

Hi Neeraj,

I checked STUSB1600 registers from UBOOT CLI, in different USB connection scenarios.

All registers, but one, seem to be correct. The device registers reflect correctly a dynamic connect/disconnect on its USB port

One thing that is not defined correctly in the STUSB1600, for all scenarios:

Register 0x0c = 0xf3 which means all interrupts are masked.

So, when we dynamically connect/disconnect a Host or device to our system, the STUSB1600 will not issue an interrupt.

How do we correct that?

thanks,

Gil

 

[gil_he]

Hi Neeraj,

I checked GPIOE8 after power up and it reads Low (via UBOOT CLI).

After some time I checked again and it reads High (few minutes, maybe 10 minutes).

Nothing changed in the setup. Scope read 0V the entire time.

Can you perform the same?

thanks,

Gil

• This reply was modified 1 month ago by gil_he.

[gil_he]

Hi Neeraj,

I agree.

There shouldn’t be any discrepancy.

But, there is.

What is wrong here?

Why do the GPIO measurement and GPIO I2C read give different results?

thanks,

Gil

[gil_he]

Hi Neeraj,

Thank you.

Can you please read what I enclosed below and comment on that? (from your knowledge).
(1)
My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.
So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

(2)
Then you wrote “In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.”
I assume this is another justification to remove this line from the TF-A dts.

(3)
Can you describe what this patch does?
(From you knowledge of the patch syntax, if you are familiar with it). I enclosed the patch.

thank you

Gil

• This reply was modified 4 months, 2 weeks ago by gil_he.

Attachments:

1. 0591c8f.diff_.zip

[gil_he]

Hi Neeraj,

I looked into the links you sent.

I compiled and sent few questions to the person who submitted the patch in ST.

That was five days ago and no reply from him.

Please take a look and see if you can assist.

************************************************************************
We encountered this issue just recently. Every few power-ons, the system is stuck and we get the messages as described at the beginning of the thread. Resetting the PMIC / STM32MP153C solves this.

At first you suggested to remove the line for vmmc-supply from the TF-A dts.

My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.

So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

Then you wrote “In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.”

I assume this is another justification to remove this line from the TF-A dts.

In my case, our custom board connects v3v3 (BUCK4) to both vmmc and vqmmc supplies.

So, should I remove both lines (vmmc-supply = <&v3v3>; vqmmc-supply = <&v3v3>) from the TF-A dts?

Then, you wrote: “After internal discussions, we will deploy a correction that will have the same effect as the previous solution. So you can go on with it on your side.”

And, suggested a fix: a patch, to be applied to “regulator_core.c” (a file in the TF-A package).

Can you describe what this patch does?

What do you suggest we do? Apply the patch or modify the TF-A dts file?

*****************************************************************

thank you

Gil

• This reply was modified 4 months, 3 weeks ago by gil_he.

[gil_he]

hello Neeraj,

RANK 0 voltages, that we actively use, include BUCK2 (VDD_DDR) and the voltages that derive from it, LDO3/VTT_DDR and VREF_DDR.

We don’t use the other power rails that are RANK 0: LDO1, LDO2, LDO6.

However, I measure 0V on all of them.

This “erratic” behavior was observed on at least 4-5 boards (out of the 18 we assembled).

We use an eMMC Flash which has FSBL, SSBL, Linux, etc., on it.

I managed to capture the boot log when the issue happens.

Enclosed a text file with failing (problematic power-up) and successful boot logs.

I can understand why RANK 0 voltages are not there. It didn’t reach the place where they are intialized and enabled.

I am not able to accurately pin point where, during boot, the system fails.

Is it during the SoC PROM execution?

Was it able to load FSBL1 from the eMMC Flash?

What is CMD13?

Is everything we see in the boot log is a result of the SoC running its PROM code?

Meaning initial access to eMMC fails?

thanks,

Gil

 

• This reply was modified 5 months ago by gil_he.
• This reply was modified 5 months ago by gil_he.
• This reply was modified 5 months ago by gil_he.

Attachments:

1. power_up_log.txt

[gil_he]

Hi Michal,

I am thinking:

The FSBL initializes the clock and DDR, then loads the SSBL into the DDR and executes it.

Is there a known sequence that the FSBL follows when it initializes, before loading the SSBL?

Maybe we fail in some early stage of the FSBL init (clock initialization for example) and do not reach the stage where the DDR and DDR power (BUCK2) are initialized, and that is why BUCK2 is not defined as 1.35V and/or is not turned on?

thanks,

Gil

 

• This reply was modified 5 months, 1 week ago by gil_he.

[gil_he]

Hi Michal,

Thank you for the prompt response.

So, we have the ROM code in the STM32MP that loads the FSBL, from the eMMC flash, in the internal RAM and executes it.

the FSBL initializes the clock and DDR, then loads the SSBL into the DDR and executes it.

In our case, BUCK2=0V (VDD_DDR).

FSBL should change the default voltage to 1.35V and enable it. I assume it does that via I2C4.

The TF-A dts file you shared is very similar to what we use (I attached what we use).

Is there any difference between the TF-a dts files that might cause this issue?

It seems we have something marginal here since it only happens once every 5-10 power ups.

In addition, NRST solves this.

NRST resets the ST as well as the STPMIC1.

thanks,

Gil

 

• This reply was modified 5 months, 1 week ago by gil_he.
• This reply was modified 5 months, 1 week ago by gil_he.

Attachments:

1. tf-a.zip

[Author]

Posts