Rabbit 4000 Microprocessor
User's Manual
PREV INDEX NEXT

Appendix B. Rabbit 4000 ESD Design Guidelines and Bug Workarounds

The Rabbit 4000 began shipping in 2006, and has undergone one minor respin since that time. Several bugs were found in the design after the chip was produced, and are discussed in this appendix.

B.1 ESD Sensitivity

A small number of the original Rabbit 4000 LQFP processors had somewhat greater ESD sensitivity between the VBAT pin and VSSCORE, making the VBAT pin more sensitive to ESD events than any of the other pins. Devices with the following markings have this sensitivity.

There is no danger to the chip as long as normal ESD precautions are taken, and there is no greater ESD sensitivity on the VBAT pin once the chip is installed in a design as long as the design guidelines recommended below are followed.

The design was respun to improve the ESD protection on the VBAT pin. Rabbit 4000 processors with the following markings have this additional protection:

NOTE All Rabbit processors are sensitive to ESD, and should be handled appropriately.

B.1.1 ESD Design Guidelines

The following design guidelines are recommended for designs incorporating a Rabbit 4000 processor with ESD sensitivity on VBAT. Note that these guidelines should be considered standard for all Rabbit Semiconductor products, and are good design recommendations for all Rabbit processors.

  1. The 1.8 V supply for VBAT should be provided by a regulator with at least 2 kV ESD protection (human body model).

  2. The 3.3 V supply should have smaller 0.1 µF, 0.01 µF, and 2.2 nF bypass capacitors throughout the layout. In addition, the 3.3 V supply should also have a large value bulk capacitor (10 µF).

  3. The power going to VBAT should also be protected by a diode and two resistors. See a Rabbit Semiconductor schematic for a RabbitCore module based on the Rabbit 4000 for more details.

B.2 Bugs

The following bugs have been identified in the Rabbit 4000 design, and are present in all devices currently available.

  1. Primary/secondary watchdog timer interaction — if the secondary watchdog timer is enabled when a primary watchdog timeout occurs (resetting the processor), the secondary watchdog timer is still enabled when the device comes out of reset, which is not the documented behavior (the secondary watchdog should be disabled on reset).

    The BIOS provided by Rabbit Semiconductor in Dynamic C avoids this bug by disabling the secondary watchdog on startup or reset by writing 0x5F to WDTCR. The secondary watchdog timer is then enabled if needed with the #define USE_SECONDARY_WD macro.

  2. Stack protection/DMA interaction — when stack protection is enabled and a DMA transfer is occurring, the stack protection interrupt will occur if the lower 16 bits of a DMA transfer's physical write address match the 16 bits of the stack protection's logical address limits.

  3. DMA/HDLC/Ethernet interaction — a specific bug can manifest itself when the following conditions are present.

    · The HDLC or Ethernet peripherals are being fed bytes for transmit via DMA.
    · The current DMA buffer has been marked with "special treatment for last byte."
    · The buffer has not been marked as "final buffer."
    · The DMA fills the transmit FIFO with the next-to-last byte of the buffer and then either switches to another channel or releases the bus.
    · The DMA then returns to the channel before the transmitter has had a chance to transmit a single byte, freeing space in the transmit FIFO.

    When all these conditions occur, the DMA will overwrite the next-to-last byte in the transmit FIFO, and that particular byte will never be transmitted.

    There are several ways to avoid this bug.

    · Always mark the buffer that contains the end-of-frame byte as the final buffer, and restart the DMA once that buffer has been transmitted.
    · Make sure that the DMA will not return to this channel before the transmitter has sent one byte from the transmit FIFO.
    · Place the end-of-frame byte in a separate DMA buffer.

    The Ethernet driver provided by Rabbit Semiconductor in Dynamic C is written so that this bug never occurs.

  4. DMA/block copy interaction — when a DMA transfer occurs during a block copy instruction (LDIR, LDDR, COPY, COPYR, UMA, or UMS) while executing code out of 16-bit memory with the "advanced 16-bit mode" enabled, the code prefetch queue and program counter will become out-of-synch. This means that one or two incorrect bytes (depending on the 16-bit alignment of the instruction) are reloaded and presented to the processor as instructions when execution is "rewound" after the DMA transfer. The result of this mismatch is that the block copy instruction does not complete.

    The only way to prevent this from occurring is to prevent DMA transfers during block copy instructions, either by disabling the DMA or by increasing the processor priority above the priority of the DMA transfer.

    There is a workaround. The processor's BC register is used as a program counter by the block copy instructions, and will be nonzero if the block copy instruction did not complete. By checking the value of BC and jumping back to the block copy instruction if it is nonzero, the block copy instruction is restarted with all the current register values (source and destination pointers) and will continue where it left off. Rabbit Semiconductor's Dynamic C compiler automatically includes this wrapper code whenever it identifies a block copy instruction.

  5. Single-byte timed and external DMA requests to internal I/O registers — when timed or external DMA requests are enabled and set to transfer a single byte at a time to an internal I/O register, two bytes will actually be transferred.

    The simplest workaround is to double each data byte in the buffer; two bytes will be transmitted, but they will be identical, so the actual I/O register setting will not change.

  6. Wait states when moving from advanced 16-bit mode to basic modes — a wait state may be missed when certain instructions transfer execution from a device operating in the advanced 16-bit mode to a device operating in a different memory interface mode. Depending on the characteristics of the memory being accessed, this can lead to a missed or incorrect instruction byte being read.

    The exact circumstances that cause the missed wait state are complicated to predict because they involve the advanced 16-bit operating mode. In this mode a semi-autonomous prefetch mechanism fetches words from a 16-bit memory to feed to the instruction decoder. The fetched instruction bytes are presented to the instruction decoder on an as-needed basis, which is only loosely coupled to the operation of the external memory bus.

    The bug can only occur if the following conditions are met.

    1. One of these three instructions is used — JP (HL), JP (IX), or JP (IY).
    2. The jump is from a memory using the advanced 16-bit mode into a memory that is not using the advanced 16-bit mode.
    3. The destination memory requires wait states.

    Whether the bug occurs is a function of when the instruction decoder accepts the JP instruction relative to the fetch of the next instruction on the bus. This in turn depends on both the instructions immediately prior to the JP instruction and the number of wait states used by the prefetch mechanism.

    The simplest workaround is to not use the instructions listed above. The same operation can be handled by the following code sequence.

This code sequence will take more clocks to execute.

Another way to avoid the bug is to increase the number of wait states, if possible, on the device operating in the basic mode. Using this option will produce a loss of performance.

Finally, this bug is best avoided by not using the basic 16-bit mode unless absolutely necessary. It is highly likely that any SRAM device that you are executing code in will support the advanced 16-bit mode with byte-writes enabled, which will also improve the overall performance as a result of the 16-bit data fetches.

Rabbit Semiconductor
www.rabbit.com
PREV INDEX NEXT