Rabbit® 4000 Microprocessor Designer’s Handbook 019-0156_H
Rabbit® 4000 Microprocessor Designer’s Handbook Part Number 019-0156 • Printed in the U.S.A. Digi International Inc. © 2007-2010 • All rights reserved. Digi International Inc. reserves the right to make changes and improvements to its products without providing notice. Trademarks ® Rabbit ® Dynamic C and RabbitCore® are registered trademarks of Digi International Inc. Windows® is a registered trademark of Microsoft Corporation. The latest revision of this manual is available at www.rabbit.com.
TABLE OF CONTENTS Chapter 1. Introduction ....................................................................................................................7 1.1 Summary of Design Conventions ............................................................................................................. 7 Chapter 2. Rabbit Hardware Design Overview ...............................................................................9 2.1 Design Conventions ..........................................................
5.2.4 The Stack Segment .........................................................................................................................27 5.2.5 The Extended Memory Segment ....................................................................................................28 5.3 Separate I&D Space.................................................................................................................................29 5.3.1 Enable Separate I&D Space .........................................
7.2.2 Reserved Flash Space..................................................................................................................... 64 7.2.3 Reading the User Block ................................................................................................................. 65 7.2.4 Writing the User Block ................................................................................................................. 67 Chapter 8. BIOS Support for Program Cloning.............................
rabbit.
1. Introduction This manual is intended for the engineer designing a system using the Rabbit 4000 microprocessor and Rabbit’s Dynamic C development environment. It explains how to develop a system that is based on the Rabbit 4000 and can be programmed with Dynamic C. With Rabbit 4000 microprocessors and Dynamic C, many traditional tools and concepts are obsolete. Complicated and fragile in-circuit emulators are unnecessary. EPROM burners are not needed.
As shown in Figure 1-1, the Rabbit programming cable connects a PC serial port to the programming connector of the target system. Dynamic C or the Rabbit Field Utility (RFU) runs as an application on the PC, and can cold boot the Rabbit 4000 based target system with no pre-existing program installed in the target. A USB to RS232 converter may also be used instead of a PC serial port.
2. Rabbit Hardware Design Overview Because of the glueless nature of the external interfaces, especially the memory interface, it is easy to design hardware in a Rabbit 4000-based system. More details on hardware design are given in the Rabbit 4000 Microprocessor User’s Manual. 2.1 Design Conventions Rabbit-based systems designed using the following conventions will provide a hardware base that is compatible with running Dynamic C applications. • Include a standard Rabbit programming cable.
2.1.1 Rabbit Programming Connector The user may be concerned that the requirement for a programming connector places added cost overhead on the design. The overhead is very small—less than $0.25 for components and board space that could be eliminated if the programming connector were not made a part of the system. The programming connector can also be used for a variety of other purposes, including user applications.
2.2 ESD Design Guidelines The following guidelines are recommended for designs incorporating a Rabbit 4000 processor with electrostatic discharge (ESD) sensitivity on VBAT. These guidelines are good 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.
2.5 Through-Hole Technology Most design advice given for the Rabbit 4000 assumes the use of surface-mount technology. However, it is possible to use the older through hole technology and develop a Rabbit 4000 system. One can use a Rabbit 4000-based Core Module, a small circuit board with a complete Rabbit 4000 core that includes memory and oscillators. Another possibility is to solder the Rabbit 4000 processors by hand to the circuit board.
3. Core Design and Components Core designs can be developed around the Rabbit 4000 microprocessor. A core design includes memory, the microprocessor, oscillator crystals, the Rabbit 4000 standard programming port, and in some cases, a power controller and power supply. Although modern designs usually use at least four-layer printed circuit boards, two-sided boards are a viable option with the Rabbit 4000, especially if the clock speed is not high and the I/O is intended to operate at 3.
Figure 3-1 Main Oscillator Circuit VBAT NC7SZU04 CLKI CLKIEN FDV303N Rp Rs 29.49 MHz 33pF 33pF The 32.768 kHz oscillator is slow to start oscillating after power-on. For this reason, a wait loop in the BIOS waits until this oscillator is oscillating regularly before continuing the startup procedure. The startup delay may be as much as 5 seconds, but will usually be about 200 ms. Crystals with low series resistance (R < 35 k) will start faster. For more information on the 32.
3.3 Basic Memory Design Normally /CS0 and /OE0 and /WE0 should be connected to a flash memory that holds the startup code that executes at address zero. When the processor exits reset with (SMODE1, SMODE0) set to (0,0), it will attempt to start executing instructions at the start of the memory connected to /CS0, /OE0, and /WE0. For Dynamic C to work out of the box, the basic RAM memory must be connected to /CS1, /OE1, and /WE1.
3.3.1 Memory Access Time Memory access time depends on the clock speed and the capacitive loading of the address and data lines. Wait states can be specified by programming to accommodate slow memories for a given clock speed. Wait states should be avoided with memory that holds programs because there is a significant slowing of the execution speed. Wait states are far more important in the instruction memory than in the data memory since the great majority of accesses are instruction fetches.
3.4 PC Board Layout and Memory Line Permutation To use the PC board real estate efficiently, it is recommended that the address and data lines to memory be permuted to minimize the use of PC board resources. By permuting the lines, the need to have lines cross over each other on the PC board is reduced, saving feed-through’s and space.
rabbit.
4. How Dynamic C Cold Boots the Target System Dynamic C assumes that target controller boards using the Rabbit 4000 CPU have no pre-installed firmware. It takes advantage of the Rabbit 4000’s bootstrap (cold boot) mode, which allows memory and I/O writes to take place over the programming port. Figure 4-1 Rabbit Programming Port Circuit Board with Rabbit 4000 Processor 5 6 7 9 8 10 RXA GND CLKA Vcc Programming Header Pinout /RESET TXA n.c. STATUS SMODE0 61 2 GND 3 113 4 +3.
When the programming cable connects a PC serial port to the target controller board, the PC running Dynamic C is connected to the Rabbit 4000 as shown in the table below.
The function of the boot ROM program depends on the settings of the pins SMODE0 and SMODE1 and on whether the high bit of the high address byte (first byte of a received triplet) that is loaded to register D is set. If bit 7 of the high address byte is set, then the data byte (last byte of the triplet) is written to I/O space when received. If the bit is clear, then the data byte gets written to memory.
6. The initial loader then reads 7 bytes from the serial port. First a 4-byte address field: the physical address to place the secondary loader, followed by a 2-byte length field: the number of bytes in the secondary loader. The 7th byte is a checksum (simple summation) of the previous 6 bytes. Whether or not the checksum matched, it is echoed back as an acknowledgement. 7. The data segment is then mapped to the given physical location, using the DATASEG register.
5. Rabbit Memory Organization The architecture of earlier Rabbit processors was derived from the original Z80 microprocessor. The original Z80 instruction set used 16-bit addresses to address a 64 KB memory space. All code and data had to fit in this 64 KB space. To expand the available memory space, the Rabbit 4000 adopts a scheme similar to that used by the Z180. The 64 KB space is divided into segments and the Rabbit’s Memory Mapping Unit (MMU) maps each segment to a block in a larger memory.
5.1.2 SRAM Static RAM may or may not be battery-backed. If the SRAM is battery-backed it retains its data when primary power is disconnected. SRAM chips typically used for Rabbit systems are 128 KB, 256 KB, 512 KB, or 1 MB. With the configurable physical memory of the Rabbit 4000 and support in Dynamic C 10.21 and later versions, static RAM chips of 1 MB and larger may also be used. When the memory is battery-backed, power is supplied at 2 V to 3 V from a battery.
5.2 Memory Segments From the point of view of a Dynamic C programmer, there are a number of different uses of memory. Each memory use occupies a different segment in the logical 16-bit address space. The four segments are shown in Figure 5-1. Figure 5-1 Memory Map of 16-bit Logical Address Space MMU Register Value 0x3FFFFF MECR = 0x40 0xFFFF 0xE000 Xmem Segment Quadrant 3 Stack Segment Root Data, etc.
Table 5-1 Selecting the Quadrant Size MECR Value Address Bits Used to Select Quadrant Quadrant Size Physical Address Space 11100000b A18, A17 128 KB 512 KB 00000000b A19, A18 256 KB 1 MB (default) 00100000b A20, A19 512 KB 2 MB 01000000b A21, A20 1 MB 4 MB 01100000b A22, A21 2 MB 8 MB 10000000b A23, A22 4 MB 16 MB One advantage of retaining the Rabbit 16-bit logical memory organization is that 16-bit addresses and pointers can reduce code size and execution times.
5.2.2 The Base (or Root) Segment The base segment has a typical size of 24 KB. The larger the base segment, the smaller the data segment and vice-versa. Base segment address zero is always mapped to physical address zero. Sometimes the base segment is mapped to flash memory since root code and root constants do not change except when the system is reprogrammed. It may be mapped to RAM for debugging, or to take advantage of the faster access time offered by RAM.
5.2.5 The Extended Memory Segment This 8 KB segment from logical address 0xE000 to 0xFFFF is a sliding window into extended code and it can also be used by routines that manipulate data located in extended memory. The xmem window uses up only 8 KB of the 16-bit addressing space. While executing code the mapping is shifted by 4 KB each time the code passes the halfway point in the 8 KB xmem window. The halfway point corresponds to the root address 0xF000, or 60KB.
5.3 Separate I&D Space Separate instruction and data space is a hardware memory management scheme that uses address line inversion to double the amount of logical address space in the base and data segments. In other words, this doubles the amount of root code and root data available for an application program.
Separate I&D logical addresses map to physical addresses by inverting address lines A16, the most significant address bit or both.The most significant address bit may be A18-A23, depending on the MECR setting. The MMU Instruction/Data Register (MMIDR) determines which lines are inverted. Please see the Rabbit 4000 Microprocessor User’s Manual for more information about the MMIDR.
When using separate I&D space you can not reference code as data or data as code in logical memory below the stack. When using separate I&D space, the processor makes a distinction between fetching an instruction from memory and fetching data from memory. The RAM segment register determines the window in RAM where root code may be executed. Embedded applications that do not need more code or data space do not require any changes for separate I&D space.
5.3.2.1 Compiling to RAM For RAM compiles, all banks (quadrants) are mapped to RAM. In a 20-bit physical address space (i.e., 1 MB physical address space), a 512 KB memory would be mapped with the lower 256 KB mapped to banks 0 and 2. The higher 256 KB are mapped to banks 1 and 3. In this configuration, A16 is inverted to provide access to the constants and data starting at the 64K boundary.
5.3.2.2 Compiling to Flash For flash compiles, flash is mapped to banks 0 and 1. The address range depends on the size of the physical address space. For example, a 20-bit address space with 512 KB of flash would mean that flash is mapped from 0x00000 to 0x7FFFF. Alternatively, a 22-bit address space (1 MB quadrants) with 1 MB of flash would mean that the flash is mapped to 0x000000 to 0x0FFFFF in bank 0 and is repeated again in bank 1 from 0x100000 to 0x1FFFFF.
address space for constants) and bit 3 enables inversion of MSB for the data space data segment (i.e., the logical address space for root data). 5.3.3 Customizing Interrupts No special code is required to customize interrupts using separate I&D space on the Rabbit 4000 with the addition of the RAM segment register (RAMSR). Use SetVectIntern() and SetVectExtern() to set interrupts. Please see the Dynamic C Function Reference Manual for more information on these functions. 5.
As the compiler compiles code for the extended code window, it checks to see if the code has passed the midpoint of the window or 0xF000. When the code passes 0xF000, the compiler generates code to slide the window down by 4 KB so that the code at F000+x becomes resident at 0xE000+x. This automatic paging results in the code being divided into segments that are typically 4 KB long, but which can be very short or as long as 8 KB.
rabbit.
6. The Rabbit BIOS When Dynamic C compiles a user’s program to a target board, the BIOS (Basic Input/Output System) is compiled first as an integral part of the user’s program. The BIOS comprises files that contain the code needed by the user program to interface with Dynamic C and the Rabbit hardware. The BIOS may also contain a software interface to the user’s particular hardware. Certain drivers in the Dynamic C library suite require BIOS routines to perform tasks that are hardware-dependent.
6.1 Startup Conditions Set by the BIOS The BIOS performs initialization tasks and #use’s library files that contain setup information. 6.1.1 Registers Initialized in the BIOS The BIOS sets up initial values for the following registers by means of code and declarations. MBxCR There are four memory bank control registers: MB0CR, MB1CR, MB2CR, and MB3CR. They are 8-bit registers, each one associated with a quadrant of the physical memory space.
6.2 BIOS Flowchart The following flowchart summarizes the functionality of the BIOS: Figure 6-1 BIOS Flowchart Start at address 0 Set up memory control and basic BIOS services. Yes Is the programming cable connected? Start Dynamic C communications and state machine. No Yes Divert to BIOS service? Act as master for cloning. No Call user application program (main). BIOS services for user application program.
6.3 Internally-Defined Macros Some macros used in the BIOS are defined internally by Dynamic C before the BIOS is compiled. They are defined using tests done in the bootstrap loading, or by reading variables set in the GUI or set by the CLC (command line compiler). Table 6-1 Partial List of Compiler-Defined Macros Macro Name Macro Description _BOARD_TYPE_ This is read from the System ID block or defaulted to 0x100 (the BL1810 JackRabbit board) if no System ID block is present.
6.4.1 Macros that Affect the BIOS There are several macros that may be modified for custom-designed boards or for special situations involving off-the-shelf Rabbit 4000-based boards. The following list is not exhaustive. CLOCK_DOUBLED Default value of 1 causes the clock speed to be doubled. Setting this to zero means the clock speed will not be doubled. To override the default, define CLOCK_DOUBLED to zero in the project by using the Defines tab of the Project Options dialog.
FLASH_SIZE Sets the amount of flash available. The default value is the internally defined _FLASH_SIZE_ The units are the number of 4 KB pages of flash. In special situations, such as splitting flash between two coresident programs, this may be modified to a smaller value than the actual available flash. RAM_SIZE Sets the amount of RAM available. The default value is the internally defined _RAM_SIZE_. The units are the number of 4 KB pages of RAM.
MBxCR_INVRT_A18, MBxCR_INVRT_A19 These macros determine whether the MIU registers for each quadrant are set up to invert address lines A18 and A19 after the logical to physical address conversion. This allows each quadrant of physical memory access up to four 256 KB pages on the actual memory device. These would be used for special compilations of programs to be coresident on flashes between 512 KB and 1 MB in size.
6.5.1.1 Example of Origin Declarations The code from memory_layout.lib provides a practical application of origins. In this section, several of the origin declarations in the memory layout library are explained. (To simplify matters, the conditional compilation macros regarding board type, compile mode and separate I&D settings in memory_layout.lib are not shown in this example.) A graphical representation of the regions defined by the origin declarations follows their explanation (see Figure 6-2).
#orgdef xcodorg xmemcode in flash above start to user_block Defining origins for the physical memory devices in a particular configuration is not enough for the compiler, so we need to define regions for code and data. The line above defines an origin for xmem code with “xcodorg” origin type, and called “xmemcode”. The compiler knows to use this origin for xmem code because of the origin type.
several other regions needed for buffers. For simplicity’s sake, none of them are shown here and they are not reflected in Figure 6-2.) Figure 6-2 Origins from memory_layout.
6.5.1.2 Origin Declaration Syntax Following is an EBNF (Extended Backus Naur Form) representation of the origin grammar facets: declarations, actions, and macros. Angle brackets (“<” and “>”) indicate non-terminals while terminals are represented literally with these exceptions: the “|” symbol represents a disjunction, the “::=” represents a definition, and the “[” and “]” symbols are used to enclose optional synatx.
Table 6-2 Origin Type Descriptions Origin Type Keyword Description flashorg Used for mapping flash; non-volatile. bbramorg Used for mapping RAM; battery-backed. fastramorg Used for mapping fast RAM. xconorg Used for mapping xmem constants. xcodorg Used for mapping xmem code xvarorg Used for mapping xmem data. xmemorg Reserved for future use. rconorg Used for mapping root constants. rcodorg Used for mapping root code. rvarorg Used for mapping root data.
The non-terminal “placement” denotes the placement of an origin within a larger parent space relative to the beginning of that parent (in the absence of the “in” qualifier, the parent can be considered to be all of the physical memory or “root”). The “placement” non-terminal is either the “fill” terminal or the non-terminal followed by the non-terminal “size.” The “vector” non-terminal is not a vector in the mathematical sense, but rather denotes a position and an orientation.
6.5.1.4 Origin Declaration Start and End Syntax The non-terminal start is simply the terminal “#orgstart”. It must occur exactly once and must occur before the end non-terminal. All origin declarations must follow this non-terminal. The non-terminal end is simply the terminal “#orgend”. It must occur exactly once and must occur after the start non-terminal. When the compiler encounters this non-terminal, it locks the definitions of the origins and performs final collision detection.
The aspect non-terminal represents an individual aspect of an origin. This non-terminal may be one of three things. It may be the "size" terminal, in which case the compiler assigns the size of the origin in bytes to the macro. It may be the "fragments" terminal, wherein the compiler will assign the number of fragments within the origin to the macro. Lastly, it may be the non-terminal quality followed by position as explained below.
Table 6-3 Origin Types Recognized by the Compiler Origin Type Keyword root code rcodorg xmem code xcodorg watch code wcodorg watch code wvarorg root data rvarorg root constants rconorg All code sections (rcodorg, xcodorg code and wcodorg) grow up. All non-constant data sections (rvarorg) grow down. Root constants are generated to the rcodorg region when separate I&D space is disabled. When separate I&D space is enabled, root constants are generated to the rconorg region.
#xcodorg yourcode 0x0 0x5000 0x500 then the origin statement: #xcodorg mycode 0x0 0x5500 0x500 follows yourcode tells the compiler to activate mycode when yourcode is full. This action does an implicit resume on the memory region identified by yourcode. In this example, the implicit resume also generates a jump to mycode when yourcode is full. For data regions, the data that would overflow the region is moved to the region that follows.
6.5.2.6 Origin Directive Examples The diagram below shows how the origin directives define the mapping between the logical and physical address spaces.
6.5.2.8 Origin Directive to Reserve Blocks of Memory With the Rabbit 4000, the compiler generates an origin table that contains the blocks that are reserved for code and data origin or other non-xalloc use. With this change, the method of reserving a block of memory so that xalloc() does not use it has also changed. To reserve a block of memory in DC 9.30 and later, the #resvorg should be used. All other origins (e.g., #rcodorg, #rvarorg, etc.
rabbit.
7. The System Identification and User Blocks The BIOS supports a System Identification block and a User block. These blocks are placed at the top of the primary flash memory. Identification information for each device can be placed in the System ID block for access by the BIOS, flash driver, and users. This block contains specific part numbers for the flash and RAM devices installed, the product’s serial number, Media Access Control (MAC) address if an Ethernet device, and so on.
7.1 System ID Block Details The BIOS will read the System ID block during startup. If the BIOS does not find an ID block, it sets all fields to zero in the data structure SysIDBlock. The user may access the information contained in the System ID block by accessing SysIDBlock. 7.1.1 Definition of SysIDBlock The following global data structures are defined in IDBLOCK.LIB and are loaded from the flash device during BIOS startup. Users can access this struct in RAM if they need information from it.
typedef int int int char long * int int int int int long * int int int int int long int int int long char char char struct { tableVersion; productID; vendorID; timestamp[7]; flashID; // // // // // version number for this table layout** Rabbit part # 1 = Rabbit YY/M/D H:M:S Manufacturer ID/ Product ID, 1st flash flashType; flashSize; sectorSize; numSectors; flashSpeed; flash2ID; // // // // // // Write method in 1000h pages size of flash sector in bytes number of sectors in nanoseconds * Manufacturer
7.1.2 Reading the System ID Block To read the ID block from the flash instead of getting the information from SysIDBlock, call _readIDBlock(). _readIDBlock int _readIDBlock(int flash_bitmap); DESCRIPTION: Attempts to read the system ID block from the highest flash quadrant and save it in the system ID block structure. It performs a CRC check on the block to verify that the block is valid. If an error occurs, SysIDBlock.tableVersion is set to zero.
7.1.2.1 Determining the Existence of the System ID Block In Dynamic C versions prior to 7.20, and for ID block versions 1 and 2, the following sequence of events is used by _readIDBlock() to determine if an ID block is present: 1. The 16 bytes at the top of the primary flash are read into a local buffer. (If a 256 KB flash is installed, the 16 bytes starting at address 0x3FFF0 will be read.) 2.
Table 7-1 The System ID Block (Continued) 62 Offset from start of block Size (bytes) 21h 2 Number of sectors in 2nd flash 2 23h 2 Flash access time, in nanoseconds, for the 2nd flash 4 25h 4 RAM ID 2 29h 2 RAM size, in 1000h pages 2 2Bh 2 RAM access time, in nanoseconds 4 2Dh 2 CPU ID 3 2Fh 4 Crystal frequency (Hertz) 2 33h 6 Media Access Control (MAC) address 1 39h 24 Serial number (as a null-terminated string) 51h 30 Product name (as a null-terminated string) 6Fh
7.1.3 Writing the System ID Block The WriteFlash() function does not allow writing to the System ID block. If the System ID block needs to be rewritten, a utility to do so is available for download from the Rabbit website: www.rabbit.com/support/downloads/downloads_feat.shtml or contact Rabbit’s Technical Support. 7.
7.2.2 Reserved Flash Space The macro MAX_USERBLOCK_SIZE (default 0x8000) in the BIOS tells the Dynamic C compiler how much flash at the top of the primary flash is excluded from use by the compiler for xmem functions. For any application, whether compiled to a single target board or for multiple target boards, the MAX_USERBLOCK_SIZE macro value defined in RabbitBios.c must not be lower than the amount of flash required for the System ID/User blocks on the target board with the largest requirement.
7.2.3 Reading the User Block readUserBlock int readUserBlock(void *dest, unsigned addr, unsigned numbytes); DESCRIPTION: Reads a number of bytes from the User block on the primary flash to a buffer in root memory. NOTE: portions of the User block may be used by the BIOS for your board to store values such as calibration constants. See the manual for your particular board for more information before overwriting any part of the User block. PARAMETERS dest Pointer to destination to copy data to.
readUserBlockArray int readUserBlockArray(void *dests[], unsigned numbytes[], int numdests, unsigned addr); DESCRIPTION Reads a number of bytes from the User block on the primary flash to a set of buffers in root memory. This function is usually used as the inverse function of writeUserBlockArray(). PARAMETERS dests Pointer to array of destinations to copy data to. numbytes Array of numbers of bytes to be written to each destination. numdests Number of destinations.
7.2.4 Writing the User Block writeUserBlock int writeUserBlock(unsigned addr, void *source, unsigned numbytes); DESCRIPTION: Rabbit-based boards are released with System ID blocks located on the primary flash. Version 2 and later of this ID block has a pointer to a User block that can be used for storing calibration constants, passwords, and other non-volatile data. This block is protected from normal writes to the flash device and can only be accessed through this function.
writeUserBlockArray int writeUserBlockArray(unsigned addr, void* sources[], unsigned numbytes[], int numsources); DESCRIPTION Rabbit-based boards are released with System ID blocks located on the primary flash. Version 2 and later of this ID block has a pointer to a User block that can be used for storing calibration constants, passwords, and other non-volatile data. The User block is protected from normal write to the flash device and can only be accessed through this function or writeUserBlock().
8. BIOS Support for Program Cloning The BIOS supports copying designated portions of flash memory from one controller (the master) to another (the clone). The Rabbit Cloning Board connects to the programming port of the master and to the programming port of the clone. This simple circuit can easily be incorporated into test fixtures for fast production.
8.2 Creating a Clone Before cloning can occur, the master controller must be readied. Once this is done, any number of clones may be created from the same master. 8.2.1 Steps to Enable and Set Up Cloning The step-by-step instructions to enable and set up cloning on the master are in Technical Note 207. In brief, the steps break down to: attaching the programming cable, running Dynamic C, making any desired changes to the cloning macros, and then compiling the BIOS and user program to the master.
8.3 Cloning Questions The following subsections answer questions about different aspects of cloning. 8.3.1 MAC Address Some Ethernet-enabled boards do not have the EEPROM with the MAC address. These boards can still be used as a clone because the MAC address is in the system ID block and this structure is shipped on the board and is not overwritten by cloning unless CL_INCLUDE_ID_BLOCKS is set to one.
rabbit.
9. Low-Power Design and Support With the Rabbit 4000 microprocessor it is possible to design systems that perform their tasks with very low power consumption. The Rabbit has several features that contribute to low power consumption. They are summarized here and explained in greater detail in the following section. • Special chip select features minimize power consumption by external memories. • The Rabbit core operates at 1.8 V. • The I/O ring can operate 3.3 or 1.8 V.
9.1 Details of the Rabbit 4000 Low-Power Features This section goes into more detail about the Rabbit 4000 low-power features. 9.1.1 Special Chip Select Features Unlike competitive processors, the Rabbit 4000 has two special chip select features designed to minimize power consumption by external memories. This is significant because, if not handled well, external memories can easily become the dominant power consumers at low clock frequencies.
9.1.2 Reducing Clock Speed It is important to know that the lowest speed crystal will not always give the lowest power consumption. This is because when the crystal is divided internally, the short chip select option can be used to reduce the chip select duty cycle of the flash memory or fast RAM, greatly reducing the static current consumption associated with some memories. Some applications, such as a control loop, may require a continuous amount of computational power.
9.2 To Further Decrease Power Consumption In addition to the low-power features of the Rabbit 4000 microprocessor, other considerations can reduce power consumption by the system. 9.2.1 What To Do When There is Nothing To Do For the very lowest power consumption the processor can execute a long string of mul instructions with the DE and BC registers set to zero.
9.2.3 External 32 kHz Oscillator Unlike the Rabbit 2000, the Rabbit 4000 has no internal 32 kHz oscillator. Instead there is a clock input. The recommended external crystal oscillator circuit and the associated battery backup circuit are discussed in Technical Note 235 available on our website: www.rabbit.com. 9.2.4 Conformal Coating of 32.768 kHz Oscillator Circuit The 32.768 kHz oscillator circuit consumes microampere level currents.
Functions are provided to power down the Realtek Ethernet chip as well. By calling the pd_powerup() and pd_powerdown() functions, the Realtek chip can be placed in and awakened from its own powerdown mode. Note that no TCP/IP or Ethernet functions should be called while the Realtek is powered down. 9.2.6 Baud Rates in Sleepy Mode The available baud rates in sleepy mode are 1024, 1024/2, 1024/3, 1024/4, etc. Baud rate mismatches of up to 5% may be tolerated. The baud rate 113.
10. Supported Flash Memories There are several flash memories that have been qualified for use with the Rabbit 4000 microprocessor. Both small and large sector flash devices are supported. To incorporate a large-sectored flash into an end product, the best strategy is have a small-sectored development board. Table 10-1 Flash Devices for Rabbit 4000-Based Designs Device Size (bytes) Write Mode Operating Voltage SST39LF040 512x8 byte 3.0-3.6V Starts w/ version 10 SST39VF040-70-41 512x8 byte 2.7-3.
10.2 Writing Your Own Flash Driver Rabbit does not support using a flash memory that is not listed above and that does not use the same standard 8-bit JEDEC write sequences as one of the supported flash memories. If you must use such a flash memory, the flash driver supplied with Dynamic C (LIB\Rabbit4000\BIOSLIB\FLASHWR.LIB) provides a model for writing your own flash driver. 80 rabbit.
11. Troubleshooting Tips for New Rabbit-Based Systems If the Rabbit design conventions were followed and Dynamic C cannot establish target communications with the Rabbit 4000-based system, there are a number of initial checks and some diagnostic tests that can help isolate the problem. 11.1 Initial Checks Perform the first two checks with the /RESET line tied to ground. 1. With a voltmeter check for VDDIO, VDDINT, VBAT and VBATIO for the correct voltages.
After extracting the files, double click on serialIO.exe to display the following screen. Click on Help at the top left-hand side of the screen for directions for using this program. A diagnostic program is a group of triplets. You can open the provided diagnostic programs (those files with the extension .diag) with Dynamic C or any simple text editor if you would like to examine the triplets that are sent to the target. Also serialIO.
11.2.2 Diagnostic Test #1: Toggle the Status Pin This test toggles the status pin. 1. Apply the reset for at least ¼ second and then release the reset. This enables the cold boot mode for asynchronous serial port A if the programming cable is connected to the target’s programming connector. 2. Send the following sequence of triplets. 80 0E 20 80 0E 30 80 0E 20 ; sets status pin low ; sets status pin high ; sets status pin low again 3. Wait for approximately ¼ second and then repeat starting at step #1.
11.2.3 Diagnostic Test #2 The following program checks the processor/RAM interface for an SRAM device connected to /CS1, /OE1, /WE1. The test toggles the first 16 address lines. All of the data lines must be connected to the SRAM and functioning or the program will not execute correctly. A series of triplets are sent to the Rabbit via one of the bootstrap ports to set up the necessary control registers and write several instructions to RAM.
3. The opcodes and their data are in the 2nd column of the Assembly window. Since we want each triplet loaded to RAM beginning at address zero, create the following sequence of triplets. ; code to be loaded in SRAM 00 00 21 00 01 01 00 02 00 00 03 06 00 04 10 00 05 7E 00 06 29 00 07 10 00 08 FC 00 09 C3 00 0A 00 00 0B 00 4. The code to be loaded in SRAM must be flanked by triplets to configure internal peripherals and a triplet to exit the cold boot upon completion.
D3 32 24 00;ioi ld (SPCR), a ; .forever: D3 3A 30 00;ioi ld a, (PADR) EE 01; xor 0x01 D3 32 30 00;ioi ld (PADR), a 01 0C 00;ld bc, 12 (use 24 vs. 12 for clock doubled vs. not doubled) ; .again0: 21 CC FB;ld hl, 64460 ; .again1: 2B; dec hl B1; ld de, hl CC; bool hl A1; ld hl, de 20 FA; jr nz, .again1 ED 10 F4;dwjnz .again0 18 E5; jr .forever \\Footer Block ; Insert Rabbit 4000 diagnostic code before this comment.
80 73 01;PEAHR = 0x01 (preset PE4 as /A0) 80 75 10;PEFR = 0x10 (PE4 is alternate output) 80 77 10;PEDDR = 0x10 (set PE4 as output) 80 1D 20;MACR = 0x20 (set basic 16-bit operation for /CS1) 80 C4 00;SACR = 0x00 (use pport C for Rx, 8-bit async mode, IRQ off) 80 A0 01;TACSR = 0x01 (enable timer A main clock) ;Address 1000 21 21 00;ld hl, 0x0021 00; nop 2B; dec hl 2B; dec hl 2B; dec hl 2B; dec hl (HL = 0x001D, i.e.
rabbit.
Appendix A: Supported Rabbit 4000 Baud Rates This table contains divisors to put into TATxR registers. All frequencies that allow 57600 baud up to 30MHz are shown (as well as a few higher frequencies). All of the divisors listed here were calculated with the default equation given on the next page. Crystal Freq. (MHz) 2400 baud 9600 baud 19200 baud 57600 baud 115200 baud 230400 baud 460800 baud 1.8432 23 5 2 0 a - - 3.6864 47 11 5 1 0 - - 5.5296 71 17 8 2 - - - 7.
The default equation for the divisor is: frequency in Hz- – 1 divisor = CPU ---------------------------------------------------32 baud rate If the divisor is not an integer value, that baud rate is not available for that frequency (identified by a “-” in the table). If the divisor is above 255, that baud rate is not available without further BIOS modification (identified by a “*” in the table).
INDEX A D A18 and A19 inversion ........................................... 43 access times ........................ 11, 15, 16, 38, 41, 61, 62 DATAORG ............................................................ 41 DATASEG register .......................................... 22, 38 debug mode ...................................................... 22, 76 design conventions ................................................... 9 memory chips .....................................................
macros, defined internally __SEPARATE_INST_DATA__ .........................40 _BOARD_TYPE_ ...............................................40 _CPU_ID_ ...........................................................40 _FLASH_ ............................................................40 _FLASH_SIZE_ ..................................................40 _RAM_ ................................................................40 _RAM_SIZE_ .....................................................40 CC_VER ................
Z ZERO_STATIC_DATA ......................................... 34 Rabbit 4000 Designer’s Handbookl rabbit.
rabbit.
