Microcontroller Ethernet-enabled system design [STM32Nucleo]

Although devices and equipment of various standards are connected to the network, the network standards are standardized by the OSC reference model below, so any device or equipment can communicate with any other device or equipment as long as it is based on the common standards.

Ethernet is one of the most popular wired LAN standards and is defined by IEEE802.3.

According to the standard, a communication system is to be built from the LAN cable at the physical layer to, for example, the HTTP application layer using a web browser. The data link layer is usually hardware-based, and the rest is software-based.

There are three main types of MCUs with respect to Ethernet communication, which can be categorized as follows.

The first general-purpose MCU is not equipped with an Ethernet controller, so a MAC/PHY device controller is externally attached to it, and SPI, I2C, and other general-purpose buses are used as interfaces for communication. The Nucleo-F103RB MCU we will be dealing with this time falls into this category.

The second MCU has a built-in Ethernet MAC device, for example, the STM32F407. It communicates with the MCU's built-in MAC device using a method called MII/RMII with an external PHY device controller.

The third MCU incorporates the device MAC and PHY required for Ethernet, and the only additional component is an RJ-45 with built-in pulse transformer.

The following is a list of commonly used and easily obtainable controllers that can be combined with MCUs to make them Ethernet-compatible.

Even if you have no knowledge of Ethernet, you can use a controller with a general-purpose serial communication interface like the ESP32 used for WiFi, just like serial communication.

It can be selected as the simplest IoT-enabled controller. The advantage is that it can be externally attached to existing devices that support only serial communication, but the disadvantage is that it is not highly versatile because it follows the driver provided by the manufacturer.

The ENC28J60 controller can be made Ethernet-compatible even with MCUs that do not have an Ethernet controller, as long as they have SPI communication.

Since the TCP/IP protocol stack must be built in by yourself, the STM32F1 series seems to be very difficult to implement with few examples. If you do not want to take the time to understand the contents of the selected TCP/IP protocol stack, the following W5500 is recommended.

As in the case of the ENC28J60 controller, it is applicable to MCUs without an Ethernet controller that have SPI communication. The major difference between the two is that the W5500 has a TCP/IP protocol stack built into the hardware, which eliminates the hassle of installing a TCP/IP protocol stack and provides a stable connection.

Therefore, in addition to being usable without knowledge of the TCP/IP protocol stack, another major advantage is that it can be implemented in MCU with small memory due to its low software load.

The Nucleo-F103RB is a well-balanced controller that requires few external components for the STM32 in the Nucleo-F103RB and can be expanded to socket communication using the TCP protocol and communication from a browser using the higher-level HTTP protocol.

Controllers such as LAN8720 and DP83848, which only have PHY devices for those with built-in Ethernet-compatible MACs like the STM32F407 , can better utilize MCU's functions.

Controllers such as LAN8720 and DP83848, which only have PHY devices for those with built-in Ethernet-compatible MACs like the STM32F407, can better utilize the microcontroller's functions.

Using the STM32CubeIDE development environment, the TCP/IP protocol (LwIP) can be easily incorporated and even the transport layer TCP and UDP protocols can be implemented by using the automatic generation function at the development project creation stage.

When designing a product for network equipment from the beginning, it is probably a good idea to select MCU with a built-in network.

To make the STM32F1 series MCUs without an Ethernet controller Ethernet-compatible, the W5500 or ENC28J60 should be considered for versatility.

The W5500, which has a TCP/IP protocol stack built into the hardware, is particularly good as a network specification, and can easily be used to network a microcontroller, then I will choose this one.

The TCP/IP protocol stack conforms to the standard, so there is little need to understand the internal details and it can be dismissed as a pre-existing module.

To connect the Nucleo-F103RB to the network with an external W5500, here we use a commercial W5500 board. The boards are inexpensive and have minimal peripherals, but many of them do not have a MAC address.

EEPROM or other memory to hold the MAC address is required for product development.

The only connections to the Nucleo are the power supply and the SPI communication section if interrupts and resets are not used. However, the W5500 does not have a power-on reset, so a hardware reset should be used especially in the case of commercialization to ensure a reliable reset. In this case, SPI2 is used, so the connection is as shown in the figure below.

The W5500 communicates by operating registers inside the IC via SPI communication. The details of the registers are described in the W5500 datasheet, but for programming, the drivers provided by the manufacturer are registered as a library (ioLibrary_BSD), and functions are called as needed.

