Block descriptions

UM0804

10/25

Doc ID 16303 Rev 2

6.3

Ethernet subsystem

This subsystem is based on the Ethernet PHY STE100P (U9) and a connector (J9) that also

includes also all the required magnetics (Line transformer ratio 1:1).

Several LEDs are present to indicate the status of the line:

●

The green LED in the connector is driven on continuously when 100 Mb/s network

operating speed is detected.

●

The yellow LED in the connector blinks when there is TX or RX activity. This LED is

driven on continuously when the Link test detects a good link condition.

●

The yellow LED (D4) is driven on continuously when a full duplex configuration is

detected. This LED blinks at a 20 Hz frequency when a collision status is detected in

the half duplex configuration.

●

The yellow LED (D3) blinks at a 10 Hz frequency when ongoing receiving or

transmitting is detected.

●

The yellow LED (D2) is driven on continuously when 10 Mb/s network operating speed

is detected.

6.4

USB 2.0 subsystem

6.4.1

Host ports

The board has two host ports (J2) that are fully compliant with the USB 2.0 specification

(two controllers with one port each). This means that the two hosts can work in concurrent

mode with the maximum possible bandwidth. Each host has also full control of the VBUS

supplied by the ST2052 power switch that also provides overcurrent protection in case of a

short circuit in the USB cable.

6.4.2

Device port

A USB 2.0 device port is also provided (J1).

6.5

Debug interface

Two debug interfaces are provided:

1.

The JTAG interface can be used for "static" debug. This means that it is possible to set

a breakpoint and, when the system stops, to verify the contents of the memory and/or

registers and modify them if needed.

2.

The ETM9 interface can be used for "dynamic" debug. The ETM9 block embedded in

the SPEAr300 chip, sends all the information about the AHB transactions during the

code execution to the external trace box and the external box stores this information in

a local buffer. This makes it possible, by stopping the CPU activity, to analyze the actual

program flow. For example, if a particular data abort occurs, you can set a breakpoint

on the data abort location and then, when the breakpoint is reached, you can analyze

the buffer trace. With this information, it becomes a simple task to identify the event that

produced the problem.

The following configurations can be selected by setting SW2 bits [2:1].