RE: UCMCx Client Driver for USB-C

Hi all,

Im not writing the custom driver .

Here one of our team updating the firmware for a chip which supports the
power delivery which inbox driver is using in windows 10.

I’m getting the yellow bank which shows the power device failure.

Ucmusci.sys is a connector manager driver uses the USB type c device.

In windows 10 if the inbox driver were in yellow bank or something happened
it doesn’t boot to windows normally also it were scrolling.

In windows 10 machine it doesn’t have last known good configuration also.

How I can move or how I can store the last known good configuration ?

How I can trace the error if doesn’t move to good configuration using
windbg whether the inbox driver ucmusci.sys has lot of information of print
log which I can see using windbg

Is there how I can move to good configuration in windows 10 ?

If suppose it doesn’t boot to windows normally ?

Windows automatic repair /safe mode also doesn’t boot to windows 10 ?

What are the hardware require for USB type c connector to get certified for
the inbox driver ?

What is the hardware requirements for hlk test ?

Is Mutt device is essential for this ?

Regards,
Prabhakar v
On 4 Jun 2016 7:02 a.m., “Tran Phuc Khanh” wrote:

> Thanks Vivek,
>
> My system have no EC.
>
> I’m contacting with Intel for SMBUS controller about the access.
>
> Thanks,
> KHANH
> On Jun 4, 2016 08:26, “Vivek Gupta” wrote:
>
>> Hi Khanh,
>>
>> You seem to be on the right path as far as Type C/PD is concerned. I am
>> assuming that the target system doesn’t have an EC; I ask because there is
>> an easier solution for EC based type c systems.
>>
>> However, your issue is not related to type c; it is related to the
>> discovery of the device on SMBUS. I think you will need to consult the
>> owner of the SMBUS controller driver for that.
>>
>> Thanks,
>> Vivek
>> ------------------------------
>> From: xxxxx@gmail.com
>> Date: Thu, 2 Jun 2016 09:33:40 +0700
>> Subject: Re: [ntdev] UCMCx Client Driver for USB-C
>> To: xxxxx@lists.osr.com
>>
>> Hi Tim,
>>
>> Thanks for your reply.
>>
>> We have two rear USB type C ports with thunderbolt support. The ports
>> also support charging (dual role) by using Power Delivery(PD) device. The
>> PD device connect to PCH SMBUS interface.
>>
>> As I understand for UCMCx Client Driver implement, we will need install
>> the driver on PD device. That why our driver need to access to PCH SMBUS
>> to enumerate device info, am I wrong here?
>>
>> Thanks,
>> KHANH
>>
>>
>>
>> On Thu, Jun 2, 2016 at 7:10 AM, Tim Roberts wrote:
>>
>> Tran Phuc Khanh wrote:
>> >
>> > I’m writing a UCMCx Client Driver for USB-C as
>> > specs: https://msdn.microsoft.com/en-us/library/windows/hardware/
>> mt188011(v=vs.85).aspx
>> > https:>> hardware/mt188011%28v=vs.85%29.aspx>
>> >
>> > In my case: The devices use I2C pins, I2C_1 PIN connect to Thunder
>> > bolt I2c Interface; I2C_2 PIN connect to PCH SMBUS interface.
>>
>> I’m rather confused by your post. There are no I2C pins in a USB-C
>> connector, nor in a Thunderbolt connector. Further, each I2C bus
>> requires two pins, not just one. Can you try to describe your
>> configuration in more detail?
>>
>>
>> > I tried to enumerate SMBUS information in my driver follow the
>> > specs: http://smbus.org/specs/smbus_driver_ext_arch10.pdf but got NOT
>> > FOUND result. My device is using Windows 10 with Intel Sky-lake.
>>
>> This is not an easy area to deal with. The SMBus has traditionally been
>> reserved for the BIOS, so drivers don’t play there. What information
>> were you trying to get? Are you quite sure that your SMBus peripherals
>> are enumerated in your ACPI DSDT?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: http:>> showlists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>>
>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online at
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: http:>> showlists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></http:></https:>

Prabhakar V wrote:

Here one of our team updating the firmware for a chip which supports
the power delivery which inbox driver is using in windows 10.

