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.

[Nicolas P.]

Hello Peter,

I've seen a quick fix that you can do : in your ThreadX settings, TX_TIMER_TICKS_PER_SECOND is set to 100. For USBPD, you need to set it to 1 !

Tell me if it helps.

We'll continue analyzing your file.

Regards,

Nicolas

 

[Softronic Solutions]

Dear Nicolas,

FYI when following your recommendation to start with only one UCPD port enabled (for a SINK operation) I could not help noticing that "now" I have Stack + User port 0 parameters available.

When you refer to earlier post you can see that these Port 0 where not available when both UCPD ports are enabled.

BR.

Peter

[Softronic Solutions]

Hello Nicolas,

Humm, first compile results with the one UCPD and SINK only approach are not successful.

Getting compile error because CubeMX did not add certain files needed?

The code copied-in here is in accordance to all online available example code. So I assume it's needed to compile correctly before I get things working here?

I'm starting to get the feeling that CubeMX in combination with threadX and USBPD stacks needs a coding review? FYI I'm using the latest version, will be difficult to get back to older versions.

[FBL]

Hi @Softronic Solutions 

I reproduced on my end. CubeMX is missing port 0 parameters. Internal ticket (190248) is reported. However, I can compile without issues. Would you attach your project?

[Softronic Solutions]

Hi FBL,

Thanks for raising that ticket! Does that ticket also include the investigation into why enabling TRACER_EMB removes those otherwise CubeMX included DMA handlers?

Got it to compile too...needed to "Enable USB Support" to get those missing files included.

I was hoping that since focussing on SINK only and reenabling TRACE_EMB would offer a working trace capability. but this is still failing to send data.  I noticed that HW_TRACER_EMB_SendData() gets run once

Hereafter the HW_TRACER_EMB_IRQHandlerDMA() callback get called regularly but the TRACER_EMB_TX_DMA_ACTIVE_FLAG(TRACER_EMB_DMA_INSTANCE) is never set.

Any idea why this flag is not set?

UPDATE:

Found the culprit!

Because enabling TRACER_EMB removed the other DMA handlers I needed to re-add them manually, but that was one to many.

Now tracer is working!

Question: GUI_INTERFACE is that needed to register your board in the USB type-C PD monitor?  Because this is not the case?

 

 

 

 

[Nicolas P.]

Hello Peter.

Glad you reached one fist functional step.

Regarding the question of GUI_INTERFACE activation : you need to activate it only if you want to use UCPD monitor to send some PD messages (nice to select some PDO for examples).

Having the trace only is the basis to tune and help building your application. If you don't have GUI_INTERFACE activated, you will not see it in the available boards list. But you can however access it by selecting manually the COM port on the top right dark blue bar, and get the debug traces.

So you have one port sink running. What about the source ?

Regards,

Nicolas

[FBL]

Hi @Softronic Solutions 

You might require custom interrupt handling to manage overrun interrupt of DMA. 

Sure, _GUI_INTERFACE is needed in the UCPD monitor. But it is not strictly necessary for USB Type-C PD monitoring if you do not need a graphical interface. You can manage PD settings and monitor status directly through firmware. I guess I have faced this issue before! Check user defined preprocessor _TRACE and _GUI_INTERFACE

[Imen.D]

Hello @Softronic Solutions,

This issue was fixed in the STM32CubeMX V6.13.0 by adding the Stack Port 0 Parameters and the User Port 0 Parameters panels to the Configuration field in the UI.

Thank you for your contribution and for having reported the point.

[Softronic Solutions]

Hi Imen.

Thanks for providing that CubeMX fix, I can again see and configure both USBPD ports.

There is however something I don't quite understand related to the use of both __USBPD_PWR_IF_C and __USBPD_DPM_CORE_C compiler switches.

I understand it allows you to switch between extern defined (in an object file) and local defined (in a .h file) variables.

But when defining those compiler switches so that the .h file defined variables are to be used the compiler complains about: multiple definition of `USBPD_NbPDO' , `PORT0_PDO_ListSRC', `PORT0_PDO_ListSNK', etc...

I guess the object file still includes those regardless of the compiler switch been defined.  Is that on purpose or am I missing the point here?

What should I do to be able to use the .h file defined variables?

Thank you for looking into this topic.

Peter

[FBL]

Hi Peter from @Softronic Solutions 

As moderators, we would recommend starting a new discussion to tackle another subject.

You need to check that the variables are defined only once. This should be done using the extern keyword. Here an example where all these PDOs should be defined in usbpd_pdo_defs.h

[rcoleman99]

Sorry to hijack this thread - on STM32CubeIDE 1.19.0 I am still experiencing the issue mentioned (link) where enabling TRACER_EMB deletes calls to HAL_DMA_IRQHandler() in stm32g0xx_it.c. Is there a ticket for this bug?