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!