Weird SPI Behaviour with the W5500 and STM32

Question

Hi all, I have been struggling with the SPI interfacing of this chip in combination with the STM32L412KB. I am using an ETH WIZ Click mikro 3 w5500 board. After a whole while of getting nonesense numbers from the spi (it almost always returned 15 for some reason). I now got more promising results and decided to test the SPI by running the getversion command. However this value is not just, I receive a 0x2. or a decimal 2. Instead of the expected 0x04. Now I am unsure wether my code is working alright, hence why I am asking for help here. On another note, the link stat light is a constant orange, and the CRS occaisionally blinks when connected to a network. Does this mean a succesfull link? I am thrown off by the colour being orange instead of green… I think it could help if I can print all incoming data on the chip, like handshakes etc. Yet I am having trouble realizing that. Please find attached the below code and the MCU configuration. One theory I have is that in the manual it states that the CS pin is a pullup. Yet I configure my GPIO CS as a non pullup. Is this something that could hinder the SPI? I much rather thought it had to do with how the CS pin is configured internally, rather than what the controlling pin should be. /* USER CODE BEGIN Header */ /** ****************************************************************************** * @file : main.c * @brief : Main program body ****************************************************************************** * @attention * * Copyright (c) 2024 STMicroelectronics. * All rights reserved. * * This software is licensed under terms that can be found in the LICENSE file * in the root directory of this software component. * If no LICENSE file comes with this software, it is provided AS-IS. * ****************************************************************************** */ /* USER CODE END Header */ /* Includes ------------------------------------------------------------------*/ #include "main.h" #include "wizchip_conf.h" #include "stdio.h" #include "socket.h" #include "w5500.h" #include "loopback.h" /* Private includes ----------------------------------------------------------*/ /* USER CODE BEGIN Includes */ /* USER CODE END Includes */ /* Private typedef -----------------------------------------------------------*/ /* USER CODE BEGIN PTD */ /* USER CODE END PTD */ /* Private define ------------------------------------------------------------*/ /* USER CODE BEGIN PD */ /* USER CODE END PD */ /* Private macro -------------------------------------------------------------*/ /* USER CODE BEGIN PM */ /* USER CODE END PM */ /* Private variables ---------------------------------------------------------*/ CRC_HandleTypeDef hcrc; SPI_HandleTypeDef hspi1; UART_HandleTypeDef huart2; volatile wiz_NetInfo gWIZNETINFO = { {0x00, 0x14, 0xA3, 0x75, 0x20, 0x3f}, // Source Mac Address {192, 168, 1, 100}, // Source IP Address {255, 255, 0, 0}, // Subnet Mask {192, 168, 1,1}, // Gateway IP Address {8, 8, 8, 8}, //…

hzrnbgy · Answer

TSWiznet: hspi1.Init.DataSize = SPI_DATASIZE_4BIT; Should this be 8 bits? and 40 Mbps on the SPI is too much for the W5500, try making it work at 8 MHz for now

TSWiznet · Answer

I have managed to restructure my code, according to other very old posts i found that the order in which initilaizers are called matters. I have now made the following which works with ping. /* USER CODE BEGIN Header */ /** ****************************************************************************** * @file : main.c * @brief : Main program body ****************************************************************************** * @attention * * Copyright (c) 2024 STMicroelectronics. * All rights reserved. * * This software is licensed under terms that can be found in the LICENSE file * in the root directory of this software component. * If no LICENSE file comes with this software, it is provided AS-IS. * ****************************************************************************** */ /* USER CODE END Header */ /* Includes ------------------------------------------------------------------*/ #include "main.h" #include "w5500_spi.h" #include "wizchip_conf.h" /* Private includes ----------------------------------------------------------*/ /* USER CODE BEGIN Includes */ /* USER CODE END Includes */ /* Private typedef -----------------------------------------------------------*/ /* USER CODE BEGIN PTD */ /* USER CODE END PTD */ /* Private define ------------------------------------------------------------*/ /* USER CODE BEGIN PD */ /* USER CODE END PD */ /* Private macro -------------------------------------------------------------*/ /* USER CODE BEGIN PM */ /* USER CODE END PM */ /* Private variables ---------------------------------------------------------*/ CRC_HandleTypeDef hcrc; SPI_HandleTypeDef hspi1; UART_HandleTypeDef huart2; wiz_NetInfo gWIZNETINFO = { .mac = {0x00, 0x08, 0xdc, 0xab, 0xcd, 0xef}, .ip = {zzzz}, .sn = {255, 255, 255, 0}, .gw = {zzzzzz}, .dns = {8, 8, 8, 8}, .dhcp = NETINFO_DHCP}; /* USER CODE BEGIN PV */ /* USER CODE END PV */ /* Private function prototypes -----------------------------------------------*/ void SystemClock_Config(void); static void…

