AzureRTOS (Threadx) USBPD support

[Softronic Solutions]

Dear all,

I'm working on an custom hardware project using the STM32G0B1 MCU running ThreadX.  My goal is to use/port the USBPD stack for both source as sink device, but I'm failing to do so partly because the stack provided is closed source.

The CubeMX skeleton code generated for my project does not offer a working solution and all example code nor documentation available is not targeting ThreadX.

Also I'm somewhat confused about which PD stack to use since X-CUBE-USB-PD is no longer recommended? Then what would be the alternative stack to use?

Does anyone have practical experience, can provide meaningful documentation or example code porting USBPD to ThreadX? I would be forever thankful.

Thanks and looking forward to your replies.

With regards,

Peter

[Nicolas P.]

Hello Peter,

there are examples of USBPD applications using ThreadX, have a look here : STM32U5 on github.

Have a look at the Wiki. You will find all the available examples on all STM32.

And yes, the page  X-CUBE-USB-PD is no more supported. As it is explained on this page, this solution was to be used with a TCPC/TCPM architecture. But since the USB power delivery is natively supported by the latest STM32, no need to have an external PD controller.

The most updated stack is available here, with the x-cub-tcpp sw pack.

And now CubeMX can handle this pack. Have a look at this page for dual role support : DRP Wiki .

Hope it helps, tell me if you need more information.

[Softronic Solutions]

Dear Nicolas,

Thank you for your reply.

First let me correct you, I'm not looking into a DRP but a separate SINK and a separate SOURCE implementation  each on a dedicated ucpd port.

Meanwhile I've been making some small successes but I'm still faced with issues/questions.

FYI I'm adding PD packet traces taken with a CC line bus sniffer.

First thing I noticed is that it takes the SINK ST USPD stack a long time before it start replying to the SOURCE (= well known Anker PD power adaptor), is there a known reason for that?  Keep in mind that the PD stack is fully initialised before I attach USB plug.

Second issue is that when I'm the stack is replying it's replying with a strange request for 0A current?

Could that be related to something that is (not) defined in usbpd_dpm_conf.h?

Because I find it strange that it defines external variables that are nowhere declared and the once that are declared from CubeMX are grayed/compiled out.

[Nicolas P.]

Hello Peter @Softronic Solutions ,

Good if you move forward.

To help you, it would be more than helpful if you could share your .cpd trace (see : Trace wiki). I hope you have an UART available for debug...

We would see the timings thanks to the timestamps traces, from the internal stack perspective.

There are also debug messages that would help telling if you have filled in correctly all the functions. (Look for "ADVICE" messages in the trace)

Perhaps you could also share your AzureRTOS tasks priorities order ?

Regards,

Nicolas

[Softronic Solutions]

Hello Nicolas,

Well that was brutal!  As requested I enabled the TRACER_EMB

Enabled the GUI_INTERFACE

Recreated the skeleton code complied it without errors, but it completely ruined my application.

Nothing was working any more.  After some debugging I found that when enabling the TRACER_EMB the DMA interrupt section got overwritten entering the TRACER_EMB_IRQHandlerDMA() function but removing all other DMA handlers which basically the CubeMX (re-)adds without TRACE_EMB enabled.

To proceed I added them manually to make sure the remaining code remained working.

Now when running the code with the STM32CubeMonitor USB Type-C PD attached I get only this.

Each time I reboot the code the same entry appears, but nothing else is displayed not even when re-plugging the USB cable.

While my external CC-line tracer is able to capture this.

So much for the TRACER_EMB functionality, as I don't have much appetijt for spending time debugging the debugger here.

[Softronic Solutions]

Dear Nicolas,

There is one topic that I needed to verify with you.

The instruction video's mention the use and configuration of X-CUBE-TCPP, while I'm not enabling it at all since it doesn't allow me to create one SINK and one SOURCE application.

And I'm also not using any of the X-nucleo boards or used parts either.

How does that affect the skeleton code created?

[Nicolas P.]

If you are not using the TCPPs, you should avoid using the CubeMX pack x-cube-tcpp...

One question : are you looping port 1 to port 2 ? Have you tried to generate and test one port only (source or sink) ?

[Softronic Solutions]

Not using any of the TCPP's, thanks for confirming that topic.

I'm not looping any of the ports both ports need to be handled individual.

I'm focused on getting the SINK port working using an external USBPD charger adaptor, but the skeleton code is generated for both SINK and SOURCE.

Would it help if you can have a look at the project/code?

 

[Nicolas P.]

Yes, you can share your ioc.

But if the two ports are independent, it could be simpler to start first with sink port for example, and then source.

To avoid mixing multiple issues.

[Softronic Solutions]

Hi Nicolas,

Sharing the projects IOC file here.

Would be good if you could return a working SINK example project based on this IOC that would allow me to continue build upon.

Meanwhile I'll try your suggestion of removing the SOURCE section from the project.