Dual USBPD: "Stack Port 0" and "User Port 0 Parameters" tabs missing in IDE 1.16

[EStua.1]

This is very easy to reproduce:

- Create a new STM32 project using a PD-compatible MCU e.g. STM32G071CBT6 

- Enable both UCPD1 and UCPD2 as dual-role ports. Add DMA for Rx/Tx for each port.

- Enable FreeRTOS

- Enable USBPD with default port configuration "Port 0: UCPD1; Port 1: UCPD2", "Full stack", TIM1

- Looking at the "Configuration" window only Port 1 is configurable (see attached)

 

[Mahmoud Ben Romdhane]

Hello @EStua.1 ,

First let me thank you for posting and welcome to the ST Community.

I suggest that you take a look at this Post. The issue is related to STM32CubeMX standalone, and it was reported to the concerned team (under internal ticket number:190439).

Thanks.

Mahmoud

[EStua.1]

Hi Mahmoud,

Thanks for the update. I am not quite sure what the proposed work around is to ensure all the Port 1 & 2 parameters are set correctly. Is the process as follows:

- Enable UCPD1. Disable UCPD2. Configure Port 0 and generate code. Commit to GIT.

- Disable UCPD1. Enable UCPD2. Configure Port 1 and generate code. Revert any changes that appear to related to Port 0. Keep Port 1 changes.

The Post above just says "add the function call MX_UCPD1_Init()" but this obviously won't configure the missing Port information.

Thanks,
Evan.

[EStua.1]

The problem with the approach above is every time you enable or disable even one of the UCPD ports it disabled USBPD middleware package - meaning everything is reset.

 

Configuring dual USBPD support is broken. How long has the internal ticket been open for? 

[EStua.1]

Hi Mahmoud,

 

What is the last known-good STM32Cube IDE version we can roll back to?

 

Thanks,
Evan.

[EStua.1]

I can't download 1.15 - it simply reloads the page:

https://www.st.com/en/development-tools/stm32cubeide.html

 

1.16 works but we know that's broken.

[EStua.1]

I think we've found a work around. Open the IOC file a text editor and set the version back to the previous MxCube version:

MxCube.Version=6.11.1
MxDb.Version=DB.6.0.111

[EStua.1]

Hi Mahmoud,

Could you please update the status of this and when can we expect to see it fixed?

Regards,
Evan

[Carl_G]

Has this been fixed or is there a successful workaround?

[Carl_G]

Looks to be fixed in the new STM32CubeIDE 1.17.0!
Another interface anomaly however.  Some items are not displayed depending on the configuration. However, if those items were already configured, then the configuration stays in the generated file. e.g. I have a dual port with source and sink PDOs defined. I generate and get a file with source and sink PDOs. Then I change to SRC only. The SNK PDOs will be removed from the IDE so I don't see them anymore, but they will remain in the generated source.

Its not a big deal since they shouldn't be used, but just an FYI as it was confusing me jugging 4 ports and not seeing the change I expected.

[EStua.1]

Hi Mahmoud, Carl_G,

Unfortunately this is still pretty broken partly due to missing tabs but also due to ST's hardcoding port 0 as a SNK. You can easily reproduce this by the following:

- Configure UCPD1 as a SRC

- Configure UCPD2 as a DR

- Under port configuration, set Port 0 - UCPD2 (DR), Port 1 - UCPD1 (SRC). The tab for Port 0 SNK config is missing.

 

You might suggest ok well why don't you change the config around, so that Port 0 - UCPD1 (SRC), Port 1 - UCPD12 (DR)? Well that's broken because of the hardcoded SNK Port 0 check in .USBPD_PWR_IF_Init().

See attached.

 

 

 

[Carl_G]

Hi Estua.1,

The "hardcoded" source that you show is considered user code and you must modify it yourself. You can tell because it is between

 

USBPD_StatusTypeDef USBPD_PWR_IF_Init(void)
{
/* USER CODE BEGIN USBPD_PWR_IF_Init */
 return USBPD_ERROR;
/* USER CODE END USBPD_PWR_IF_Init */
}

 

 

 

[EStua.1]

re hardcoded - ah ok must have got that from an ST example a while back. 

 

re broken PD config - The tab is still missing so this is still an open bug.

 

re DRP - I haven't found an ST example. If you enable CAD there's a 50/50 chance of an another DRP being detected as SNK/SRC and the role change request isn't ideal. Our work around is to disable the CAD toggle in CAD_StateMachine_DRP depending on our adaptor state. i.e. if ADAP is connected, set CAD to SRC otherwise CAD SNK. This isn't a good solution so I'm hoping someone else has a better idea.