I’m getting the yellow bank which shows the power device failure.

Ucmusci.sys is a connector manager driver uses the USB type c device.

It managed the USC Type C connector. It isn’t really a device, in the
normal USB sense.

In windows 10 if the inbox driver were in yellow bank or something
happened it doesn’t boot to windows normally also it were scrolling.

In windows 10 machine it doesn’t have last known good configuration also.

How I can move or how I can store the last known good configuration ?

We keep extracting one tiny bit of information at a time here. If your
firmware load has screwed up the USB stack, then it’s possible that you
have disabled the entire host controller. In that case, your keyboard
and mouse will not operate to scroll the menus. If your computer has a
second USB controller, or some USB 2 ports, you might be able to plug
your keyboard in there.

What are the hardware require for USB type c connector to get
certified for the inbox driver ?

You have to follow the spec. If your firmware load has caused some
standard request to fail, or has caused some delay to be too long, then
the inbox driver will reject it. YOU need to figure out what you have
broken. You still haven’t told us, for example, whether it is the act
of firmware loading that causes the failure (which would imply some
delay problem), or is it that the new firmware itself is broken? Once
you load your firmware, does it continue to fail forever? Or does it
recover on next boot?

What is the hardware requirements for hlk test ?

Is Mutt device is essential for this ?

If you are testing a host controller, then yes, you will absolutely
require the MUTT device.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I followed the link "
https://msdn.microsoft.com/en-us/library/windows/hardware/mt710944(v=vs.85).aspx
"

When i use the UcsiControl.exe command line utility with the command
“*UcsiControl.exe
Send 0 1”*

*I got the error as " exception with code: 0x800700aa"*

*I could not find out the trace of error why it failed.*

On Fri, Jan 27, 2017 at 3:33 AM, Tim Roberts wrote:

> Prabhakar V wrote:
> >
> > Here one of our team updating the firmware for a chip which supports
> > the power delivery which inbox driver is using in windows 10.
> >
> > I’m getting the yellow bank which shows the power device failure.
> >
> > Ucmusci.sys is a connector manager driver uses the USB type c device.
> >
>
> It managed the USC Type C connector. It isn’t really a device, in the
> normal USB sense.
>
>
> > In windows 10 if the inbox driver were in yellow bank or something
> > happened it doesn’t boot to windows normally also it were scrolling.
> >
> > In windows 10 machine it doesn’t have last known good configuration also.
> >
> > How I can move or how I can store the last known good configuration ?
> >
>
> We keep extracting one tiny bit of information at a time here. If your
> firmware load has screwed up the USB stack, then it’s possible that you
> have disabled the entire host controller. In that case, your keyboard
> and mouse will not operate to scroll the menus. If your computer has a
> second USB controller, or some USB 2 ports, you might be able to plug
> your keyboard in there.
>
>
> > What are the hardware require for USB type c connector to get
> > certified for the inbox driver ?
> >
>
> You have to follow the spec. If your firmware load has caused some
> standard request to fail, or has caused some delay to be too long, then
> the inbox driver will reject it. YOU need to figure out what you have
> broken. You still haven’t told us, for example, whether it is the act
> of firmware loading that causes the failure (which would imply some
> delay problem), or is it that the new firmware itself is broken? Once
> you load your firmware, does it continue to fail forever? Or does it
> recover on next boot?
>
>
> > What is the hardware requirements for hlk test ?
> >
> > Is Mutt device is essential for this ?
> >
>
> If you are testing a host controller, then yes, you will absolutely
> require the MUTT device.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Prabhakar V wrote:

I followed the link
https://msdn.microsoft.com/en-us/library/windows/hardware/mt710944(v=vs.85).aspx
https:
>
> When i use the UcsiControl.exe command line utility with the command
> "UcsiControl.exe Send 0 1"
> *
> *
> I got the error as " exception with code: 0x800700aa"
> *
> *
> I could not find out the trace of error why it failed.

80070xxx errors are, in general, a COM-compatible wrapper of the
standard Windows error codes in winerror.h. You can look up the error
by removing the 8007 part.

In this case, 0xaa is 170 which is ERROR_BUSY. Can you send the Get
Capability command, “0 6”?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</https:>