STM32G0 USBCPD: Debug issue and hard reset of PE instead of negotiation

[Franz.1]

//EDIT: Please go to the my last reply since this represents the current state of the investigations

This is kind of a follow-up post, but a totally different topic than yesterday.

So, after following the video step by step for a USBCPD sink "project with a custom board" (video minute 13:04)

https://www.youtube.com/watch?v=cbdFHmMOMwk

I was successful is the sense that "STM32CubeMonitor for USB Type-C PD" does indeed recognise my custom board based on the STM32G0B1CBT6. I can connect and see that there is a explicit contract for a fixed 5V.

However, despite reading through different USBCPD related documents, I am not really sure which kind of functionality the demo / the full stack from ST provides and what is left to the user. For example: after connecting the CubeMonitor to the board, I am not able to send any Messages to the board or do any configuration. No matter which mesage I seelct from the "Message Selector" Tab or the "Port Communication", I always get "Message rejected for this port configuration". Not even the ping mesage is working. Is this to be expected? I somehow expected that the Messages that are exposed in the GUI and the settings that one can do in the "Port Communication/ Configuration" are already "built-into" the stack?

Thanks!

[FBL]

Hi @Franz.1 

Could you please check in predefined symbols are activated?

_TRACE
_GUI_INTERFACE

[Franz.1]

Hi @FBL ,

Yes, it seems they are (see screenshot below from CubeIDE)

Am I right that your answer suggests that the Messages exposed in the GUI should be already handled by the Example/Demo Firmware as setup in the mentioned tutorial?

Thanks! 

//Edit: I was not sure whether with “activated” you mean “just defined” as they are in the screenshot or also set to a value like “1”? But I tried both, did not make a difference.

//EDIT2: At least (by scope) I can tell there is data on both the RX and TX lines of the LPUART when I try to send a Message from GUI to the board and the board seems to answer... generally the MonitorTool and/or stack seems incredibly unstable. I can as I said issue no messages beside of Soft Reset and hard Reset . Sometimes, but only sometimes and as a first action after board reset the "Get Status" Message at least blinks "green" in the Gui, but even then this only works once until I reset the board again. All other Messages are broken "all the time".

[Nicolas P.]

Hello @Franz.1 

An easy way to know if you have some code to write, is the keyword "ADVICE" in the trace, like in below example.

793	DEBUG	5483	1	ADVICE: Update BSP_USBPD_PWR_SetRole

Look for the function after the ADVICE in you code. You need to code there to fit your needs.

Once your code has been filled, you can remove the ADVICE trace.
Have a look on how these sections are completed in our examples.

Messages can be rejected if what you request are not in line with the current status of the stack. For example, enter in some VDM modes, if discovery was not done previously.

See also this thread.

Can you share your .cpd file ?

Regards,

Nicolas

[Franz.1]

@Nicolas P.  thanks for the support so far, got me one tep further.

Actually, the only thing not working is requesting a new voltage from the source using the USBPD_DPM_RequestMessageRequest() function. Now I stumbled across another roadblock when trying toi debug the return value of the USBPD_DPM_RequestMessageRequest() function. I cannot halt the target in debugger witouthout loosing the connection to the STM32G0B1CBT target.

Trying to see where this happens showed that as soon I try to do ANYTHING in the debugger (when the PD state machine is running) like toggling a breakpoint, the connection to the target is lost.

Target is not responding, retrying...
Could not halt device (18)
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...

Using the ST-LINK (OpenOCD) instead of ST-LINK (ST-LINK GDB Server) is a bit more verbose and as soon as the scheduler starts says

Error: Fail reading CTRL/STAT register. Force reconnect
Error: [STM32G0B1CBTx.cpu] not halted (gdb fileio)
Polling target STM32G0B1CBTx.cpu failed, trying to reexamine
Error: Fail reading CTRL/STAT register. Force reconnect
Error: [STM32G0B1CBTx.cpu] Examination failed
Examination failed, GDB will be halted. Polling again in 100ms
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to write memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to write memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Fail reading CTRL/STAT register. Force reconnect
Error: Failed to read memory and, additionally, failed to find out where
Info : stlink_dap_op_connect(reconnect)
Info : SWD DPIDR 0x0bc11477
Info : [STM32G0B1CBTx.cpu] external reset detected
Polling target STM32G0B1CBTx.cpu failed, trying to reexamine
Info : [STM32G0B1CBTx.cpu] Cortex-M0+ r0p1 processor detected
Info : [STM32G0B1CBTx.cpu] target has 4 breakpoints, 2 watchpoints
Info : [STM32G0B1CBTx.cpu] Examination succeed

//EDIT: I stepped through the code and found out that as soon as the RTOS starts the first task with vPortStartFirstTask(), the USBPD_CAD_Task gets active. I still can step through code (and therefore halt and resume) at this point. Then, the USBPD_PE_Task kicks in. Seems that as soon as the line 

_timing = USBPD_PE_StateMachine_SNK(_port);

is run, I cannot halt the target anymore without loosing my debugger connection.

//EDIT2: After some more investigations/experiments I see that I loose the debugger becuause the PE requests a Hardreset as it seems. This is the trace I get when I listen on the UART port and the start the firmware (i.e. let the board run). The board is already powered in this case and the µC/ FW is flashed and reset by the debugger. You see that after the PE_SNK_WAIT_FOR_CAPABILITIES it follows a PE_STATE_HARD_RESET.

