MOD5441X FlexBus using CS1

[seulater]

I am trying to use CS1 to connect a LCD to the address & data bus.
The lcd has a "RS" pin meaning 1=command & 0=data. I figured that I could connect this pin to A1 to accomplish this.
I have CS1 working but something strange is going on that i cannot figure out.
Here is the code I have.

Code: Select all

#define BASEADDRESS 0x00000000
#define LCD_COMMAND BASEADDRESS
#define LCD_DATA	BASEADDRESS + 2

//Enable Chip Select 1 for LCD
sim2.cs[1].cscr = 0x007FFC40;
sim2.cs[1].csmr = 0x00000001;
sim2.cs[1].csar = ( BASEADDRESS >> 16 );


while(1)
{
	*(unsigned short *)(LCD_COMMAND) = 0x03;

    	for(int t=0;t<50;t++){
    		asm("nop");
    	}

    	*(unsigned short *)(LCD_DATA) = 0x00;

       OSTimeDly(10);
}

what is strange is that the value I give to LCD_COMMAND or LCD_DATA affects the A0 pin during the write.
For instance if i *(unsigned short *)(LCD_COMMAND) = 0x00, A0 should be low which it is. Yet if i change it to a 1 then A0 goes high during the write. Why is this ? I am writing to the same memory location so how does the data affect the address pins.

[pbreed]

You have the device set up s an 8 bit port...

You are writing 16 bit values... (You defined it as pointer to short)

So for every short write you will see two byte writes....


So writing 1234

One write 34 A0=0 A1=0
One write 12 A0=1 A1=0

[seulater]

That idea hit me later, I changed it to
*(unsigned char *)(LCD_COMMAND) = x;

yet A1 still does the same thing.
for every pass through the loop I should see 2 CS. For the First CS A1 should be low and the second A1 should be high, no matter what the value passed to it is.

I also changed the code to the following, and If i leave it running I will get a 4.12us CS pulse, now and then. Is anything else using CS1 ?
Why would it fire ? If I switch to CS4, the same thing happens.

Code: Select all

#define BASEADDRESS 0x00000000
#define LCD_COMMAND BASEADDRESS
#define LCD_DATA	BASEADDRESS + 2

void UserMain(void * pd)
{
    InitializeStack();
    OSChangePrio(MAIN_PRIO);
    EnableAutoUpdate();


	//Enable Chip Select 1 for LCD
	sim2.cs[1].cscr = 0x2140;
	sim2.cs[1].csmr = 0x00000001;
	sim2.cs[1].csar = ( BASEADDRESS >> 16 );


    iprintf("Application started\n");


	*(unsigned char *)(LCD_COMMAND) = 1;
	*(unsigned char *)(LCD_DATA) = 1;


    while (1)
    {
        	OSTimeDly(10);
    }
}

screenshot.jpg (131.09 KiB) Viewed 6592 times

[seulater]

Found the issue.
sim2.cs[1].csar = ( BASEADDRESS >> 16 );

I nabbed this example from Databus-IO-Expansion.pdf on the MOD5441x Page.
According to the manual bits 31-16 define the Base Address, not 15-0. So a quick change to:
sim2.cs[1].csar = ( BASEADDRESS );

Resolved the spurious extra CS pulse about every few seconds or so.

[mbrown]

You also mentioned your issues with the memory regions you're talking to. A useful set of documents to keep in mind is the Netburner memory maps available in the \nburn\docs\Platform directory. In it you'll see that 0x00000000 is reserved for trapping null pointers, as well as several other portions of memory that are dedicated for other peripherals(DDR2, RAM, parallel flash, system config, user params, ...). In the MOD54415.pdf document, you'll note that the regions 0x02000000 to 0x3FFFFFFF and 0xC2000000 to 0xDFFFFFFF are unused and available for your applications.

[seulater]

Thanks! that is exactly what I was looking for.