2025-03-17 6:19 AM
Hello,
I am attempting to send data from an STM32G474RE (Client) to a laptop (Server) over TCP using the W5500 module. However, I am encountering an issue where the data transmission works properly only up to an SPI baud rate of 18 MHz. When I attempt to increase the SPI baud rate beyond 18 MHz, the transmission fails, and no data is sent to the server.
I have also tried using DMA mode for SPI, but there was no improvement in the situation.
According to the W5500 datasheet, the recommended practical SPI baud rate is 33.3 MHz. Despite this, I am unable to send data reliably at higher speeds.
Can Anyone suggest a solution to resolve this issue and allow for successful data transmission at SPI speeds above 18 MHz?
2025-03-17 7:13 AM - edited 2025-03-17 7:13 AM
@Kirtan wrote:When I attempt to increase the SPI baud rate beyond 18 MHz, the transmission fails,
What, exactly, do you mean by that?
Have you used an oscilloscope to verify the signals in the analogue domain?
Have you used an analyser to verify comms?
@Kirtan wrote:According to the W5500 datasheet, the recommended practical SPI baud rate is 33.3 MHz.
If your STM32 is still complying with the WS5500 requirements/specifications (as verified above), then it's a Wiznet problem - you need to contact them for support with their product:
WS5500 documentation is here: https://docs.wiznet.io/Product/iEthernet/W5500/overview
Wiznet's GitHub: https://github.com/Wiznet/
Wiznet forums: https://maker.wiznet.io/forum
2025-03-17 7:25 AM
@Kirtan wrote:According to the W5500 datasheet, the recommended practical SPI baud rate is 33.3 MHz. Despite this, I am unable to send data reliably at higher speeds.
Apart from the raw speed of the link, check if there are also any other restrictions on timing, throughput, etc ...
What speed ethernet are you using?
2025-03-17 7:41 AM - edited 2025-03-17 7:42 AM
Does the STM32 stop transmitting?
=Yes, data above 18 MHz SPI baud rate is not transmitted from STM32. However, when I check the ping, I still receive a response at higher frequencies, such as 30 MHz."
Have you used an oscilloscope to verify the signals in the analogue domain?
= No..
2025-03-17 8:07 AM
Perhaps your board is not designed well enough to handle speeds past 18 MHz. This can be due to crosstalk or other noise sources. Short traces with fewer vias are best. Can you show your layout?
2025-03-17 8:12 AM - edited 2025-03-17 8:15 AM
@Kirtan wrote:Does the STM32 stop transmitting?
=Yes, data above 18 MHz SPI baud rate is not transmitted from STM32.
So all activity on the SPI lines ceases - no clock; nothing on MOSI ?
I'm talking here just about the SPI - not the ethernet.
@Kirtan wrote:However, when I check the ping, I still receive a response
Presumably, the WS5500 handles that internally, then - without interaction from the STM32?
@Kirtan wrote:Have you used an oscilloscope to verify the signals in the analogue domain?
= No..
So do that!
EDIT: as @TDK said, there may be noise, distortion, etc ...
If the STM32 isn't properly driving the SPI lines (and/or poor design is corrupting the signals), the WS5500 obviously won't be receiving properly.
2025-03-17 9:39 AM
Apologies for not mentioning earlier that I am using the Nucleo STM32G474RE, rather than a custom board.
2025-03-17 10:04 AM
Are you suggesting that the issue might be due to improper SPI functionality? Specifically, there could be a problem with the SPI configuration for the W5500 module?
2025-03-17 10:15 AM - edited 2025-03-17 10:19 AM
I'm trying to understand what's actually happening - your posts are unclear!
You talk about "the data transmission" - but it's unclear whether that's
We don't have access to your hardware, so we can't test or investigate this for you.
So you need to:
use an oscilloscope to verify the SPI signals in the analogue domain
use an analyser to verify the STM32-WS5500 SPI comms
2025-03-17 10:17 AM
@Kirtan wrote:Apologies for not mentioning earlier that I am using the Nucleo STM32G474RE, rather than a custom board.
But you still haven't told use how the WS5500 is connected to that.
Post schematics.
Some good, clear, photographs may help.
See: How to write your question to maximize your chances to find a solution.