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,

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]

Hello Nicolas,

TX_TIMER_TICKS_PER_SECOND defaults to 100.  

Are you sure you need "only" one (1) timer tick or in other words one potential task switch per second?

Or did you mean 1ms timer intervals, that would set TX_TIMER_TICKS_PER_SECOND = 1000.

That also raises the question what is then the purpose of TIM1 that needs to be assigned?

[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

[Softronic Solutions]

HI  @FBL 

Latest STM32cubeMX update did not solve issue (ticket 190248) any idea when we can expect this fix?

I see it as an essential part of your ecosystem that is not working as intended and expected.  One would start to think the UCPD stack + tooling provided by ST is nor used nor popular with customers.  Am I again the only one having an issue with it, was it wise to decide using STM32 microcontrollers for this project?

Looking forward to your reply.

With regards,

Peter

[FBL · Accepted solution]

Hi @Softronic Solutions 

Ticket 190248 is under investigation by CubeMX team. Workaround proposed is to manually add the function call MX_UCPD1_Init() in the initialization section of your code in case port configuration Port0:UCPD1 and Port1: UCPD2.

The example provided in Demo is very interesting. You can follow the implementation in STM32Cube\Repository\STM32Cube_FW_G0_V1.6.2\Projects\STM32G0C1E-EV\Demonstrations\Demo