hzrnbgy · Answer

I have been working on writing a driver for the W5500 specifically for the STM32F4 that I have. There are some nuisances I discovered that has caused me a lot of wasted time troubleshooting the issue. One of them is the clock speed of the MCU. Anything above 32 MHz CPU causes some corruption on received data from the W5500. I can make it work at 168MHz with 21MHz SPI but it’s not stable and would have data corruption after tens of thousands of packets transmitted and received. Enabling the Instruction and Data Cache (DCACHE and ICACHE) feature of the STM32 also causes issue with SPI communication. Tried adding delay between Slave_Select activation and SPI byte sends doesn’t help either. Even running the CPU at 168MHz and SPI at 1MHz or below don’t work either so I’m not sure what the problem is. Currently, I have it running at 32MHz CPU and 16MHz SPI with no DCACHE, ICACHE enabled and been able to TX and RX 2.2 million packets of about 3.2 GBytes of data with zero data corruption from the Linux client so far (1.3 Mbps TX/RX) Just some things to keep in mind when working with the STM32 and W5500 combo.

Eugeny · Answer

hzrnbgy: so I’m not sure what the problem is My educated and experienced guess says the problem lies in the SPI relative signal timing (hold/setup timing violations).

hzrnbgy · Answer

That’s what I thought too so I tried adding delays between SPI byte operations I have tried something like this func read_reg() { SS_LOW delay(); SPI_send addr_H delay(); SPI_send addr_L delay(); SPI_send OPCODE_byte delay(); SPI_read reply_byte SS_HIGH; } The datasheet specifies like 3 or 5 ns minimum for most of these “delays” The thing that I found out is, if the SPI is not working, i received the byte sequence from the SPI_RECV at 0x00, 0x01, 0x02, 0x03 instead of 0x01, 0x02, 0x03, 0x04 So when I’m reading the VERSION register, I get a 0x03 instead of 0x04

Eugeny · Answer

The evil could be in SPI_send and SPI_read - in delays between toggling and reading signals relative to each other. I can’t say more because do not know how they are implemented in your platform. hzrnbgy: The datasheet specifies like 3 or 5 ns minimum for most of these “delays” Which datasheet? 5 ns is 200 MHz, and sounds to be insane for W5500 SPI communication.

hzrnbgy · Answer

Eugeny: Which datasheet? 5 ns is 200 MHz, and sounds to be insane for W5500 SPI communication. I was talking about section 5.5.4 “SPI TIMING” of the Wiznet W5500 V1.1.0 ref guide Eugeny: The evil could be in SPI_send and SPI_read - in delays between toggling and reading signals relative to each other. I can’t say more because do not know how they are implemented in your platform. I’m using basic baremetal implementation of the SPI peripheral for my STM32F4 static uint8_t ssp1_read_register(uint8_t BSB, uint16_t offsetAddress) { uint8_t rtn = 0; uint8_t tH = 0; uint8_t tL = 0; W5500_SS_LO; tH = (uint8_t) ((offsetAddress & 0xFF00) >> 8U); tL = (uint8_t) ((offsetAddress & 0x00FF) >> 0U); SPI2->DR = tH; while((SPI2->SR & SPI_SR_TXE_Msk) == 0); rtn = SPI2->DR; SPI2->DR = tL; while((SPI2->SR & SPI_SR_TXE_Msk) == 0); rtn = SPI2->DR; SPI2->DR = BSB | W5500_OPCODE_READ; while((SPI2->SR & SPI_SR_TXE_Msk) == 0); rtn = SPI2->DR; SPI2->DR = DUMMY_BYTE; while((SPI2->SR & SPI_SR_TXE_Msk) == 0); rtn = SPI2->DR; W5500_SS_HI; return rtn; } This works at anything below 32MHz CPU and upto max SPI of 16MHz. Anything above 32 MHz CPU, I have to put in short delays between byte transfers, and even that is unreliable so I’m not quite sure what else can be done.

Eugeny · Answer

hzrnbgy: I was talking about section 5.5.4 “SPI TIMING” of the Wiznet W5500 V1.1.0 ref guide These values are minimal when you connnect your MCU’s input directly to W5500 die-to-die. In reality you have transmission line subject to capacitance and inductance, which will make these times longer. Consider 2x derating for these times if you make hardware right. hzrnbgy: I’m not quite sure what else can be done. Take scope to see what is going on in the SPI bus. Better multi-channel scope to see the relative positioning of the waveforms. The next steps will depend on what you see. Digging into the features of the MCU SPI implementation may be a good idea to see what you can tune (if it is possible at all). You may also search MCU forum or ask question there. It may appear problem is not purely W5500-related.