| Revision History | |
|---|---|
| Revision 1.7 | 2005/09/13 |
|
Section 7 USB host and supporting USB LS devices in hubs. | |
| Revision 1.6 | 2004/04/05 |
|
Section 5.3 sdram clock changed to reset_. | |
| Revision 1.5 | 2004/03/04 |
|
Trouble report 98 about SDRAM was readded. For trouble report 102, multiple of 30" was changed to "equals N*32 + 30". | |
| Revision 1.4 | 2004/02/23 |
|
Trouble report #102 was added. | |
| Revision 1.3 | 2001/12/13 |
|
Added bug report 89. | |
| Revision 1.2 | 2001/05/11 |
|
Added Documentation Affected subsection. | |
| Revision 1.1 | 2001/04/25 |
|
Initial revision. | |
Table of Contents
- 1. Introduction
- 2. USB periodic transfer insertion (trouble report #82)
- 3. Asynchronous serial port break (trouble report #83)
- 4. CPU status record gets corrupted (trouble report #89)
- 5. SDRAM can drive the bus after manual reset
- 6. Multiply operations and cache behavior (trouble report #102)
- 7. USB host and supporting USB LS devices in hubs (trouble report #103)
This document lists known bugs in the ETRAX 100LX v2 (Axis part number 17854 IC ETRAX 100LX ASIC E2) and ETRAX 100LX v3 (Axis part number 18816 IC ETRAX 100LX ASIC E3), and possible work-arounds.
The USB controller fails to insert periodic transfers if a USB device persis- tently NAKs a CTRL transfer attempt in the first part of a USB frame. When the NAKed transfer hit the End Of Frame, then the first INTR transfer is tried, which immediately fails due to being too close to the frame end.
The problem presents itself if there exists both CTRL and periodic (INTR, ISO) traffic in a frame.
The problem disappears if the CTRL traffic is stopped or if the periodic traf- fic is stopped.
It does not work to set R_USB_PSTART to zero. At least one CTRL transfer would sneak through no matter what.
A workaround must rely on software as the trouble lies deep in the protocol procedure engine.
The most obvious workaround lies in avoiding periodic traffic if possible. If that is not an option, then more subtle workarounds must be used.
To detect that a transfer suffers from persistent NAKing, the software can check the progress by observing the data counters and / or pointers in the DMA descriptor(s) for the transfer. Excatly how depends on how the transfer is set up. If the counter / pointers doesn't move over a period of a few frames, then it suffers from persistent NAKing and the software should disable it for a period of time.
The USB standard states that a device must process a request in a setup trans- action within 500ms for standard requests, and within 5s for a class specific request. This can be used to avoid persistent NAKing.
A control transfer is built up from three different phases: setup, data and status. Each phase has its own descriptor. To time the issue of each phase, just put one at a time in the endpoint sub list at the apprpriate time.
If the device is compliant, then it shall have processed the request in the setup transaction when the data phase is issued.
Host mode USB applications should use ETRAX 100LX v3 if possible.
If ETRAX 100LX v2 must be used, is not recommended to use periodic transfer traffic in host mode.
When the serial port receiver receives a BREAK (rxd low for a long time), it will signal a 'framing error' and then immediately continue to receive a new byte, without waiting for a stop bit. This will result in new received bytes, with 'framing error' set, as long as the BREAK persists. At the end of the BREAK (i.e. rxd goes high) one garbage byte may be received without any error status.
Discard the received bytes that have framing error, and also discard the first byte received without error if it arrives immediately after a BREAK.
The data field of the CPU status record will get corrupted if a bus fault occurs during RBF restart at the second half of an unaligned data write cycle.
For MMU generated bus faults, the problem can be avoided by clearing the 'unaligned' bit in the 'Execution state' field of the CPU status record before returning. This will ensure that all data accesses are rerun from the start. The workaround is only needed for restarted write accesses, but it may be applied on all returns from MMU generated bus faults. See the ETRAX 100LX programmer's manual Format of the CPU status record section for a description of the CPU status record.
This issue has to be considered when implementing the bus fault handler for MMU generated bus faults. The problem is taken care of in the Linux kernel for ETRAX 100LX.
If a manual reset is given to ETRAX, i.e., the ETRAX reset pin is asserted, when the SDRAM drives the data bus, the SDRAM clock (produced by ETRAX) will stop. This can leave the SDRAM in a locked mode where it continues to drive the data bus. When ETRAX tries to read from address 0 (normally from flash) it fails.
The problem is related to the fact that the start and stop of the SDRAM clock is initiated from software. The SDRAM chip needs a few more clock cycles after the SDRAM clock disappears to exit this locked mode.
The solution used by Axis to eliminate this problem is to connect the SDRAM and system clock to a 2 input MUX and let the output from the MUX be controlled by the reset signal. When the reset is asserted (low), the system clock should be the input of the SDRAM chip(s) and when reset is deasserted (high), the SDRAM clock should be the input of the SDRAM chip(s). Se below.
This problem only affects the combination of SDRAM and manual reset without power cycle. If power is turned off and on, the SDRAM chip(s) will reset and ETRAX will boot normally.
A multiply operation may cause incorrect cache behaviour under some specific circumstances.
The problem can occur if the instruction following the multiply instruction causes a cache miss, and multiply operand 1 (source operand) bits [31:27] matches the logical mapping of the mode register address (0xb0....), and bits [9:2] of operand 1 matches the TLB register address (0x258-0x25f).
The problem only occurs if there is a valid mapping through the MMU to the mode registers. There is such a mapping in kernel mode or when the MMU is off. Normally there is no such mapping in user mode, and the problem will not occur in Linux user mode programs.
The compiler, beginning with version cris-dist-1.56, has a workaround for this problem.
Manually written assembly code needs to be reviewed and possibly edited as per conclusions: when in delay-slots, muls and mulu need to be moved before the jumping instruction, and the delay-slot instead filled with a nop.
All occurrences of muls and mulu that can not otherwise be
asserted as not being last on a cache-line, are recommended to
be forced to an address that is a multiple of four by prepending
each with a nop-filling assembly alignment directive, like
.p2alignw 2,0x050f.
In code where the TLB registers are accesible, muls and mulu should not be located at addresses that equals N*32 + 30 (last in a cache-line), nor in delay-slots where the jump instruction may target a different cache-line.
The ETRAX100LX USB interface can not handle lowspeed (LS, 1.5 Mbit/s) devices connected to a hub. Transmitting data (including preamble) works, but the root- hub and the receiver fails to receive data or handshake. This leads to no support for LS devices behind a USB hub. LS devices directly connected to one of the ETRAX 100LX USB ports will work.