The file wizchip_conf.c/wizchip_conf.h is a collection of functions that interface SPI communication with the STM32. This file specifies the controller IC chip (W5500) to be used, register addresses, etc. The file wizchip_conf.c/wizchip_conf.h contains the functions for SPI communication interface with the STM32. It is necessary to modify some parts of the file when customizing the interface with MCU.

w5500.c/w5500.h defines and summarizes the send/receive functions with the microcontroller used in controller W5500.

socket.c/socket.h is a set of functions used for TCP socket communication. The functions conform to Berkeley Sockets (BSD sockets).

It would be good to register these as the minimum drivers in the ioLibrary_driver folder and add others as needed, such as those related to DHCP.

The W5500 LAN controller has a common register block for writing/reading operations, IP addresses and other parameters, protocol specifications, and other specifications, and a socket register block for use in socket communications.

The register details are explained in the W5500's instruction manual, which allows for fairly detailed settings, but only some of them are used in general applications.

To operate these register blocks, SPI communication is used as an interface to MCU, so if this part can be established, it is almost done.

Only a small part of the driver interface file (wizchip_func.c) needs to be modified to STM32 specifications. In actual programming, the functions defined in the driver can be used, so once you understand the points, it does not take much time and effort.

I think it is a good idea to follow the functions in the driver in order to see how the registers are actually manipulated, while looking at the instruction manual at least once.

The frame format for spi communication in the W5500 consists of three phases shown in the figure below, with a block of one byte (8 bits) each. There is an address phase for the upper and lower 2 bytes, a control phase of 1 byte, and a data phase.

This is a customization to tie SPI-related functions (chip select, send/receive) defined in the STM32 to the W5500 driver.

In the SPI interface (wizchip_conf.c), additionally register the part circled in red below. Chip select function SPI_CS1_Select()/ SPI_CS1_Deselect() is self-made for STM32Nucleo.

Add and register your own send/receive function SPI_Send_Receive() in the same way.

If the contents are different, the SPI send/receive function additionally defined in the above figure is tied to the driver-defined function as shown in the figure below.

In fact, this is the only important part to add or rewrite to the driver. In addition, you only need to modify the file paths to be included, which will result in an error during the build process.

Don't forget to include a file defining your own SPI-related functions in the header file of the SPI interface (wizchip_conf.c) so that it can be linked.

Once the interface with SPI communication is ready, the actual programming involves initialization using functions defined in the driver.

The initialization flowchart is summarized in W5500_ini() in the program as follows. The functions for register manipulation are defined in the driver header file W5500.h.

The W5500 can be configured for multicast and other advanced settings, but here we will initialize with simple basic single-cast settings.

Reset register (MR_RST) is issued to register PHY initialization, source (server side) MAC address, IP address, KeepAlive, timeout, etc.

After completing the initial setup so far, the communication environment up to the network layer is ready. The full program is as follows

The initialization function W5500_ini(), net-related homebrew functions, etc., are separately compiled in the module net_func.c and its header files are included.

When the program is run, it can connect to a LAN with a network address belonging to the configured IP address.

Here the network address is 192.168.3 and the IP address is set to 192.168.3.100.

Run the "ping" command from the PC command prompt screen to see if it is recognized in the network. Check the response when typing "ping 192.168.3.100".

A screen like the one below indicates that the ping is not passing through due to an incomplete connection for some reason.

In such cases, there is usually some reason, such as an incomplete cable or a different IP address than the one you have set.

If the ping response is like this on the first connection immediately after programming, there may be some flaw in the program, and you will find the cause of the bug. It is especially important to check the operation related to spi communication and the path of the driver related files. Once it works, it is fine.

If the program functions properly, the screen below will appear. In this state, the ping has passed, indicating that it has successfully joined the network.

Since the ping command is in the ICMP protocol, the communication system is established up to the network layer of the OSI reference model.

The ping command alone cannot do any work other than checking communications, but once a network has been established up to this point, a web server can be created and accessed from a browser using the upper-level TCP protocol for socket communications or the higher-level HTTP protocol.

This time, the IP address is the fixed value "192.168.3.100" stored in memory. Although not explained here, if the DHCP function is installed, an IP address automatically assigned by the DHCP server can be used.

In the next issue, I will implement TCP, the upper-level protocol, to realize socket communication.