Problems with ethernet and usb when using TouchGFX

[jimmii]

Hello

I'm working with a custom HW with a STM32H753 controller.

The operating system is Keil RTX and Keil Middleware is used.

I have a 272x480 display connected to LTDC (RGB565).

I also have ethernet functionality implemented with a LAN8742A PHY and one USB Host (MSC).

For Networking and USB, Keil Middleware is used.

Now my 2 problems:

1: Ethernet connection is working fine (Link is up and running) when connecting my board to a switch or hub.

When connecting our board directly to the pc/notebook (point to point connection) without the use of a switch, then the link is up for a short time (1-1.5s) and then loses it. This cycle is repeated endlessly.

When disabling TouchGFX (removing the signal vsync), both connection variants (with and without switch/hub) are working without any problems.

As far as I know, the link is brought up by the PHY and has nothing to do with my firmware, all it needs is a 25MHz clock and then the link shoud be established.

I'm clueless as of why the deactivation of TouchGFX has anything to do with the Ethernet link. And why it only affects the the ethernet link when not using a switch/hub.

Do you have any idea/hints where I could start to look for a solution?

2: I'm using the USB to log some data. Every hour I write the collected logs to a USB stick. This works fine for some time, then I get some bus errors and the usb stack is stuck forever. A HW reset is necessary to function again.

Again, when disabling TouchGFX the problem disappears.

Following errors occur:

304527, 300.87113479, USBH_Driver, OnSignalPipeEvent, ctrl=0 pipe_hndl=0x40080540 event=ARM_USBH_EVENT_BUS_ERROR

304528, 300.87118531, USBH_Driver, PipeTransferGetResult, ctrl=0 pipe_hndl=0x40080540 num=0

304529, 300.87118879, USBH_Core, PipeSendFailed, pipe_handle=0x30013DF0 len=31 error=usbTransferError

304530, 300.87119312, USBH_Core, MemFree, ctrl=0 ptr=0x30011D74

304531, 300.87119582, USBH_MSC, ScsiWrite10Failed, instance=0 block_addr=1553767 block_num=16 status=103

304532, 301.87060821, USBH_MSC, ScsiWrite10, instance=0 block_addr=1553767 block_num=16

304533, 301.87061230, USBH_Core, MemAlloc, ctrl=0 ptr=0x30011D74 size=31

304534, 301.87061576, USBH_Core, PipeSend, pipe_handle=0x30013DF0 len=31

304535, 301.87063044, USBH_Driver, PipeTransfer, ctrl=0 pipe_hndl=0x40080540 packet=0x02 num=31

Perhaps this problem is connected to the ethernet problem.?

Maybe someone of you has some good ideas?

Thanks for the help.

/jimmii

[Walid ZRELLI]

Hello @Roman Schläpfer​ ,

This might be a stack overflow issue.

So, I recommend that you try to size you stack by following this application note from ARM Determining the stack usage of applications (keil.com)

I hope this helps. Please keep me posted.

BeST Regards,

walid

[jimmii]

hi @Walid ZRELLI​ 

Sorry for the delay, I was on vacation.

We checked the document, thanks.

Unfortunately, this does not appear to be the problem. Our stack is not overflowing.

Any other ideas?

/jimmii

[DGiro.2]

Hello @jimmii,

i have  the same problem.

Are you solved the problem?

Thank you,

Davide

[jimmii · Accepted solution]

Hi @Davide G_Oirometti​ 

Yes,

In our case it was an HW issue. The QSPI lines interfered with the 16 MHz oscillator and thus all derived clocks (PLL...) - 48MHz USB clock and the 25MHz Ethernet clock were unstable.

/jimmii

[Walid ZRELLI]

Hello @Roman Schläpfer​ 

Thank you for the feedback :smiling_face_with_smiling_eyes:

BeST Regards,

Walid