C6720 EMIF asynchronous behavior using 16bit data bus with EM_BA1

Could you give one or two examples where you show an address you're writing to and the corresponding address lines?

With the 16-bit interface the LSB of the address (EM_BA1) I believe will correspond to bit 1 of the address written to.  EM_A0 would correspond to bit 2 and so on.  Is that not what you're seeing?

Brad

I am using the memory setup according to SPRU711C, Fig 2.9B on pg 30.  EM_BA1 is A0, EM_A0-EM_A11 (i do not have an EM_A12 on this processor) are A1-A12 respectively and I have mapped MCASP pins as GPIO to cover A13-A19.

Here is the code I am using:

Function to perform the write:

void memsw(unsigned short* Address, unsigned short data)
{
    char x; 
    setadd13_19((unsigned int)Address); //this function will set address lines 13-19 using MCASP GPIO lines and the address passed to it.
    *Address=data;
    for (x=10;x>0;x--)
        {
        asm("     NOP");
        }   
}

Main Routine:

//Flash Prom Write enable setup
    USP=(unsigned short*)0x90005555;   
    memsw(USP,0xAAAA);                           //Write 1
    USP=(unsigned short*)0x90002AAA;   
    memsw(USP,0x5555);                           //Write 2
    USP=(unsigned short*)0x90005555;   
    memsw(USP,0xA0A0);                           //Write 3
    USP=(unsigned short*)0x9000A000;
    for (x=0;x<255;x++)    //Test write some info into PROM               
    {   
        usdata=usdata*0x100 | x;
        memsw(USP,usdata);
        USP++;
    }

I am using an emulator and have stopped after each of the write statements and have taken readings of the address bus.  I have changed the program around a little since yesterdays post.  The difference being, I was using byte writes instead of word(16) writes.  The behavoir is better but not perfect.

Write 1 does write to 90005555

Write 2 writes to 90002AAB      This is an issue!!

Write 3 does write to 90005555

seems like EMBA_1 is locked to 1 and not controllable.

Example of the problem initially seen:

Function wexdat:

void wexdat(unsigned char* Address, unsigned char wdata)
{
    unsigned char x;
    if (Address>=(unsigned char*)0x900C0000 && Address<(unsigned char*)0x900E0000)
        {//Write to On Board Peripheals
        *MC0_PDCLR=0xFFFFFFBF;
        *MC0_PDSET=0x00000C00;
        }
    else
        {//Write to Off Board Peripheals
        *MC0_PDCLR=0xFFFFFFBF;
        *MC0_PDSET=0x00000C10;
        }
    *Address=wdata;
    for (x=10;x>0;x--)
        {
        asm("     NOP");
        }     
}

Declarations in an include file:

unsigned char* dspgpio= (unsigned char*)0x900C0020;
unsigned char* analogch=(unsigned char*)0x900C0040;
unsigned char* pga_fs_disp=(unsigned char*)    0x900C0060;
unsigned char* keyenc=(unsigned char*)0x900C00A0;

Main function calls:

    wexdat(dspgpio,0x00);       //SET DSP GPIO OUTPUTS TO 0
    wexdat(keyenc,0x00);        //SET KEYBOARD AND USB SWITCHES TO 0   
    wexdat(analogch,0x00);       //SET ANALOG MUXES BOTH TO CHANNEL 1
    wexdat(pga_fs_disp,pga_fs_disp_dat);   //SET PGA TO SETTING 1, FILTER SWITCH TO MAX291 PROG SQ WAVE ON, & DISPLAY E & RS TO LOW.

while using the emulator and performing these functions and reading the address bus:

dspgpio reads 900C0010

keyenc reads 900C0050

analogch reads 900C0020

pga_fs_disp reads 900C0030

These read locations are the actual locations I expected to map, so I had already compensated for the problem by shifting my declarations.  However, I cannot play these kind of games while trying to access my memories.

To summarize I have 2 issues:

Shifting of the bus while writing a to byte Address and 8 bit data.

Control of EM_BA1 while writing to word(16) Address and 16 bit data.

After further evaluation I have determined that I have an error in the results posted.

dan kantorski said:

Write 1 does write to 90005555

Write 2 writes to 90002AAB      This is an issue!!

Write 3 does write to 90005555

seems like EMBA_1 is locked to 1 and not controllable.

