USB HS doesn't work with TouchGFX ?

[walidhmz]

Hello,

I am using an STM32F769I-DISCO board to implement USB HS in my TouchGFX project, but it is not working as expected. I have already tested USB functionality with FreeRTOS CMSISv2 without TouchGFX, and it works fine. However, when I try to run both TouchGFX and USB HS host (MSC) together, the application state remains stuck at APPLICATION_START when the USB disk is connected and never make transition to APPLICATION_READY.

I have tried adjusting the priorities of the USB and TouchGFX tasks and increased the stack size for the USB task, but the issue persists.

Any suggestions to help get both working together properly would be greatly appreciated ?

Best regards.

[GaetanGodart]

Hello @walidhmz ,

Can you share the call stack?

Where does it get stuck? What is the line and the code?

Can you try to lower the clock speed?

Could you try to move the TouchGFX task entry at the end of the USB setup (or the other way around)?

Is there any potential pin conflict when enabling both?

When you enabled USB only, did you use FreeRTOS too?

Regards,

[walidhmz]

Hi @GaetanGodart 

Thank you for your  suggestions.

- It gets stuck when entering USBH_Process. After receiving Appli_state: APPLICATION_START and phost->gStat: HOST_CLASS_REQUEST, the status remains at USBH_BUSY in usb_core.c, and phost->gState is set to HOST_ABORT_STATE.

- Initially, I tested the setup at 216 MHz, then reduced the clock to 96 MHz without any improvement.

- There is no conflict between LTDC/DSI and USB, the pins are available before USB is enabled.

- I also tried to use to move the TouchGFX task entry at the end of the USB setup.

- Yes, it works correctly when i enbled USB only with FreeRTOS.

You can find my .ioc file attached with a simple example integrating both USB and TouchGFX. I’m stuck at this point and would appreciate any help.

 

BR

[GaetanGodart]

Hello @walidhmz ,

It looks like you get to phost->gstate = HOST_ABORT_STATE because phost->pActiveClass is NULL.

It also looks like there is a specific log systems for the USB part, have you looked at it?

Perhaps it is because phost is not initialized correctly.
One solution to start debugging could be to look at the working project (without TouchGFX) and see where pActiveClass is set and then see if you do the same thing in the project with both USB and TouchGFX.

Regards,

[walidhmz]

Hi @GaetanGodart 

Is it possible to find a similar example?

BR

[GaetanGodart]

Hello @walidhmz ,

ST made an example using TouchGFX and USB to transfer data and power between 2 STM32H7S78-dk boards, this example will soon be available on the STM32H7S78-dk product page.

Regards,

[walidhmz · Accepted solution]

Hi @GaetanGodart 

I resolve it by changing the definition as follows : 

/** Alias for memory allocation. */
#define USBH_malloc pvPortMalloc
 
/** Alias for memory release. */
#define USBH_free vPortFree

Regards,

[GaetanGodart]

Hello @walidhmz ,

I am glad you found a solution !

Thank you for keeping us updated.

Regards,

[cpssoft]

I'm also using TouchGFX with the STM32F769I-DISCO board and the USB Host device in the STM32CubeIde 1.14.1 IDE environment.
With TouchGFX running to manage the graphic display, when I insert the USB stick, the USB stick management doesn't work.

When debugging, the system interrupts, calls the USBH_UserProcess function in the usb_host.c file, but
the HOST_USER_CLASS_ACTIVE case condition is missing.

I adopted user walidhmz's solution by modifying the following in the usbh_conf.h file:
#define USBH_malloc pvPortMalloc
#define USBH_free vPortFree

With this change, when I insert the USB stick, I resolve the HOST_USER_CLASS_ACTIVE case condition in the
USBH_UserProcess function in the usb_host.c file. But when I call the f_readdir function, it doesn't work, and I believe this is
related to the condition of using dynamic memory with the Malloc instruction.

How can I fix this?

Your help would be appreciated.

Thanks

[cpssoft]

Problem solved.
The problem was using the malloc instruction for dynamic memory allocation. When using FreeRTOS, using malloc is risky, because the heap isn't always adequate. I solved the problem by replacing malloc with an array, which, while not as memory-optimized as malloc, is safer in a FreeRTOS environment.
Thanks everyone