EVAL performs badly in Ethernet udp stress, (and NUCLEO performs OK)

Are you using an LCD at all?

If you are, then it is possible that running with a slow LCD clock will mean that bus transfers, register accesses and the like will be slow.

As I understand things, the LCD peripheral uses its own DMA to refresh the LCD panel. So a large (many pixels) LCD at a slow clock will occupy a greater proportion of the BUS bandwidth and thereby leave insufficient bandwidth for Ethernet. There is a direct connection between LCD and AXI-SRAM, so the LCD frame buffer should be there to minimise bus contention.

Also, if you have any blocking (e.g. interrupt) code relating to the LCD, if that is slower the CPU will be unable to service Ethernet events for a longer period.

Hope this helps,

Danish

Hello,

Thanks for the answer.

I've edit the question.

I am not using LCD.

We see the following:

1. stm32h743-EVAL - using RTOS example with udp echo server, stops responds to udp/ping request during a short stress test from pc to target.And even after stopping the stress, it stops responding at all to any request ! I have to reset board to make is respond (changing to 400 and restarting debugger did not help !!)

1. stm32h743-NUCLEO - using RTOS example with udp echo server, still responds to udp/ping request during a short stress test from pc to target.

Comparing the changes in code (assuming that it is not an HW difference between nucleo and eval), I saw that PLLN in eval was 160, while in nucleo 400. (yet, there are other differences too that I should still check).

I suspected that this is the PLLN issue, because when changing PLLN in nucleo to 160, it stops responding during the test. (but after stopping the stress, it did continue responding to requests). So, I then tried to change in nucleo to 400, but it did not help in EVAL.

Any idea,

Ran