پیام Request در USB PD؛ ساختار RDO، انتخاب PDO و حالتهای آزمون BIST
در مقاله دهم، میبینیم Sink چگونه یکی از تواناییهای Source را با Request Data Object انتخاب میکند، جریان یا توان موردنیاز را مینویسد، Capability Mismatch را اعلام میکند و در پایان چگونه پیام BIST یک Port را وارد حالت آزمون PHY میکند.
دامنه و منبع این مقاله
این مقاله فقط بر Sections 6.4.2 و 6.4.3، صفحات ۱۵۵ تا ۱۶۱ سند USB Power Delivery Specification, Revision 3.2, Version 1.1, 2024-10 استوار است. پیامهای Vendor Defined، Discover Identity، شناسایی کابل و مدیریت Mode از Section 6.4.4 آغاز میشوند و برای مقاله ۱۱ محفوظ ماندهاند.
Advertisement بدون Request به قرارداد تبدیل نمیشود
Source گزینهها را Advertise میکند؛ Sink یکی از آنها را با RDO انتخاب و مقدار مصرف خود را محدود میکند.
در مقاله ۹ دیدیم Source_Capabilities آرایهای مرتب از PDOها و APDOهاست. آن پیام فقط میگوید Source چه گزینههایی دارد؛ هنوز مشخص نمیکند Sink کدام گزینه را میخواهد. در مرحله Request مذاکره SPR، Sink باید به جدیدترین Source_Capabilities پاسخ دهد و دقیقاً یک Sink Request Data Object بفرستد. این Object هم جایگاه PDO منتخب و هم پارامترهای درخواست را حمل میکند.
Source پس از دریافت Request فقط با یکی از سه Control Message منطقی پاسخ میدهد: Accept، Wait یا Reject. Accept یعنی درخواست قابل اجراست، Wait یعنی Source فعلاً آماده نیست و Reject یعنی درخواست پذیرفته نمیشود. GoodCRC همچنان فقط دریافت صحیح Packet را تأیید میکند؛ بنابراین در Trace باید GoodCRC را از نتیجه واقعی Request جدا نشان داد.
قالب RDO به نوع PDO منتخب وابسته است. Fixed و Variable یک قالب مشترک دارند؛ Battery بهجای جریان از توان استفاده میکند؛ PPS ولتاژ خروجی را با گام 20mV و جریان را با واحد 50mA میخواهد؛ و AVS ولتاژ مؤثر 100mV و جریان 50mA را حمل میکند. اگر Decoder ابتدا نوع PDO مرجع را پیدا نکند، ممکن است همان بیتها را با واحد یا معنای اشتباه نمایش دهد.
یک RDO در Request
Request Message دقیقاً یک Sink Request Data Object حمل میکند.
Object Position
این چهار بیت، جایگاه PDO یا APDO منتخب را در آخرین Capabilities تعیین میکنند.
پاسخ Source
نتیجه منطقی درخواست با یکی از این سه پیام اعلام میشود.
Request Message دقیقاً چه کاری انجام میدهد؟
در SPR، Sink هنگام Request Phase یک Request Message را در پاسخ به آخرین Source_Capabilities ارسال میکند. عبارت «آخرین» مهم است: Object Position باید به فهرستی ارجاع دهد که همین حالا مبنای مذاکره است. اگر Source مجموعه تازهای Advertise کرده باشد، نگهداشتن شماره موقعیت از مجموعه قبلی میتواند گزینهای متفاوت یا نامعتبر را هدف بگیرد.
RDO سطح توان درخواستی را نیز ثبت میکند. برای مثال، اگر Fixed PDO منبع 9V @ 1.5A را عرضه کند ولی Sink تنها 9V @ 0.5A بخواهد، Operating Current باید مقدار 50 داشته باشد، زیرا واحد این فیلد 10mA است: 50 × 10mA = 500mA. Sink مجبور نیست تمام جریان Advertiseشده را درخواست کند؛ سقف Source حد بالا است، نه مقدار اجباری مصرف.
همین خانواده RDO در EPR_Request نیز استفاده میشود. تفاوت در Message و محدوده Object Position است. اگر Source در EPR Mode یک Request معمولی دریافت کند باید Hard Reset را آغاز کند؛ در EPR مذاکره باید با EPR_Request انجام شود. این قاعده برای Analyzer یک بررسی State-aware مهم است.
قاعده طلایی Decode
ابتدا Object Position را به آخرین Source_Capabilities نگاشت کنید، نوع PDO منتخب را بیابید و فقط پس از آن قالب RDO را انتخاب کنید. Decode مستقیم B19..0 بدون شناخت PDO مرجع ممکن است Current را Power یا Output Voltage را فیلدی دیگر تفسیر کند.
Fixed و Variable RDO؛ قالب مشترک جریانمحور
Fixed Supply و Variable Supply از قالب مشترک Table 6.23 استفاده میکنند. نیمه بالایی Object، Position و Flagهای توانایی Sink را حمل میکند؛ نیمه پایین دو مقدار Current دارد. Maximum Operating Current از نظر عملکردی منسوخ شده، اما برای سازگاری عقبرو باید برابر Operating Current نوشته شود.
ساختار بیتهای RDO مشترک برای Fixed Supply و Variable Supply.
| بیتها | فیلد | معنا و واحد |
|---|---|---|
| B31..28 | Object Position | شماره PDO یا APDO مرجع |
| B27 | GiveBack | Deprecated؛ باید صفر باشد |
| B26 | Capability Mismatch | اعلام ناکافیبودن تواناییهای فعلی Source |
| B25 | USB Communications Capable | توانایی ارتباط روی خطوط داده USB |
| B24 | No USB Suspend | درخواست ادامه Explicit Contract هنگام Suspend |
| B23 | Unchunked Extended Messages | پشتیبانی از Extended Message بدون Chunk |
| B22 | EPR Capable | توانایی Sink برای کار در EPR Mode |
| B21..20 | Reserved | باید صفر باشد |
| B19..10 | Operating Current | Raw × 10mA |
| B9..0 | Maximum Operating Current | همان مقدار Operating Current، با واحد 10mA |
مثال: درخواست 9V / 0.5A
اگر PDO شماره ۲ گزینه 9V را ارائه کند، Object Position برابر 0010b است. Operating Current و Maximum Operating Current هر دو باید 50 نوشته شوند. با فرض صفر بودن Flagهای اختیاری، همین Position و دو مقدار Current هسته RDO را میسازند.
Maximum به معنی درخواست بیشتر نیست
این فیلد از نظر عملکردی Deprecated است و استاندارد به Source توصیه میکند آن را نادیده بگیرد. Sink برای سازگاری با Sourceهای قدیمی موظف است آن را دقیقاً برابر Operating Current بگذارد؛ نوشتن یک سقف بزرگتر رفتار جدیدی ایجاد نمیکند.
Battery، PPS و AVS؛ سه قالب متفاوت RDO
همه این قالبها Object Position و Flagهای اصلی را حفظ میکنند، اما بیتهای پارامتر درخواست تفاوت دارند. Battery بر حسب Power است؛ PPS و AVS ولتاژ خروجی و Operating Current را مینویسند. Reservedها در هر قالب باید صفر باشند و نباید بهعنوان فضای آزاد برای داده اختصاصی استفاده شوند.
ساختار Battery RDO و فیلدهای Operating Power و Maximum Operating Power.
ساختار PPS RDO با Output Voltage در واحد 20mV و Operating Current در واحد 50mA.
ساختار AVS RDO با کد ولتاژ 25mV، گام مؤثر 100mV و جریان 50mA.
Battery RDO — Table 6.24
- B31..28: Object Position
- B27..22: GiveBack و Flagها
- B21..20: Reserved و صفر
- B19..10: Operating Power
- B9..0: Maximum Operating Power
واحد هر دو Power برابر 250mW است. Maximum Operating Power نیز Deprecated است و باید برابر Operating Power نوشته شود.
PPS RDO — Table 6.25
- B31..28: Object Position
- B27: Reserved و صفر
- B26..22: Flagها
- B21: Reserved و صفر
- B20..9: Output Voltage با واحد 20mV
- B8..7: Reserved و صفر
- B6..0: Operating Current با واحد 50mA
AVS RDO — Table 6.26
- B31..28: Object Position
- B27: Reserved و صفر
- B26..22: Flagها
- B21: Reserved و صفر
- B20..9: Output Voltage با کد 25mV
- B8..7: Reserved و صفر
- B6..0: Operating Current با واحد 50mA
چرا AVS با 25mV نوشته شده ولی گام مؤثر 100mV است؟
در AVS، B20..9 از نظر عددی واحد 25mV دارد، اما دو بیت کمارزش این فیلد باید صفر باشند. صفر بودن آن دو بیت تنها مضربهای چهار را باقی میگذارد؛ 4 × 25mV برابر 100mV است. Decoder بهتر است هم مقدار خام و هم ولتاژ مؤثر 100mV را گزارش کند تا این قاعده پنهان نشود.
| نوع RDO | پارامتر اصلی | واحد ولتاژ | واحد جریان/توان | نکته |
|---|---|---|---|---|
| Fixed / Variable | Operating Current | از PDO منتخب | 10mA | Maximum برابر Operating |
| Battery | Operating Power | از PDO منتخب | 250mW | Maximum برابر Operating |
| PPS | Voltage + Current Limit | 20mV | 50mA | Source محدودکننده جریان دارد |
| AVS | Voltage + Current | 100mV effective | 50mA | Sink مسئول عدم تجاوز از جریان است |
Object Position؛ شماره گزینه، نه نوع ولتاژ
Object Position به جایگاه Object در Source_Capabilities یا EPR_Source_Capabilities اشاره میکند. مقدار 0001b همیشه اولین PDO پس از Header است و چون ساخت Capabilities با vSafe5V آغاز میشود، به Fixed 5V PDO اشاره دارد. مقدار 0010b Object بعدی و به همین ترتیب Positionهای بالاتر Objectهای بعدی را انتخاب میکنند.
مقادیر 0001b تا 0111b فقط برای SPR (A)PDOها هستند. این گزینهها میتوانند با Request یا EPR_Request درخواست شوند. Positionهای 1000b تا 1011b فقط به EPR (A)PDOها اشاره میکنند و باید با EPR_Request انتخاب شوند. اگر Request معمولی Position بزرگتر از 0111b داشته باشد، Source باید Hard Reset بفرستد.
بنابراین Position را نباید با «پروفایل 9V» یا «PPS» نامگذاری ثابت کرد. شماره ۲ در یک Advertisement ممکن است 9V Fixed باشد و در Advertisement بعدی به گزینه دیگری اشاره کند. Analyzer باید Snapshot آخرین Capabilities را کنار هر RDO نگه دارد و رابطه Position را در همان Snapshot حل کند.
PDO نخست
همیشه Fixed Supply 5V در Capabilities است.
محدوده SPR
ارجاع به SPR PDO یا APDO.
محدوده EPR
فقط در EPR_Request برای EPR (A)PDO.
Capability Mismatch؛ درخواست معتبر همراه با اعلام کمبود
Mismatch زمانی رخ میدهد که Source با مجموعه فعلی خود نیاز توان Sink را کامل برآورده نمیکند. ممکن است ولتاژ لازم Advertise نشده باشد یا جریان گزینههای موجود کافی نباشد. Sink در این وضعیت حق ندارد RDO خارج از پیشنهاد Source بسازد؛ باید از میان گزینههای موجود یک درخواست معتبر انتخاب کند و همزمان B26 را یک بگذارد.
یک Request معتبر در این زمینه دو شرط اصلی دارد: Object Position باید به Object موجود در آخرین Source Capabilities اشاره کند و Operating Current یا Operating Power نباید از بیشینه عرضهشده توسط (A)PDO منتخب بیشتر باشد. Mismatch شرح نیاز بیشتر است، نه مجوز عبور از سقف Source.
اگر Port Reported PDP منبع از Port Present PDP کمتر باشد، Source پس از PS_RDY و در محدوده tCapabilitiesMismatchResponse باید Capabilities تازهای بفرستد: یا مجموعهای که نیاز واقعی Sink برای عملکرد کامل را حداقل برآورده کند، یا مجموعهای که بر اساس Port Present PDP در همان لحظه قابل عرضه است. برای فهم نیاز Sink، Source میتواند Sink_Capabilities، EPR_Sink_Capabilities یا Sink_Capabilities_Extended را ارزیابی کند.
برای جلوگیری از Loop، Source نباید در پاسخ به Requestهای بعدی با همان Mismatch پیوسته Capabilities جدید بفرستد، مگر Port Present PDP تغییر کند. Guaranteed Capability Source نیز پس از پاسخ به Mismatch نباید بعداً PDP پایینتری عرضه کند، مگر نیاز اعلامشده Sink هم کاهش یافته باشد.
Mismatch را با Invalid Request اشتباه نگیرید
در Mismatch، RDO هنوز داخل محدودیتهای آخرین Advertisement است. Invalid Request میتواند به Position ناموجود یا مقدار جریان/توان بالاتر از سقف PDO اشاره کند. این دو وضعیت از نظر Policy Engine و گزارش خطا یکسان نیستند.
Flagهای RDO چه اطلاعاتی از Sink میدهند؟
GiveBack — B27
GiveBack Deprecated شده و در Fixed، Variable و Battery RDO باید صفر باشد. در PPS و AVS همین جایگاه Reserved است و باز هم باید صفر بماند.
USB Communications Capable — B25
اگر Sink خطوط داده دارد و میتواند با USB 2.0، USB 3.2 یا USB4 ارتباط برقرار کند این بیت یک است. اگر صفر باشد Source باید بداند Sink نمیتواند قواعد USB Suspend را از طریق ارتباط USB رعایت کند.
No USB Suspend — B24
Sink میتواند برای ادامه Explicit Contract هنگام USB Suspend این Flag را یک کند؛ دستگاهی که از توان برای کاری جز ارتباط USB، مانند شارژ باتری، استفاده میکند نمونه رایج است. Source با این اطلاعات تصمیم میگیرد آیا Source_Capabilities را با USB Suspend Supported پاکشده دوباره بفرستد.
Unchunked Extended Messages — B23
وقتی Port قادر است Extended Message بزرگتر از MaxExtendedMsgLegacyLen را در یک پیام Unchunked ارسال و دریافت کند، این بیت تنظیم میشود.
EPR Capable — B22
این بیت توانایی Sink برای کار در EPR Mode را نشان میدهد. هرگاه توانایی EPR Sink تغییر کند، باید Request جدیدی با مقدار بهروزشده این بیت ارسال شود. یک بودن آن بهتنهایی به معنی فعالبودن قرارداد EPR نیست؛ Mode، کابل و پیام مذاکره نیز باید درست باشند.
Operating Current، Power و Output Voltage
Operating Current باید بیشترین جریانی باشد که Sink در طول Explicit Contract خواهد کشید. هر زمان نیاز توان تغییر کند، Sink باید Request یا EPR_Request جدید با مقدار بهروزشده بفرستد. این قاعده اجازه نمیدهد Sink قراردادی برای مقدار پایین ببندد و سپس بدون مذاکره بار بالاتری اعمال کند.
در PPS، Operating Current علاوه بر اعلام مصرف، Current Limit موردنیاز Sink را تعیین میکند. پس از پذیرش، جریان Source به Load نباید از این مقدار بیشتر شود؛ اگر Sink تلاش کند جریان بیشتری بکشد، Source ولتاژ خروجی را کاهش میدهد تا از Operating Current عبور نکند.
در AVS رفتار متفاوت است. AVS برخلاف PPS محدودکننده جریان برنامهپذیر ندارد و Sink مسئول است بیشتر از جریان درخواستشده مصرف نکند. Operating Current در Fixed، Variable، PPS و AVS نباید از Maximum Current گزینه Source بیشتر باشد. برای EPR AVS، سقف جریان از PDP تقسیم بر Output Voltage بهدست میآید و به نزدیکترین گام 50mA رو به پایین گرد میشود.
Operating Power در Battery RDO بیشترین توانی است که Sink در تمام مدت قرارداد خواهد کشید. Maximum Operating Power از نظر عملکردی Deprecated است، باید برابر Operating Power باشد و Source بهتر است آن را نادیده بگیرد.
Output Voltage در PPS و AVS ولتاژی است که Sink در کانکتور خروجی Source میخواهد. این مقدار باید بین Minimum Voltage و Maximum Voltage APDO منتخب باشد. محل اندازهگیری مهم است: استاندارد مقدار را در خروجی Source تعریف میکند، نه الزاماً روی ورودی داخلی مدار Sink پس از افت کابل.
نمونه PPS: 9V و 2A
Output Voltage برابر 9000÷20 یعنی 450 است. Operating Current برابر 2000÷50 یعنی 40 میشود. هر دو مقدار باید داخل Range و Imax همان PPS APDO باشند.
نمونه AVS: 20V و 3A
کد 25mV برای 20V مقدار 800 میشود و چون 800 بر چهار بخشپذیر است، دو بیت کمارزش صفر میمانند. Operating Current برابر 3000÷50 یعنی 60 است. Sink باید سقف PDP و جریان APDO را نیز بررسی کند.
روش عملی Decode و اعتبارسنجی Request
- ۱. زمینه Message را بررسی کنید.
Request باید در SPR و EPR_Request در EPR استفاده شود. Request معمولی هنگام EPR خطای جدی و منجر به Hard Reset است.
- ۲. آخرین Capabilities را پیدا کنید.
RDO باید پاسخ به جدیدترین Advertisement باشد. Snapshot قبلی مبنای معتبر Position نیست.
- ۳. Object Position را Resolve کنید.
Position را به PDO واقعی نگاشت کنید و نوع Fixed، Variable، Battery، PPS یا AVS را بهدست آورید.
- ۴. قالب صحیح RDO را اعمال کنید.
واحدها را مطابق نوع انتخاب کنید: 10mA، 250mW، 20mV یا کد AVS با گام مؤثر 100mV.
- ۵. Reserved و Flagها را کنترل کنید.
GiveBack و Reservedها باید صفر باشند؛ Mismatch و Capability Flagها باید با توانایی واقعی Sink سازگار باشند.
- ۶. سقف درخواست را بسنجید.
Current، Power و Voltage باید داخل محدودیتهای PDO/APDO منتخب باشند. Mismatch این محدودیت را لغو نمیکند.
- ۷. پاسخ و ادامه AMS را دنبال کنید.
GoodCRC، سپس Accept/Wait/Reject و در صورت پذیرش ادامه انتقال توان را جداگانه گزارش کنید.
این توالی ساده نشان میدهد Capabilities فقط گزینهها را میسازد، Request انتخاب را انجام میدهد، Accept پذیرش منطقی را اعلام میکند و PS_RDY آمادهشدن وضعیت توان را خبر میدهد.
BIST Message؛ ورود کنترلشده به آزمون PHY
BIST Message از Port میخواهد وارد حالت آزمون لایه فیزیکی شود. در محدوده این Section دو خانواده عملکرد مطرح است: Continuous BIST برای ارسال جریان پیوسته داده آزمایشی به Tester و Shared Capacity Group Test Mode برای آزمون Portهایی که یک منبع توان مشترک دارند. قالب پیام از Header و BIST Data Object تشکیل میشود و Number of Data Objects برابر ۱ یا ۷ است.
ساختار Header و BIST Data Object در پیام آزمون داخلی PHY.
همه Portها فقط هنگام کار در vSafe5V باید بتوانند Unit Under Test یا UUT باشند. اگر BIST Mode در ولتاژی غیر از vSafe5V درخواست شود، پیام باید نادیده گرفته شود. درخواست Mode پشتیبانینشده نیز نادیده گرفته میشود؛ دریافت هر کد به معنی ورود اجباری به هر حالت دلخواه نیست.
Port یا Cable Plug در Continuous BIST Mode باید حالت درخواستی را برای tBISTContMode حفظ و سپس به کار عادی بازگردد. مدل استفاده فرض میکند یک عامل کنترلکننده، آزمون Port Partner را درخواست میکند و توالیهای انطباق طبق سازوکار BIST اجرا میشوند.
Table 6.27؛ کدهای BIST Data Object
چهار بیت بالایی BIST Data Object نوع Mode را تعیین میکنند و B27..0 همگی Reserved و صفر هستند. کدهای تعریفنشده نباید استفاده شوند. Carrier Mode و Test Data برای همه UUTها Mandatory هستند؛ Entry و Exit حالت Shared Test فقط برای UUTهای دارای Shared Capacity الزامیاند.
کد Mode، کاربرد و دامنه الزامی هر BIST Data Object.
| B31..28 | Parameter | عملکرد | Applicability |
|---|---|---|---|
| 0000b..0100b | Reserved | نباید استفاده شود | - |
| 0101b | BIST Carrier Mode | ورود Transmitter به Carrier Mode | Mandatory |
| 0110b..0111b | Reserved | نباید استفاده شود | - |
| 1000b | BIST Test Data | ارسال Test Frame | Mandatory |
| 1001b | Shared Test Mode Entry | ورود UUT به Shared Capacity Test | برای Shared Capacity UUT |
| 1010b | Shared Test Mode Exit | خروج UUT از Shared Capacity Test | برای Shared Capacity UUT |
| 1011b..1111b | Reserved | نباید استفاده شود | - |
| B27..0 | Reserved | همه بیتها صفر | همه Modeها |
رفتار سه خانواده Mode در BIST
BIST Carrier Mode
UUT پس از دریافت BIST Data Object با کد Carrier، رشتهای پیوسته از 1 و 0 متناوب با کدگذاری BMC ارسال میکند. خروج از Continuous BIST باید حداکثر در tBISTContMode پس از فعالشدن Mode انجام شود.
BIST Test Data Mode
UUT ابتدا GoodCRC بازمیگرداند، سپس وارد Test Data Mode میشود. در این حالت پیام دیگری نمیفرستد، جز GoodCRC در پاسخ به پیامهای دریافتی. پایان آزمون با Hard Reset Signaling انجام میشود.
BIST Shared Capacity Test Mode
Shared Capacity Group چند Port دارد که یک منبع مشترک نمیتواند همه را همزمان در بیشینه Source Capabilities تغذیه کند. یک یا چند Master Port کدهای Entry و Exit را میشناسند. Entry معتبر در PE_SRC_Ready مدیریت توان مشترک را غیرفعال میکند تا همه Portها بیشینه Capabilities را Advertise کنند؛ Tester متعهد است از ظرفیت مشترک عبور نکند.
UUT برای Entry، GoodCRC میفرستد و حداکثر تا tBISTSharedTestMode از هر Port گروه Source_Capabilities تازه صادر میکند. Portهای غیر Master نباید با دریافت Entry وارد Compliance Mode شوند.
در Exit، UUT GoodCRC میفرستد و از Mode خارج میشود. پیام دیگری غیر از BIST Shared Test Mode Exit نباید باعث خروج شود. سپس UUT میتواند Source_Capabilities تازه از Portها ارسال کند یا روی هر Port ErrorRecovery انجام دهد.
Shared Test Mode در برابر Resetها پایدار میماند
UUT با خاموششدن از این Mode خارج میشود، اما در رویدادهای PD مانند Hard Reset، Cable Reset، Soft Reset، Data Role Swap، Power Role Swap، Fast Role Swap و VCONN Swap باید در Shared Capacity Test Mode باقی بماند. خروج عادی فقط با BIST Shared Test Mode Exit انجام میشود.
اشتباههای رایج در Request و BIST
Decode بدون Capabilities: نوع و واحد RDO فقط پس از Resolveکردن PDO مرجع معلوم میشود.
Position ثابت برای ولتاژ: Object Position شماره جایگاه است و با Advertisement تازه ممکن است معنایش عوض شود.
Mismatch بهجای درخواست نامعتبر: حتی با B26=1، Current یا Power نباید از سقف گزینه منتخب عبور کند.
Maximum بزرگتر از Operating: فیلدهای Maximum منسوخاند و باید برابر مقدار Operating باشند.
واحد یکسان برای همه RDOها: Fixed از 10mA، Battery از 250mW و PPS/AVS از 50mA استفاده میکنند.
AVS با Step خام 25mV: دو بیت پایین صفرند و گام مؤثر 100mV است.
Request معمولی در EPR: دریافت آن توسط Source در EPR باید Hard Reset ایجاد کند.
اجرای BIST در هر ولتاژ: UUT فقط در vSafe5V وارد Mode میشود و درخواست دیگر را نادیده میگیرد.
نوشتن داده در B27..0 BIST: همه این بیتها Reserved و صفر هستند.
خروج Shared Mode با Reset: Resetها و Swapها باعث خروج نمیشوند؛ Exit Object یا خاموشی لازم است.
جمعبندی مقاله ۱۰
Request Message دقیقاً یک RDO دارد و Sink با Object Position یکی از گزینههای آخرین Source_Capabilities را انتخاب میکند.
Fixed و Variable جریان 10mA، Battery توان 250mW، PPS ولتاژ 20mV و جریان 50mA، و AVS گام مؤثر ولتاژ 100mV و جریان 50mA را بهکار میبرند.
Capability Mismatch همچنان باید یک درخواست معتبر باشد؛ این Flag فقط اعلام میکند نیاز کامل Sink با پیشنهاد فعلی برآورده نشده است.
Operating Current یا Power بیشترین مصرف طی قرارداد است و با تغییر نیاز Sink باید Request تازه ارسال شود.
BIST Data Object نوع آزمون PHY را تعیین میکند؛ UUT فقط در vSafe5V وارد Mode میشود و Shared Capacity Mode قواعد Entry، Exit و پایداری ویژه دارد.
در مقاله بعدی
مقاله ۱۱ وارد Section 6.4.4 میشود و پیامهای Vendor Defined، Structured و Unstructured VDM، Discover Identity، شناسایی محصول و کابل و سازوکار ورود و خروج از Modeها را بررسی میکند.