This is not correct.  As I investigated further,  running through the loop and monitoring the address lines actually do have the same behavior as doing a byte write.

dan kantorski said:

    for (x=0;x<255;x++)    //Test write some info into PROM               
    {   
        usdata=usdata*0x100 | x;
        memsw(USP,usdata);
        USP++;
    }

Examples:

Initially the loop starts at 9000A000.  Bus has 9000A001

USP Pointer goes to 9000A002.  Bus still has 9000A001.

USP Pointer goes to 9000A004.  Bus has 9000A003

USP Pointer goes to 9000A006. Bus still has 9000A003.

USP Pointer goes to 9000A008.  Bus has 9000A005.

My apologies to many alternating 1s and 0s in the first 3 writes tested.

So, to re-summarize:

Performing a word(16) and/or a byte write, the Address bus are shifted as follows: 

No control on the EM_BA1 line.  EM_A0 pin is reflecting actual position of an "A2" bit.  EM_A1 pin is reflecting actual position of an "A3" bit and so on.  "A1" and "A0" bits are not translated through the write. 

In other words, before the translation to the bus, all bits in the anticipated address are shifted one position to the right and EM_BA1 does not follow the "A1" bit setting. 

A13-A16 are acting normal as they are controlled by MCASP port pins and software.

Dan,

As you are using the C6720 you have the RFP package. Are you measuring the address pins at the memory or on the DSP package? If measuring the memory try measuring them on the DSP as this should prove whether or not the problem is with the EMIF itself. You should never see any sort of shifting or permanent high bits like this.

Please post your EMIF configuration code.

I have not configured anything in the EMIF, after the Bootloader, so it is in the bootload afterstate.

However this is the information entered for the bootloader.

#====================================================================
# SDRAM Configuration
#====================================================================
 -sdramCfg 0

#====================================================================
# ASYNC Ram Configuration
#====================================================================
 -asyncRamCfg 0x1
 -asyncRamA1CR  0x3FFFFFFD
 -asyncRamAWCCR 0x10000080

Here is the state of the Registers while in the main program read from the emulator:

AWCCR    10000080    SDTIMR    0021CF00    EIMSR    00000000
SDCR    80000620    SDSRETR    00000019    EIMCR    00000000
SDRCR    00000190    EIRR    00000004       
A1CR    3FFFFFFD    EIMR    00000000

My tests were done at the memory, however, I have just ran another quick test looking at pins 94 EM_BA1 and pin 91 EM_A0 at the processor.  As I step through my Main source, EM_BA1 stays logic high and EM_A0 does not change until the pointer value of 9000A004 has been written.  If I reset using a push button, and trigger on the first edges, on a scope I see proper activity on the EM_BA1 line as it is bootloading.  And for sure it is bootloading properly as I have run applications on board, creating a DAC sawtooth communincating through the SPI1 serial port and accessing my on board peripherals through the address bus compensating for this shifting phenomenon.

I ran a test using word(32) writes and I am starting to grasp it.

When you consider that working with a 16bit data bus accessing 32bits and the scheme of 4 internal processor bytes of memory for each instruction - or one byte per processor memory location, it all comes together.  The EM_BA1 line becomes a switch to the lower word(16) and upper word(16).  When a 16bit r/w is performed you are transferring 2 8-bit memory locations to/from the processor.  So the EM_BA1 points to 2 sections of 2 different 8bit memory locations.  Programmatically, looking into the simulator/emulator a step to the pointer ie. (USP++) increments the memory location by 4, and thus ends up being the EM_A0 line.  So the shifting that I see is actually the fact that it is two 8 bit processor memory locations are transferred at one time, basically becoming invisible to the outside world (losing a bit).  So essentially, it is impossible to do a byte write on the EMIF bus working with a 16bit data bus.  And the expected memory locations you would write has to be compensated by a factor of 2 as well.

So the question is: Should it possible to do a word(16) write and have the control of the EM_BA1?  If so, how?

I don't see it, but something must be wrong with your software.  The control of EM_BA1 is very simple -- it's simply the 2nd least significant bit of the address you're writing to.  Your 32-bit writes are behaving correctly, but something must be wrong somehow with your 16-bit writes.

You may want to check out this thread too:

http://e2e.ti.com/forums/p/78/406.aspx#406