CAD	2	1	USBPD_CAD_STATE_DETACHED	0	
CAD	4	1	USBPD_CAD_STATE_ATTACHED_WAIT	1	
CAD	124	1	USBPD_CAD_STATE_ATTACHED	2	
NOTIF	124	1	USBSTACK_START	3	
DEBUG	124	1	ADVICE: USBPD_DPM_Notification:104	4	
EVENT	124	1	EVENT_ATTACHED	5	
DEBUG	124	1	ADVICE: update USBPD_DPM_UserCableDetection	6	
DEBUG	124	1	ADVICE: USBPD_DPM_Notification:104	7	
PE	124	1	PE_SNK_STARTUP	8	
PE	124	1	PE_SNK_WAIT_FOR_CAPABILITIES	9	
PE	624	1	PE_STATE_HARD_RESET	10	
NOTIF	624	1	POWER_STATE_CHANGE	11	
DEBUG	624	1	ADVICE: USBPD_DPM_Notification:90	12	
NOTIF	624	1	HARDRESET_TX	13	
DEBUG	624	1	ADVICE: USBPD_DPM_Notification:31	14	
OUT	624	1	HRST	15	
DEBUG	624	1	ADVICE: update USBPD_DPM_HardReset	16	
PE	624	1	PE_SNK_HARD_RESET_WAIT_VSAFE_0V	17	
GUI	0		BOARD RESET BY USER	18	
CAD	4	1	USBPD_CAD_STATE_ATTACHED_WAIT	19	

If I listen on the UART port and power cycle the whole setup (i.e. Plugging in the AC/DC PD adapter that also supplies the board) the software runs and the contract is negotiated. Which makes me believe that this is some power up issue I don´t understand.

Maybe @Marosh ?

Thanks!

[Nicolas P. · Accepted solution]

Hello @Franz.1 

Nice to see some progress.

Could you share the full trace as .cpd trace please ?

The trace mechanism is very useful to help debugging, because the power delivery protocol has some timing constraints. And if you don't fulfill them, you could ger hard resets. That is why it is not recommended to put breakpoints in the code, but use trace instead.

Looking quickly at your trace, IN (= incoming) messages are missing. It could be that the hard reset occurs, because there is no incoming message from the source that is supposed to tell which capabilities it has. We see in the trace that the state is "wait for capabilities", as you also noticed.

Here you don't seem to have bidirectional communication. We don't reach the "explicit contract".

Have you ever reached once the explicit contract ?

[Franz.1]

Hi  @Nicolas P. 

Good to hear from you again! I had the project on a hold for some days but work goes on so I hope to find some solution soon.

As I said in my previous post: the Firmware can establish an explicit contract when the whole setup starts up from an unpowered state. My setup is that the PD AC/DC adapter supplies the target board so as long as the wall adapter is not plugged in, also my board is without power.

So  - If all components are unpowered and I plug in the wall adapter and attach the USB C cable to the target, I get the contract - see trace "2024_08_26_13_05_17_USBCPD_Debug_power_up" (it is a trace file, just has .hex ending so I can it upload here. (in fact it does not make a difference whether the wall adapter is already powered, but the cable has to be detached in the beginning!)

If I power-up successfully as described above and keep the board powered and the cable attached and then do a µC reset (e.g. by user RESET button on the board) I get the following trace "2024_08_26_13_06_08_USBCPD_Debug_target_reset".

In the second trace (the case where the target is reset with cable and wall adapter staying in place) it seems that the target state machine requests a hard reset. My guess is that this request is served by the wall adapter which "removes" power from the target board. The target board then restarts and the FW triggers the "wait for capabilities" but the source does not answer this request since it thinks it is still attached?

So as far as I understand the real question is: How do I have to modify the Firmware so that the contract is again negotiated after the target board was reset without the cable being detached? I guess that is a quite common usecase?

@Nicolas P. : Any thoughts?

[FBL]

Hi @Franz.1 

Would you attach trace files in compressed format .7z for example?

Edit /: I successfully read traces
Would share your schematics? Do you use CC line protection circuit?

Could you implement logging in the firmware to monitor the source to ensure it reacts correctly to hard reset message?

Edit/2: According to section 4.2.4 Hard reset in UM2552 , it seems your source is ignoring hard reset: something is going wrong with your source. Could you provide more information about your source? 

[Nicolas P.]

Hi @Franz.1 ,

from the last comment I gave end of August, I see no news. Hard reset seems not seen by the Source.

In the "2024_08_26_13_06_08_USBCPD_Debug_target_reset.hex" trace we see a detach at the very end, after the HR. Are you reseting the MCU again at that time ?

As @FBL said : do you have CC line protections in place ? What is your PD source model/brand ?

Regards,

Nicolas

[Franz.1]

Hi @Nicolas P.  and @FBL 

Sorry for the late reply! Actually, I did not notice that you edited the post while I waited for an anwer ;)

Good news is: After some more investigations, it seems that i solved the problem (hope this is really the case) and that the USB PD stack was not the cause of the "second" reset but some other FW related side effect - I highly appreciated your help and wanted to thank you both for your comments and the support throughout this thread!

One last and (more or less) related question to that topic; What is the reason that in CubeMX GUI, I can select fixed voltage PDOs for 5V, 9V, 15V and 20V, but not 12V? That voltage is missing in the predefined options of the GUI. What is the reason for that?

Thanks and all the Best!