xintf memory timing registers

there are two possible options available to me at this stage, I can either check the speed of access to the external memory map or I can try to get the program to work by modifying the "full memory map" cmd file.


there is info in the previously referenced post on dsp related about timing

What Simone has written is excellent advice, but you also need to set
up the external interface timing or your program will run much, much
more slowly. The default setting for the timing at hardware reset is
52 clock cycles for each read or write of the external RAM.

The boards we developed for our product with the 2812 have 128K words
of SRAM mapped to the XCS6AND7 chip select, twice as much as the
eZdsp. The SRAM is 15 ns access time. We also need to use the
external clock out at half the processor core speed, because that
clock is used by a CPLD and other logic that is 100 MHz max.

Here are our settings for the external interface generally, and this
particular chip select:

XintfRegs.XINTCNF2.all = 0x00004C17;
XintfRegs.XTIMING6.all = 0x00031629;

This gives us an external clock out of 70 MHz (our DSP runs at 5 times
a 28 MHz crystal), and SRAM read and write cycles of 4 clocks each.

The 2812 has an extremely long setup time for data read from external
memory, about 13 or 14 ns, so you need almost 0 ns RAM to be able to
read in 3 clocks. The write time could be 3 clocks, but since
external bus cycles always start on a rising edge of the external
clock, there is no overall savings for setting the write time to 3
clocks, another RAM access can't start during that fourth cycle
anyway.

I don't have the definitions of the fields in those registers handy,
but if you map the hex values into bits in the registers as defined in
the XINTF data sheet you should be able to figure them out.


here the bloke suggests that;

XintfRegs.XTIMING6.all = 0x00031629;

I have:

XintfRegs.XTIMING6.all = 0x04456447;

from the external interface documentation (SPRU067C) p27 the settings that they suggest are:

0x00031629

in binary

0000 0000 0000 0011 0001 0110 0010 1001

split up:

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 0 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 0 - READYMODE
(14) 0 - USEREADY
(13-12) 01 - XRDLEAD
(11-9) 011 - XRDACTIVE
(8) 0 - XRDTRIAL
(7) 0- XRDTRIAL
(6-5) 01 - XWRLEAD
(4-2) 010 - XWRACTIVE
(1-0) 01- XWRTRIAL

current

0000 0000 0100 0011 1111 1111 1111 1111

split up:

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 1 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 1 - READYMODE
(14) 1 - USEREADY
(13-12) 11 - XRDLEAD
(11-9) 111 - XRDACTIVE
(8) 1 - XRDTRIAL
(7) 1- XRDTRIAL
(6-5) 11 - XWRLEAD
(4-2) 111 - XWRACTIVE
(1-0) 11- XWRTRIAL

before I spend any more time on this one, I think I should just try to see if it works with their settings

I have put

/* external memeory timing setup */
XintfRegs.XTIMING6.all = 0x00031629;

into my iniitalisation routine

check first without the memory map adjusted

compiles, loads, does not run

commented out that line just to check it was the culprit

motor runs again

lets look at a direct comparison

X2TIMING - current: 1, chris: 0
scaling factor - 1 is default and doubles XWRLEAD, XWRACTIVE and XWRTRIAL. 0 keeps them the same

XSIZE - current: 11, chris: 11
these must be always written as 11, any other combination will result in incorrect XINTF behaviour.... interesting

READYMODE - current: 1, chris: 0
0 - synchronous, 1 - asynchrounous

USERREADY - current: 1, chris: 0
is XREADY used? 1 - yes, 0 no

XRDLEAD - current: 11, chris: 01
this defines the read cycle lead period
note that this is mulitplied by X2TIMING

00 - invalid
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

XRDACTIVE - current: 111, chris: 011
this defines the read cycle active wait period
note that this is mulitplied by X2TIMING

000 - 0
001 - 1 XTIMCLK cycle
010 - 2 XTIMCLK cycles
011 - 3 XTIMCLK cycles
100 - 4 XTIMCLK cycles
101 - 5 XTIMCLK cycles
110 - 6 XTIMCLK cycles
111 - 7 XTIMCLK cycles

XRDTRIAL - current: 11, chris: 00
this defines the read cycle trail period
note that this is mulitplied by X2TIMING

00 - 0
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

XWRLEAD - current: 11, chris: 01
this defines the write cycle lead period
note that this is mulitplied by X2TIMING

00 - invalid
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

XWRACTIVE - current: 111, chris: 010
this defines the write cycle active wait period
note that this is mulitplied by X2TIMING

000 - 0
001 - 1 XTIMCLK cycle
010 - 2 XTIMCLK cycles
011 - 3 XTIMCLK cycles
100 - 4 XTIMCLK cycles
101 - 5 XTIMCLK cycles
110 - 6 XTIMCLK cycles
111 - 7 XTIMCLK cycles

XWRTRIAL - current: 111, chris:01
this defines the write cycle trail period
note that this is mulitplied by X2TIMING

00 - 0
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

the most obvious change that I need to make is to avoid the use of xready

ie changing from

0000 0000 0100 0011 1111 1111 1111 1111

to
0000 0000 0100 0011 1011 1111 1111 1111
or
10000111011111111111111
or
4440063 in decimal
or
43BFFF in hex

compiles, loads, motor does not work and Xtiming6 does not change

when I try to define the same value (4456447) the motor works

try defining 4440063 in decimal rather than hex

motor works and userready is now 0 (not using xready)

change .ebss to zone6

builds, loads, motor does not work

try to avoid the avoid asynchronous (late)

10000110011111111111111
or
4407295


change back .ebss to DRAM for this trial

works - change to ZONE6

does not work

try chris' number but in dec

does not work - bedtime

tomorrow I should try to use the full_memory_map and modify it.

change back to 4407295 and dramho

works

on further checking, synchronous does not work. use 4440063

checking again - it does work - definetly bed time