2021-01-25 04:42 PM
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.
2021-01-26 12:58 AM
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
2021-01-26 02:19 PM
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
2021-01-27 01:59 AM
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
2021-02-16 06:39 PM
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.
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