OSD32MP153C GPIO read

[gil_he]

hello,

We implemented the STUSB1600 in our board using the OSD32MP153C-512M-BAA.

Its ALERT# pin is connected to PE8, which is defined as an interrupt for the SoC.

Implementation is the same as ST DK2 eval board (except we use PE8 and ST uses PI11).

When I measure the voltage on PE8, I read Low.

When I read the value using an I2C4 read command, from the UBOOT CLI, I get High.

How can that be?

From UBOOT CLI, I use:

i2c dev 0

gpio input GPIOE8

Attached find the UBOOT device tree files.

thanks,

Gil

• This topic was modified 1 month, 2 weeks ago by gil_he.

Attachments:

1. stm32mp157c-osd32mp1-brk_UBOOT.zip

[Neeraj Dantu]

Gil,

The device tree attached shows that GPIOE8 has the internal pull-up enabled. However, there should not be a measurement discrepancy between u-boot CLI and measurement.

Here is an interaction I just had on the CLI to show status of GPIOE8 on the RED board:

STM32MP> gpio input GPIOE8 gpio: pin GPIOE8 (gpio 72) value is 0 STM32MP> gpio status GPIOE8 Bank GPIOE: GPIOE8: input: 0 [ ]

1 2 3 4 5 6 7 8 9

STM32MP> gpio input GPIOE8   gpio: pin GPIOE8 (gpio 72) value is 0   STM32MP> gpio status GPIOE8   Bank GPIOE:   GPIOE8: input: 0 [ ]

 

 

[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,

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 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

 

[Neeraj Dantu]

Gil,

I am investigating and will report back.

Best,

Neeraj

[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.

[Neeraj Dantu]

Gil,

Can you check the connection of VDD(pin 24) of USBC1600? For OTG functionality, this needs to be connected to mid way point of the USB-C sink power path. On the RED board, I needed to change the jumper position of JP21 in order for OTG function to work. I was able to verify both sink and source modes as well as see the interrupt on ALERT pin when something is connected.

I am still unsure why you are reading different value of GPIO. My suspicion is that there is an issue with U-Boot CLI handling this claimed pin. I will check further, but I don’t think anything is wrong based on the functionality all working.

Best,

Neeraj

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

[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
   

[Neeraj Dantu]

Gil,

The attached circuit configuration should work correctly. A couple of changes I noticed in device tree from ST’s DK board: the GPIO pin used was declared as ANALOG until 5.10 and has changed to GPIO since 5.15 kernel. The IRQ_TYPE definition in the device tree has also changed since 5.10. I have not looked at the driver changes, can you check which version of the kernel you are using and try the configurations that match?

Best,
Neeraj

[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

 

[Neeraj Dantu]

Based on the description of what is happening so far, USB1600 is producing an interrupt on the ALERT signal, but you do not see it detected on the kernel side. Is that correct?

If so I suggest:

Look at kernel messages for USB with “dmesg | grep usb” and make sure the IRQ is registered. The messages I see when I do this on OSD32MP1-RED:[    0.122420] usbcore: registered new interface driver usbfs1# dmesg | grep usb

[    0.122513] usbcore: registered new interface driver hub

[    0.122590] usbcore: registered new device driver usb

[    1.692445] usbcore: registered new interface driver pegasus

[    1.692533] usbcore: registered new interface driver asix

[    1.692617] usbcore: registered new interface driver ax88179_178a

[    1.692688] usbcore: registered new interface driver cdc_ether

[    1.692771] usbcore: registered new interface driver smsc75xx

[    1.692853] usbcore: registered new interface driver smsc95xx

[    1.692919] usbcore: registered new interface driver net1080

[    1.692984] usbcore: registered new interface driver cdc_subset

[    1.693058] usbcore: registered new interface driver zaurus

[    1.693154] usbcore: registered new interface driver cdc_ncm

[    1.696494] usbcore: registered new interface driver usb-storage

[    1.710775] usbcore: registered new interface driver usbhid

[    1.710792] usbhid: USB HID core driver

[    3.323124] vdd_usb: supplied by vin

[    3.550022] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0

[    3.589060] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator

[    3.595971] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator

[    3.738244] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM

[    3.746814] dwc2 49000000.usb-otg: DWC OTG Controller

[    3.750562] dwc2 49000000.usb-otg: new USB bus registered, assigned bus number 1

[    3.757906] dwc2 49000000.usb-otg: irq 98, io mem 0x49000000

[    3.773879] ehci-platform 5800d000.usbh-ehci: EHCI Host Controller

[    3.778756] ehci-platform 5800d000.usbh-ehci: new USB bus registered, assigned bus number 2

[    3.787902] ehci-platform 5800d000.usbh-ehci: irq 71, io mem 0x5800d000

[    3.817661] ehci-platform 5800d000.usbh-ehci: USB 2.0 started, EHCI 1.00

[    3.832919] ohci-platform 5800c000.usbh-ohci: Generic Platform OHCI controller

[    3.838833] ohci-platform 5800c000.usbh-ohci: new USB bus registered, assigned bus number 3

[    3.847510] ohci-platform 5800c000.usbh-ohci: irq 61, io mem 0x5800c000

[   27.274310] usb0: HOST MAC a0:39:f4:d0:0d:9a

[   27.284648] usb0: MAC ee:42:52:59:6b:25

[   27.287112] dwc2 49000000.usb-otg: bound driver configfs-gadget

[   34.397708] usb33: supplied by vdd_usb

IRQ 98 is what I see trigger when there is a device plugged in.

You can “cat /proc/interrupts” to get the interrupt details and # triggered. 98 should look like the following:

” 98:       3493          0  stm32-exti-h-direct  44 Level     49000000.usb-otg, 49000000.usb-otg, dwc2_hsotg:usb1″

 

If I am wrong and STUSB1600 is not generating the alert signal, you mentioned above that the mask register 0x0C does not look right. I am not sure what the reason for this would be, but you could modify this register by issuing a “i2cset” command from linux command line and see if that fixes the interrupt generation.

 

Best,

Neeraj

 

[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]

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,

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,

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.

[Neeraj Dantu]

Gil,

Glad you found the issue and appreciate the update!

Best,

Neeraj

[Author]

Posts