NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on The site is now set to read only.

External Interface XINTF Type 0 FAQ for C2000

From Texas Instruments Wiki
Jump to: navigation, search



This topic is a list of frequently asked questions that users have when using the C2000 External Interface (XINTF) of type 0.

XINTF type 0 is the first XINTF module released for the C28x devices. This type is found on the and 2812 devices. Type 1 is very similar to type 0 so many of the FAQ's will also apply here. Refer to External_Interface_(XINTF)_Type_Differences for more information on type differences.

Electrical Specifications

Electrical specifications can change between devices, peripheral types and device families. Always refer to the data manual and errata for a particular device for Electrical Specifications.

This page is obsolete and no longer maintained. Refer to C2000 Real-Time Control Peripherals Reference Guide (spru566m) for peripheral type information.

--Lheustess (talk) 15:03, 27 July 2018 (CDT)

Refer to External_Interface_(XINTF)_Type_Differences for more information on type differences.

Frequently asked questions for XINTF Type 0

Strobe/Signal Behavior

Q: When the external memory interface is enabled, how do the XINTF buses and control lines behave during accesses to internal memory?

The control signals would be placed in an inactive state if the CPU is accessing internal memory. These control signals are only activated when the CPU is accessing one of the 3 zones for the XINTF. There is a footnote in the timing diagrams of the XINTF that indicates the XA[] address bus holds the last address put on the bus during the inactive cycles. The XD[] data bus would go into a high-impedance state.

Q: Is there any need for pull-up or pull-down resistors to hold the external memory in a safe, inactive, state when the CPU is accessing internal memory?

The strobes will be forced to a high state and the address lines will hold their last value. There is no reason to put external pull-up's or pull-downs.

Q: Will the chip select line stay low during back-to-back accesses to the same zone?

Yes. Although keep in mind all accesses begin on the rising edge of XCLKOUT. For this reason, if there is a divider between XTIMCLK and XCLKOUT and the access ends on the falling edge of XCLKOUT, then there will be alignment cycle(s) between back-to-back reads where the chip select will go high. This alignment to wait for the next rising edge of XCLKOUT to start the next access.

Q: What if I need the chip select signal to go high between any two accesses?

If you are not using XREADY, then you can use the fact that all accesses begin on the rising edge of XCLKOUT to achieve this. Configure the timing such that an access will end on the falling edge of XCLKOUT. This will create the alignment cycle mentioned above. For example, if XCLKOUT is 1/2 XTIMCLK and the access time is an odd number of XTIMCLK cycles, then the access will always end on the falling edge of XCLKOUT. The XINTF will go inactive, including the chip select, until the next rising XCLKOUT edge.
If you are sampling XREADY, then there is no real way to control whether the number XTIMCLK cycles in an access is even or odd. In this case the chip select may stay active or it may go inactive depending on when XREADY indicates the external device has completed the operation. You could try adding delays between XINTF accesses in your application. In this case disabling the write buffer would help as well.

Q: Can I be sure that all read accesses terminate with the XRDn signal going high (inactive), even during back-to-back read operations?

Yes -
  • XRDn is high during lead cycles - at least 1 lead is required for all accesses
  • XRDn is low during the active cycles
  • XRDn is high during trail cycles even for back-to-back accesses.
You can add more lead and trail time if you need XRDn to be high longer.

Errors Accessing External Memory/Peripherals

Q: I tried to load code into XINTF, but get an error: "Data verification failed at address 0x3FFFC0. Please verify target memory map."

This address is in XINTF zone 7. On the 281x make sure that the MP/MC pin is high and then reset the device in order to enable the zone. If MP/ MC is low at reset the boot ROM will be enabled instead of zone 7.

Q: I want to run code from XINTF zone 2 on the eZdsp but it doesn't work.

The eZdsp doesn't have RAM connected to each zone. Check your eZdsp manual - I believe RAM is only connected to zone 7 on this platform.

XINTF Speed and Timing

