cancel
Showing results for 
Search instead for 
Did you mean: 

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

WGao.1
Associate II

 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.

This discussion is locked. Please start a new topic to ask your question.
4 REPLIES 4
MiBA
ST Employee

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

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

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

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