Unable to activate UCPD Trace in STM32G431

[Correa]

Hi,

I have tried many times to get a trace using STM32CubeMonitor-UCPD 1.2.0 with my board without success. I have tried with both RTOS and without. The USAR1 is connected to an FTDI usb serial cable but the board doesn't show up In the monitor.

I have noticed that USBPD_PE_StateMachine_SRC returns -1 which prevents it from ever being called again since the return value is used as a waiting time.

Find attached my main.c (initialization of the board and peripherals)

[HFISTM]

Hello @Correa​ ,

It seems that you are trying to use the GUI functionality with CubeMonitor. Have you enabled the GUI_INTERFACE under Utilities in CubeMX ?

If you just want to see the trace and only enabled the tracer, you could directly open it by selecting the proper COM port in CubeMonitor. Button "Trace" in right bottom corner --> "Select Tracer" port tab at the top.

Regarding the return value of the function you mentioned, it is a normal behavior. This function is used inside the USBPD lib, and return value is used as a task waiting time. "-1" is value 0xFFFFFFFFu which correspond to an infinite wait.

Best regards.

[Correa]

Hi @HFISTM​ thanks for replying.

Yes I have enabled GUI_INTERFACE as well as USART1 TX DMA1 and global interrupt. Even if I open the port for trace only in the Monitor nothing shows.

About return value, that function is called from here when not using RTOS:

      if ((HAL_GetTick() - DPM_Sleep_start[port]) >= DPM_Sleep_time[port])
      {
        DPM_Sleep_time[port] =
          USBPD_PE_StateMachine_SRC(port);
        DPM_Sleep_start[port] = HAL_GetTick();
      }

And returning -1 blocks it from ever being called again, unless somewhere else there is a clearing of the DPM_Sleep_start at some point, I haven't figured it out yet.

[HFISTM]

Hello @Correa​ ,

You mentioned using USART1 for the tracer. However, you configured USART2 and USART3 in your main.c file.

If you use an FTDI board, I'll advise you to check the RX/TX wiring to avoid possible mismatch or inversion. Please also ensure your FDTI breakout is made to accept the TX voltage level coming from the STM32.

Could you share your ioc so that we can check the tracer config ?

You could also check the variable TracerContext.PtrDataTx to see if the trace is well evacuated from the STM32.

[HFISTM]

Hello @Correa (Community Member)​ ,

You mentioned using USART1 for the tracer. However, you configured USART2 and USART3 in your main.c file.

If you use an FTDI board, I'll advise you to check the RX/TX wiring to avoid possible mismatch or inversion. Please also ensure your FDTI breakout is made to accept the TX voltage level coming from the STM32.

Could you share your ioc so that we can check the tracer config ?

You could also check the variable TracerContext.PtrDataTx to see if the trace is well evacuated from the STM32.

[Correa]

Hi @HFISTM​ 

Yes I have configured the other uarts as I plan to use them in the future on this application, but right now my focus os only on USB-PD Source with Data (UFP/DFP swap) and they are just not in use atm. Not sure what you mean by checking TracerContext.PtrDataTx. I have set a breakpoint in TRACER_EMB_SendData and it get's called, I can see that PtrDataTx has data in it and HW_TRACER_EMB_SendData as well as TRACER_EMB_LowPowerSendData() and TRACER_EMB_LowPowerSendDataComplete they all happen to be called in different executions of that function. From TracerContext PtrTx_Read and PtrTx_Write both increases from call to call but SizeSent doesn't. It stuck with 20 after the first run. LowPower_Counter and Counter alternates between 0 and 1 between calls.

Attached is my current .ioc file.

I have validated the TX/RX lines on all serial ports by writing a different small program to send Hello World on all serial ports using HAL. The ports have RS232 level shifters, they are not TTL. At one point I tried USART3 in TTL level connected to the TX/RX pins of a Nucleo board, rationale was that perhaps Monitor didn't recognize FTDI vendor id/device id, but it also didn't work out.

[Correa]

Hi @HFISTM​ any idea? I'm using ST-Link2 from kits to connect to my board. Since it limits to a few hardware breakpoints tracing should make it clearer where UCPD is stopping.

[HFISTM · Accepted solution]

Hi @Correa​ 

I've checked your ioc.

USART1 is used for the trace. However, USART2 is connected to STLink on the Nucleo board. (I know you have a custom board, but please make sure that your STLink is really connected to the pins associated with USART1, or change the USART in tracer config).

The rest of the ioc seems fine.

To debug, you can add the following line at the end of function USBPD_TRACE_Init in file usbpd_trace.c:

USBPD_TRACE_Add(USBPD_TRACE_DEBUG, 0u, 0u, (uint8_t*)("INIT TRACE"), sizeof("INIT TRACE") - 1u);

This way, if you open a simple COM terminal, you will see the message at startup if everything is well configured.

I've added FREERTOS for the tests on my side, and used a Nucleo-G431KB with tracer configured with USART2. And the trace is working fine.

Regards,

Heol

[Correa]

Hi @HFISTM​ 

I found the problem, when using FreeRTOS it was getting stuck on an configASSERT and the answer was to setup the MAX Interrupt Priority in RTOS settings to 3 (Down from 5 which was default). Also separated the time source for HAL to TIM2 instead of SysTick but not sure if that was important to the solution. Thanks for all the help, knowing that USART1 wasn't obligatory for trace helped as well.