Q: I read somewhere that the XINTF can run a maximum of 75MHz. Where does this number come from?

The number assumes that XINTF timing (XTIMCLK) is configured to be equal to SYSCLKOUT. The lead period of a read or write access has to be a minimum of 1. This is a design requirement of the XINTF. Thus for a SYSCLKOUT = XTIMCLK = 150MHz the fastest access is 1 lead waitstate or 75MHz. Of course this access time is theoretical and assumes that the external device being accessed can meet the same timing (probably not the case!).

Q: If the maximum speed of the XINTF is 75MHz (see previous question) then why can't I access the 12ns SRAMs on the eZdsp at that speed?

Two things to keep in mind:
  1. Although the external interface can be configured for 75MHz operation, it has been our experience that operation beyond 50MHz is quite difficult as you must meet the timing requirements of the device you are interfacing to.
  2. The user should check the access timing of the SRAM from output enable to data being available. With a Lead of 1, then the access time is dominated by the output enable. That is why a lead-active-trail timing of 1-0-0 won't work. A lead-active-trail of 1-1-0 timing is probably on the edge (50MHz). That's why a lead/active/trail of 1-2-0 timing works (37.5MHz).
Always check the data manual for the timing information.

Q: What are good XINTF timings to use on the EzDSP?

For the on-board 12ns RAMs the XINTF must be configured such that the timing meets that required of the RAMs. Refer to the data sheet for the RAMs as well as the XINTF ref guide. Here is an example of acceptable timings.
    //  Applies to all zones---------------------------------
    // Timing for all zones based on XTIMCLK = SYSCLKOUT 
    XintfRegs.XINTCNF2.bit.XTIMCLK = 0;
    // Buffer up to 3 writes
    XintfRegs.XINTCNF2.bit.WRBUFF = 3;
    // XCLKOUT is enabled
    XintfRegs.XINTCNF2.bit.CLKOFF = 0;
    XintfRegs.XINTCNF2.bit.CLKMODE = 0;

    // Zone 6------------------------------------
    XintfRegs.XTIMING6.bit.XWRLEAD = 1;        // must be >= 1 (XINTF requirement)
    XintfRegs.XTIMING6.bit.XWRACTIVE = 1; 
    XintfRegs.XTIMING6.bit.XWRTRAIL = 1;
    // Zone read timing
    XintfRegs.XTIMING6.bit.XRDLEAD = 1;        // must be >= 1 (XINTF requirement)
    XintfRegs.XTIMING6.bit.XRDACTIVE = 2;      // must be 2 or more to insure the data is there in time to be latched
    XintfRegs.XTIMING6.bit.XRDTRAIL = 0; 
     // do not double all Zone read/write lead/active/trail timing 
    XintfRegs.XTIMING6.bit.X2TIMING = 0;
     // Zone will not sample READY 
    XintfRegs.XTIMING6.bit.USEREADY = 0;
    XintfRegs.XTIMING6.bit.READYMODE = 0; 
     // Size must be 1,1 - other values are reserved
    XintfRegs.XTIMING6.bit.XSIZE = 3; 

    Repeat for Zone 7

Q: Is there an example that shows how to setup the XINTF waitstate registers?

Download the C281x C/C++ Header Files and Peripheral Examples in C (sprc097) from TI's external web. Refer to the project in the examples/run_from_xintf directory.


Q: If the processor accesses XINTF when the XHOLDAn signal is low, what happens?

It depends if the access is a read or a write:
  • Reads: If you perform an access while XHOLDAn is low, it will stall the processor on reads.
  • Writes: For writes, if the write buffer is enabled and not full, then it will not stall the processor.

Q: If the processor is halted due to XHOLDAn and an interrupt occurs will the processor remain in the halted state until the external memory bus is free?

Yes - It is desirable in such cases to design a system such that any external HOLD request is kept to a minimum duration - OR - to poll the current state of the HOLD or HOLDA signals and see if a request is pending before making an access.