Why is the STUSB4500 ALERT pin(#19) not toggled when I do PD soft reset?

[WGao.1]

 I can loop to see a bunch of alert status changes in the alert status registry(0x0B). My alert mask register(0x0C) value is 0x11. Also PD sniffer shows new PD negotiation successfully.

Thanks.

[MiBA]

Hi

the alert are cleared by reading relevant register

with naming of SW package STSW-STUSB003 available on Web updated recently

bit 6 CC_DETECTION_STATUS_AL : read register @ 0x0D PORT_STATUS_TRANS

bit 5 MONITORING_STATUS_AL : read register @ 0x0F TYPEC_MONITORING_STATUS_0

bit 4 HW_FAULT_STATUS_AL: read register @0x12 CC_HW_FAULT_STATUS_0

bit 1 PRT_STATUS_AL : read register @0x16 PRT_STATUS

other bits have no interest for you

to me ALERT_MASK must be at 0x91 or 0x81 if you want to follow HW_FAULT

ALARM_MANAGEMENT function is clearing all

so if you Alert pin is low level clear it by reading those 4 registers

after sending SoftReset Message , PRT_STATUS must be cleared as STUSB4500 is receiving many Message during negotiation

BR

MiBA

[WGao.1]

Hi,

I set the ALERT_MASK mask to 0x91 (I set to 0x95 but then it reads out as 0x91, I think it is ok since bit 2 is reserved and always be 0).

After reading the registers(from 0x0B to 0x0B+12) to clear ALERT, I can see the ALERT status register(0x0B) becomes 0x00 (it was 0x01 before I read those registers).

The problem is that, the ALERT pin sticks to low (I think it means interrupt happened) - it is low level before and after I read all 12 relevant registers (from 0x0B to 0x0B+12).

What would be wrong?

Thanks,

Yan

[MiBA]

Hi Yan

You are true the bit 2 and 3 of the Register ALERT and ALERT_MASK are not used so you don't care about them

for each of the 4 bits of the ALERT register that are useful , you can clear it by reading 1 register

the register bit 0 is ALERT on Phy event ( Phy is fully performed by STUSB4500 and this alert must remain masked ) so you don't care about this one , it give only the indication that messages was send or received if you want absolutely to clear it , simply read the register @0x17 PHY_STATUS

Protocol level is also fully managed by STUSB4500 , but to be able to take decision regarding power , you need to intercept SOURCE PDO during power negotiation

the bit 5 of the register 0x16 give you the indication that message is available in reception buffer , so you can read it , be careful that if in between a new message is received the buffer is over ,this operation must be perform by interrupt handler because it could be very short < 1.6 ms

please check my yesterday mail

for example

if you have mask register to 0x91 you have to check only 3 registers

if you have 0x02 in ALERT register read register 0x16 ( to know if a message was received ) for example Sources PDO

if you have 0x40 in ALERT register read register 0x0D( connection event )

if you have 0x20 in ALERT register read register 0xF0 (monitoring event )

by the way pull up is mandatory on ALERT pin #19

you need to use for that the interrupt handler ALARM_MANAGEMENT () combined with falling edge interrupt

the package STSW-STUSB003 help you to properly manage the STUSB4500 some bug correction and enhancement was added in last package

BR

MiBA

[WGao.1]

Hi MiBA,

I got the interrupt working following your suggestions. The alert mask(0x0C) is 0x11. Now I encounter another issue: I cannot catch the source capability PD traffic. It is so consistent that I think I have something setup wrong. I send out a softreset to re-negotiate and the data I captured is like below(The missing part appear in USB-C PD sniffer but not in my log). I only lists the PD traffic from PD source, and the traffic from sink is not listed.

1. Missing in my catch: RX_HEADER_LOW(0x32) RX_HEADER_LOW(0x31) : 01 61 (GoodCRC)
2. ALERT_STATUS_1 register(0x0B): 02 (PRT_STATUS_AL), PRT_STATUS register(0x16): 0C, RX_HEADER_LOW(0x32) RX_HEADER_LOW(0x31) : 01 63 (ACCEPT)
3. Missing in my catch: RX_HEADER_LOW(0x32) RX_HEADER_LOW(0x31) : 43 61 (Source capability, 4 objects)
4. ALERT_STATUS_1 register(0x0B): 02 (PRT_STATUS_AL), PRT_STATUS register(0x16): 04, RX_HEADER_LOW(0x32) RX_HEADER_LOW(0x31) : 03 61 (GoodCRC)
5. ALERT_STATUS_1 register(0x0B): 02 (PRT_STATUS_AL), PRT_STATUS register(0x16): 0C, RX_HEADER_LOW(0x32) RX_HEADER_LOW(0x31) : 05 63 (ACCEPT)
6. ALERT_STATUS_1 register(0x0B): 02 (PRT_STATUS_AL), PRT_STATUS register(0x16): 04, RX_HEADER_LOW(0x32) RX_HEADER_LOW(0x31) : 06 66 (PS_RDY)

What would be wrong that I always miss the item 1 and 3. While item 1 is not important, item 3 is critical.

Thanks,

Yan