ETRAX 100LX Errata Sheet

Revision History

Revision Date
1.72005/09/13Section 7 USB host and supporting USB LS devices in hubs.
1.62004/04/05Section 5.3 sdram clock changed to reset_.
1.52004/03/04Trouble report 98 about SDRAM was readded. For trouble report 102, multiple of 30” was changed to “equals N*32 + 30”.
1.42004/02/23Trouble report #102 was added.
1.32001/12/13Added bug report 89.
1.22001/05/11Added Documentation Affected subsection.
1.12001/04/25Initial revision.

Introduction

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.

Known bugs

USB periodic transfer insertion (trouble report #82)

Affected versions

This bug is only present in ETRAX 100LX v2. It is corrected in 100LX v3.

Description

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.

Workaround

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.

Progress monitoring

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.

Time out

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.

Conclusion

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.

Documentation affected

  • Designer's Reference Manual, DMA chapter, DMA linked lists for USB section.
  • Designer's Reference Manual, DMA chapter, DMA descriptors section.

Asynchronous serial port break (trouble report #83)

Affected versions

This bug is present in both ETRAX 100LX v2 and ETRAX 100LX v3.

Description

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.

Workaround

Discard the received bytes that have framing error, and also discard the first byte received without error if it arrives immediately after a BREAK.

Conclusion

This issue has to be considered when implementing serial port drivers.

Documentation affected

N/A

CPU status record gets corrupted (trouble report #89)

Affected versions

This bug is present in both ETRAX 100LX v2 and ETRAX 100LX v3.

Description

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.

Workaround

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.

Conclusion

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.

Documentation affected

N/A

SDRAM can drive the bus after manual reset

Affected versions

This bug is present in both ETRAX 100LX v2 and ETRAX 100LX v3.

Description

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.

Workaround

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.

Conclusion

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.

Documentation affected

N/A

Multiply operations and cache behavior (trouble report #102)

Affected versions

This bug is present in ETRAX 100LX v1, ETRAX 100LX v2, and ETRAX 100LX v3.

Description

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.

Workaround

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.

Conclusion

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.

Documentation affected

N/A

USB host and supporting USB LS devices in hubs (trouble report #103)

Affected versions

This bug is present in ETRAX 100LX v1, ETRAX 100LX v2, and ETRAX 100LX v3.

Description

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.

Workaround

N/A

Conclusion

ETRAX 100LX does not support LS devices behind a FS hub.

Documentation affected

N/A

 
axis/etrax_100lx_errata.txt · Last modified: 2007/03/15 16:25 by kj
 
All text is available under the terms of the GNU Free Documentation License (see Copyrights for details).