an5413-getting-started-with-the-spc58x-networking-stmicroelectronics
an5413-getting-started-with-the-spc58x-networking-stmicroelectronics
Application note
Introduction
SPC58x Automotive micro-controllers features a Quality-Of-Service 10/100 Mbit/s Ethernet controller that implements the
Medium Access Control (MAC) Layer plus several internal modules for standard and advanced network features.
This application note presents a demonstration package built on top of the FreeRTOS+TCP/IP stack that contains some
applications built on top of it to test basic and complex networking features and measuring some Ethernet controller
performances.
All application demos have been developed by using SPC5Studio tool https://www.st.com/en/development-tools/spc5-
studio.html.
SPC5Studio is built-on Eclipse that provides functionalities and components to set up both hardware and software stacks on
STMicroelectronics automotive micro-controllers.
SPC5Studio also offers a simple approach to set up signals and clocks mandatory to configure the hardware.
When testing an Ethernet communication interface, the TCP/IP stack is necessary for communicating over a local or a wide
area network.
The application note also introduces the main Ethernet controller features.
It covers the Ethernet and physical layer programming guide.
All the information available in this document can be considered and adopted, with minor variances, for all SPC58x MCU family
where the Ethernet controllers are embedded.
1 Ethernet overview
The 10/100 Mbit/s Ethernet provides many advanced features that can be summarized into the following
categories:
• MAC Core
• MAC Transaction Layer (MTL)
• DMA Block
• SMA Interface
• MAC management counters
• Power Management block (PMT)
The Interrupt generation on Frame Transmit and Receive transfer completion is supported and the status is
reported inside the descriptor itself.
The controller supports the following two types of descriptors:
• Normal Descriptor: used for packet data and to provide control information applicable to the packets to be
transmitted or received.
• Context Descriptor: used to control packet advanced features, e.g.: timestamps, VLAN.
This application covers the normal descriptors programming.
Both Transmit and Receive Normal descriptors have the following two formats:
• Read format
• Write-Back format.
When the descriptor is manipulated by the software driver, for example, to transmit a packet, it is in Read Format.
After transmitting the packet, the latest descriptor (that has been owned by the DMA engine) results in Write-Back
format and it contains the status of the packet transmission.
On the reception side, the software driver prepares the descriptors in read format, as soon as a frame is received,
the descriptor is in write back format and it contains the status of incoming frame so handled by the DMA engine.
Refer to the "Descriptor" related chapter inside the Reference Manual of the micro-controller for all the details and
related programming guide (see Section Appendix B Reference documents) .
2 Application set up
According to the PCB design and MII mode, the connection between Ethernet and PHY transceiver can be
complex, so SPC5Studio provides a set of graphical interfaces to configure the signals, clocks and so on.
Note: In the SIUL2 configuration the Output Edge Rate Control (OERC) bit for output pins are set as Strong / Very
Strong drive.
3 FreeRTOS overview
FreeRTOS TCP/IP component, integrated inside SPC5Studio, provides a scalable, open source and thread safe
TCP/IP stack for FreeRTOS.
SPC5Studio provides, in the pre-built applications, a main code that, as detailed in the diagram below is based on
FreeRTOS Operating System.
The main function starts the OS scheduler that is delegated to initialize the whole network processes:
• TCP/IP stack;
• Ethernet interface;
• Physical layer.
Other tasks can be also scheduled to start services: e.g. CLI, HTTP and FTP servers.
The FreeRTOS component is installed with a default configuration to cover all network needs in terms of task
priorities and features.
Expert User can tune some parameters for memory management, synchronization, timers etc.
This can be done by graphical interface as shown below; all selections are documented in the Help section
available in the tool.
The FreeRTOS TCP/IP component provides a configuration file FreeRTOSIPConfig.h which defines all the
configuration parameters, it is automatically generated by SPC5Studio depending on the values set on FreeRTOS
TCP/IP component graphical interface.
Below the Outline of the FreeRTOS TCP/IP component showing the main groups of configuration parameters.
Note: Note that the FreeRTOSIPConfig.h must not be manually modified. Use the FreeRTOS TCP/IP graphical
configuration tool instead.
The TCP/IP stack can be complex to tune and configure, so the application provides a default set up suitable to
run the whole stack. Expert User can change the default parameters for TCP / UDP and Socket. It is possible to
enable the loopback mode and configure the echo reply on ping. It is also possible to install user hook.
The figure below shows the “HW and Driver Specific Settings” configuration, by default the full checksum
computation is performed by the Ethernet controller.
Note: in this application the standards MTU are used by default.
Different buffer allocation schemes suite different embedded applications, so FreeRTOS+TCP keeps the buffer
allocation schemes as parts of the TCP/IP stack's portable layer.
At the time of writing, two example buffer allocation schemes are provided - each with different tradeoffs among
simplicity, RAM usage efficiency, and performance.
The C source files that implement the buffer allocation schemes are located in portable/BufferManagement
directory.
• Scheme 1 – BufferAllocation_1.c
– Ethernet buffers are statically allocated by the embedded Ethernet peripheral driver (at compile time).
This ensures the buffers are aligned as required by the specific Ethernet hardware. This is done by
means of the vNetworkInterfaceAllocateRAMToBuffers that must be implemented in the portable layer
if the user wants to use this scheme.
• Scheme 2 – BufferAllocation_2.c
– Ethernet buffers of exactly the required size are dynamically allocated and freed as required. This
requires a fast memory allocation scheme that does not suffer from fragmentation.
In SPC5Studio the FreeRTOS TCP/IP Component is configured to use BufferAllocation_2 as showed in the
following figure:
Some features can be also turned-on or off, for example the Logging print messages through UDP frames.
The figure below shows how to configure the server and UDP ports for this support.
HTML and FTP servers can be enabled and users callback can be set up to debug monitor conditions.
The figure below shows the default configuration for HTML an FTP servers.
The SPC5Studio Network component is used to configure both Ethernet and PHY devices.
The graphical interface offers several options to configure the devices.
For the selected physical driver, it is possible to change the MII mode, fix the speed and duplex mode (skipping
auto-negotiation process of the link).
For the Ethernet interface, as shown in the figure below, it is possible to provide a different address and setting
either static IP or DHCP address.
6 FreeRTOS_IPInit
The initialization of the whole TCP/IP Stack is done through the networkInit() function, that is called by the
componentInit() helper.
The FreeRTOS_IPInit() function, receives as input parameters the Ethernet configurations settings from the
graphical interface (please refer to Network Component in the next chapters).
It creates a prvIPTask task that configures and initializes the network interface by invoking the
xNetworkInterfaceInitialise() function.
The following diagram shows a simplified diagram of the layers in the network stack
The network interface port layer provides an interface between the embedded TCP/IP stack and the Ethernet
driver; it is implemented inside the NetworkInterface.c file.
The network interface port layer must provide the following main routines:
• Section 7.1 xNetworkInterfaceInitialize to initialize the Ethernet and PHY drivers.
• Section 7.2 xNetworkInterfaceOutput to implement the packet transmission.
• Section 7.3 prvNetworkInterfaceInput to implement the reception of a packet.
The initialization process is based on a defined type structure that represents the network driver operations: this is
the netdrv_ops_t and defined inside the NETDRV_IF header file.
7.1 xNetworkInterfaceInitialize
When FreeRTOS TCP task is scheduled, it invokes the xNetworkInterfaceInitialise to set up the
Ethernet controller allocating all the resources and establishing the Link.
In summary, the xNetworkInterfaceInitialise will do the following steps:
• Initialize the function callbacks and private structure according to the user configuration.
• Configure the Ethernet parameters in the micro-controller specific registers.
• Detect the PHY and start-up the Link.
– xNetworkInterfaceInitialise fails until the link is not established.
• Configure the descriptor rings and allocate the buffers.
• Initialize the DMA and perform its software reset.
• Initialize the CORE/MTL and internal counters.
• Invoke the xTaskCreate to create the main task
– It is invoked by the interrupt service routine to manage the incoming frame receptions and transmit
completion.
• Start the reception and transmission processes and configure the related tail pointer registers.
7.2 xNetworkInterfaceOutput
The xNetworkInterfaceOutput sends data received from the embedded TCP/IP stack to the Ethernet driver for
transmission. The TCPI/IP stack calls this function whenever a network buffer is ready to be transmitted.
The related function prototype is:
A network buffer descriptor, xNetworkBufferDescriptor_t, is used to describe a network buffer. It points to the
buffers that are transferred between the TCP/IP stack and the low level drivers.
The start of the buffer is pointed by pxDescriptor->pucEthernetBuffer while the length is located by pxDescriptor-
>xDataLength).
If xReleaseAfterSend is pdTRUE then both the buffer and the buffer's descriptor must be released back to the
TCP/IP stack by the driver code when they are no longer required.
If xReleaseAfterSend is pdFALSE then both the network buffer and the buffer's descriptor will be released by the
TCP/IP stack itself (in which case the driver does not need to release them).
The xNetworkInterfaceOutput invokes the Ethernet APIs to fill the buffer to be transmitted in the descriptor list and
start the controller and DMA the transmission by updating the DMA_CH_TXDESC_TAIL_POINTER register.
7.3 prvNetworkInterfaceInput
The prvNetworkInterfaceInput() function is called by the Interrupt service routine as soon as one or more packets
are received. This function moves the data from the DMA to the network buffers that have to be passed to the
upper layer. This is only done if the incoming packets have no error.
The prvNetworkInterfaceInput() has to re-fill the descriptors used by the DMA engine. So the descriptors, found in
write-back mode, have to be reset in normal read format mode in order to be reusable by the DMA engine.
The network interface port layer must send packets, received from the Ethernet driver to the TCP/IP stack.
IRQ_HANDLER(SPC5_ETH0_CORE_HANDLER) {
IRQ_PROLOGUE();
dwmac_core_dma_main_isr(&drv_instance[SPC5_ETH0_INSTANCE]);
IRQ_EPILOGUE();
}
where:
In this implementation, both transmit and receive processes are managed by prvDWMACHandlerTask:
The netd->netdrv.complete_send is invoked by the task to notify the Ethernet frame has been successfully
transmitted.
If the frame has been transmitted without any errors it releases the transmit descriptors.
Different errors can be reported by DMA engine, as detailed inside the Reference Manual (see Section Appendix
B Reference documents), each event can require different actions, for example, reallocate the related buffers,
sanitize the descriptor ring, report the failure and update internal statistic software counters.
Specific platform settings are needed before starting the network stack:
• Enable the Ethernet clock.
• Set the Soc Configuration Register 0 (SIUL2_SCR0) register to select the Ethernet0 Modality, MII (Media
Independent Interface) or RMII (reduced Media Independent Interface).
• Select voltage (3.3V or 5V) for IO Eth0/1 ring.
/* Enable clock */
SPCSetPeripheralClockMode(SPC5_ETH0_PCTL, SPC5_ME_PCTL_RUN(1) | SPC5_ME_PCTL_LP(2));
The phy library connects the Ethernet controller with the physical medium.
This library concerns itself with negotiating link parameters with the link partner on the other side of the network
connection and provides a register interface to allow Ethernet driver to determine which settings were chosen.
The library provides the callbacks to program the transceiver e.g. dp83848 10/100 MII/RMII Transceiver. So the
SPC5Studio provides its own low level driver for the dp83848 transceiver, this is embedded on several
STMicroelectronics automotive reference boards.
…
PHYDriver *phyd = NULL;
phyd = &PHYD1;
phyd->phy_drv = SPC5_ETH0_PHY_NAME;
phyd->mode = SPC5_ETH0_PHY_MODE;
phyd->link_mode = SPC5_ETH0_PHY_LINK_MODE;
phyd->speed = SPC5_ETH0_PHY_SPEED;
phyd->int_mode = SPC5_ETH0_PHY_INT_MODE;
phyd->phyops.instance = SPC5_ETH0_INSTANCE;
…
phyd->addr = SPC5_ETH0_PHY_INIT(&phyd->phyops);
/* Read and Write through the MDIO bus (invoking the Ethernet SMA interface */
uint32_t phy_read(void *priv, uint32_t phy_addr, uint32_t reg_addr);
void phy_write(void *priv, uint32_t phy_addr, uint32_t reg_addr, uint32_t val);
Below a snapshot of the dp83848_setup function. It will check the ID and it can restart the auto-negotiation
process:
if (phy_reset(dpd->parent)) {
return pdFALSE;
}
if (phy_restart_aneg(dpd->parent)) {
return pdFALSE;
}
These are the main APIs to setup the MAC core and enable the transmission and reception processes:
Refer to the SPC5Studio application demo for the complete function implementation while point to the Reference
Manual (see Section Appendix B Reference documents) where all register description is available.
priv->reg->MAC_CONFIGURATION.B.ACS = 1;
priv->reg->MAC_CONFIGURATION.B.JD = 1;
/* MII mode */
priv->reg->MAC_CONFIGURATION.B.PS = 1;
/* HW Checksum */
priv->reg->MAC_CONFIGURATION.B.IPC = 1;
/* Enable queues */
priv->reg->MAC_RXQ_CTRL0.B.RXQ0EN = 0;
…
During the initialization phase it is necessary to provide the MAC addresses as shown below.
This Application Note doesn't cover perfect and hash filtering (e.g. to join to a Multicast network)
It is mandatory to store the data in the registers guaranteeing that, the low part of the address is programmed
after the high one. This is to allow a synchronization inside the filter module in this peripheral.
priv->reg->MTL_TXQ0_OPERATION_MODE.B.TSF = 1;
priv->reg->MTL_TXQ0_OPERATION_MODE.B.TTC = 0;
priv->reg->MTL_TXQ0_OPERATION_MODE.B.TXQEN = 2;
fifosize = 128 << priv->reg->MAC_HW_FEATURE1.B.TXFIFOSIZE;
priv->reg->MTL_TXQ0_OPERATION_MODE.B.TQS = fifosize / 256 - 1;
priv->reg->MTL_RXQ0_OPERATION_MODE.B.RSF = 1;
priv->reg->MTL_RXQ0_OPERATION_MODE.B.RTC = 0;
fifosize = 128 << priv->reg->MAC_HW_FEATURE1.B.RXFIFOSIZE;
priv->reg->MTL_RXQ0_OPERATION_MODE.B.RQS = fifosize / 256 - 1;
/* Program the buffer len: e.g. 1536 (suitable for VLAN too). */
priv->reg->DMA_CH[channel].DMA_CH_RX_CONTROL.B.RBSZ = BUF_SIZE;
while (dwmac->reg->MAC_MDIO_ADDRESS.B.GB) {}
dwmac->reg->MAC_MDIO_DATA.B.RA = reg_addr;
dwmac->reg->MAC_MDIO_DATA.B.GD = 0;
dwmac->reg->MAC_MDIO_ADDRESS.B.PA = phy_addr;
dwmac->reg->MAC_MDIO_ADDRESS.B.RDA = reg_addr;
dwmac->reg->MAC_MDIO_ADDRESS.B.GOC = GMII_READ_OP;
dwmac->reg->MAC_MDIO_ADDRESS.B.GB = 1;
while (dwmac->reg->MAC_MDIO_ADDRESS.B.GB) {}
while (dwmac->reg->MAC_MDIO_ADDRESS.B.GB) {}
dwmac->reg->MAC_MDIO_DATA.B.RA = reg_addr;
dwmac->reg->MAC_MDIO_DATA.B.GD = data;
dwmac->reg->MAC_MDIO_ADDRESS.B.PA = phy_addr;
dwmac->reg->MAC_MDIO_ADDRESS.B.RDA = reg_addr;
dwmac->reg->MAC_MDIO_ADDRESS.B.GOC = GMII_WRITE_OP;
dwmac->reg->MAC_MDIO_ADDRESS.B.GB = 1;
while (dwmac->reg->MAC_MDIO_ADDRESS.B.GB) {}
The phy_addr is one the 32 possible addresses where the device is found while the reg_addr is the physical
register to be accessed.
DMATxDesc = (
(des0 = 0x4002837C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
(des0 = 0x4002897C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
(des0 = 0x40028F7C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
(des0 = 0x4002957C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
…
(des0 = 0x40032B7C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
(des0 = 0x4003317C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
(des0 = 0x4003377C, des1 = 0x0, des2 = 0x0, des3 = 0x0),
(des0 = 0x40033D7C, des1 = 0x0, des2 = 0x0, des3 = 0x0))
When the xNetworkInterfaceOutput() is invoked by the stack the descriptor will be prepared as shown below.
p = 0x40034D10 -> (
des0 = 0x4002837C,
des1 = 0x0,
des2 = 0x8000002A,
des3 = 0xB0030000)
The des2 has to set the interrupt on completion bit and the size of the frame to be sent.
The des3 programs the FS, LS, CIC and OWN bits. So, the First and Last segment bits are set and the Hardware
will perform the checksum (CIC: Checksum Insertion Control.). The OWN bit is set because the descriptor has to
be managed by the DMA as soon as the TAIL pointer register is updated.
In this case, the xNetworkInterfaceOutput() is called to send a buffer of 42 bytes (0x2A) found at the address
pointed by the des0 (0x4002837C).
This buffer, for example, contains a broadcast frame and the MAC address of the Ethernet device is
10:20:30:40:50:60.
As soon as the packet is sent, the interrupt will notify the transmission status.
For example, below the status of the descriptor in write-back format: no error on the latest segment in this case.
Concerning the reception ring, all the descriptors are configured by the xNetworkInterfaceInitialise to be handled
by the DMA so, in the descriptor 3 the OWN bit is set and the Buffer1 is used.
DMARxDesc = (
(des0 = 0x400366D4, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x40036CDC, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x400372E4, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x400378EC, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
…
(des0 = 0x40040FB4, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x400415BC, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x40041BC4, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x400421CC, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000))
The prvNetworkInterfaceInput() is called by the ISR; it has to transfer a valid packet from the DMA buffer to the
TCP stack.
Below there is the status descriptor managed by the DMA, in write back format:
DMARxDesc = (
(des0 = 0x0, des1 = 0x11, des2 = 0x0, des3 = 0x3401015A),
(des0 = 0x40036CDC, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
(des0 = 0x400372E4, des1 = 0x0, des2 = 0x0, des3 = 0xC1000000),
From SPC5Studio, the source code will be available and the picture below shows the files organization inside the
project:
SPC5Studio offers different test applications for networking designed to start testing network protocols with a
default environment where signals and clocks are setup and TCP and Ethernet stacks are configured.
Many parameters, as described in the previous chapters, can be tuned.
Some features can be disabled or enabled according to the user needs.
From a remote host machine it will be also possible to open an FTP session and browse the RAM File System
moving files from/to the board under testing.
FreeRTOS+CLI (Command Line Interface) provides a simple, small, and extensible method of enabling your
FreeRTOS application to process command line input.
User can connect by using telnet command and a sub-set of commands are exposed to get statistics, to browse
the RAMFS and to ping a remote host.
/*
* UDP Logging Configuration Settings
*/
#if( ipconfigHAS_PRINTF == 1 ) || ( ipconfigHAS_DEBUG_PRINTF == 1 )
#define configUDP_LOGGING_NEEDS_CR_LF ( 1 )
/*
* The UDP port to which the UDP logging facility sends messages.
*/
#define configUDP_LOGGING_PORT_REMOTE 1500
#define configUDP_LOGGING_PORT_LOCAL 1499
/*
* Remote Host IP address
*/
#define configUDP_LOGGING_ADDR0 192
#define configUDP_LOGGING_ADDR1 168
#define configUDP_LOGGING_ADDR2 1
#define configUDP_LOGGING_ADDR3 1
#endif
On remote host, user can have a console by using netcat under Linux or udpterm_std under Windows (see output
below):
Note: tools mentioned above need to be configured to have the same UDP ports and IP server/client addresses.
13 Set up notes
The following figure shows the simple set up used for running all the applications.
14 Conclusion
This application note can be considered a sort of Getting started for any Reader that wants to run a real network
demo application on the SPC5x Automotive Microcontrollers.
The document reports the main parts to configure and have a full network stack working: TCP/IP, Ethernet and
Physical Layer.
The example code could have some differences from what is included in the latest official tool releases because
these are continuously improved in order to support new features, for example: Multiple Network Interface
support.
In any case, the code showed in the document can be considered the base reference code for programming the
Ethernet controller.
The application demos, based on FreeRTOS, also provide a real usage of the networking on SPC5x MCU
showing many of the potentialities of this hardware (DMA engine, check-summing) and also some basic
performance measurements are reported; that could be improved by applying further system (e.g. cache enable),
network stack tuning and driver optimizations, e.g. zero copy.
Table 1. Acronyms
Revision history
Contents
1 Ethernet overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Core Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 MAC Transaction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 DMA engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 DMA descriptor overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Application set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2.1 Signal configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Clock settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
List of figures
Figure 1. Descriptor ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 2. Pinmap editor table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 3. Pinmap wizard (Ethernet pins) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 4. FreeRTOS flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 5. SPC5Studio FreeRTOS outline view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 6. TCP/IP parameter view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 7. TCP/IP component view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 8. TCP/IP buffer allocation schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 9. UDP logging window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 10. HTTP and FTP server configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 11. Ethernet configuration inside the Network component view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 12. Generic Network flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 13. Tx descriptor 0 dump. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 14. Network compoent file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 15. SPC5Studio wizard – SPC58xGxx OS Network demos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 16. Ping from a remote Linux machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 17. Browsing the web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 18. FTP session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 19. Telnet session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 20. UDP console output example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 21. jPERF output – UDP RX test throughput measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 22. Network set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34