K60 FlexBus for MRAM and LCD

[weblar]

I'm putting together a custom schematic which uses the FlexBus in multiplexed mode with 16bits for data and 16bits for the address.

I've connected FB_AD[0:15] to the address logic signals of an MRAM device and FB_AD[16:31] to the data logic signals with FB_BE7_0 and FB_BE15_8 connecting to the low byte, high byte pins of the MRAM device respectively. The relevant FB_OE_B and FB_RW_B signals are also connected.

I've also hooked up an LCD display working in 16bit 6800 mode to the FlexBus with FB_AD[16:31] connecting to the LCD_D[0:15] signals. The FB_RW_B signal also connects to the LCD_RW signal with the LCD_E pulled high.

FB_CS0_B is assigned to the MRAM and FB_CS1_B is assigned to the LCD.

Is the above configuration correct in terms of having the 16bit address and data buses round the right way? What do I do with the LCD_RST and LCD_DC signals - how do they map to the FlexBus?

I'm trying to work back from the TWR-LCD and TWR-MEM schematics and link through to the TWR-K60N512 schematic but I'm just getting confused.

Thanks in advance,

K

[weblar · Accepted solution]

Ok, so after some tinkering around and re-writing code I've finally managed to get it all working.

The issue was to do with the FB_CS2 bit in GROUP4 of the FB_CSPMCR register. Now it is set, the whole thing just works.

Amazeballs!

K

[joelesco]

Hi Kevin !

Can I ask you which driver do you use for the SSD1963?

Thanks a lot !

[weblar]

Hi Joe,

I'm not sure what you mean, which driver?

The LCD controller is the SSD1963 and I'm using the FlexBus interface to communicate with the controller.

Does that help?

Thanks,

Kev

[joelesco]

Yes but you use a driver for the SSD1963 no ?

[weblar]

Sorry, I was being stupid before - yes, I do use a driver.

It was based on a driver which I've previously used for a Kitronix 320x240 display using the TI grlib (naughty me!).

At present, my driver supports both landscape and portrait mode but its still work-in-progress.

[joelesco]

Thanks a lot to answering so fast ! So you develop your own driver cause there's no driver all ?

So much work i supposed ! I'll try also to make something correct !

Merci !

[weblar]

There are examples of other drivers.

For example, I Googled an SSD1963 driver for the Freescale eGUI platform and managed to find a driver which someone had written.

The only reason I wrote a driver for the grlib is because I already had a working platform which used grlib and wanted a very quick and easy solution using the SSD1963. In future, I will be creating my own version of a graphics library as I wish to implement some basic 3D or geometric shape support but that won't be for a while.

If you need any help with the SSD1963, post back.

[anthony_huereca]

Hi Kevin,

  The LCD_RST is the reset signal, to reset the LCD back to the default state. That is connected to the reset_out pin on the elevator, which is driving by a GPIO so that the MCU can decide when/if to reset the LCD.

  The LCD_DC signal is used to determine if the bits being sent to the LCD are a command or data. To simplify matters on the TWR-LCD, it's tied to FB_AD16, so that the address can be used to specify if we are sending a command, or if we're sending data. But it could also be driven with a GPIO pin. You can check out this app note for more information on the Flexbus, and it includes a section about connecting MRAM and the LCD.

-Anthony

[weblar]

Hi Anthony,

Thanks for your reply.

Sorry, what I meant was which FB pin should I assign the LCD_DC signal to?

I've actually re-mapped the LCD signals so that the LCD_D[0:15] connect to FB_AD[0:15] rather than FB[16:31].

Would I be correct in assigning the LCD_DC signal to FB_AD[16] as per the TWR-LCD. Like you mention, I can then use the address to specify whether I'm sending data or a command.

I guess I'm just needing confirmation that I'm trying to use the FlexBus correctly.

Thanks,

K

[anthony_huereca]

Hi Kevin,

  Yes, that would be how to do it. Some details from the app note:

For sending command and data the below functions were used. Notice that the only difference is the address where the

data is sent. 0x6000000 (FB_AD16 is low) is used to access the index register and address 0x60010000 (FB_AD16 is

high) to access the data buffer.

void vfnSendDataWord(unsigned short value)

{

*((unsigned short*)FLEX_BASE_ADDRESS) = value;

}

void vfnSendCmdWord(unsigned short cmd)

{

*((unsigned short*)FLEX_DC_ADDRESS) = cmd;

}

[weblar]

Hi Anthony,

Having referred to the FlexBus app note, I'm now a little bit stuck.

I have the LCD display hooked up to the Kinetis K60 tower stack through a custom circuit board. As previously mentioned, I've used FB_AD[15:0] to connect to the LCD_D[15:0] with LCD_DC connected to FB_AD[16] and FB_CS0 connected to the CS of the display.

I've managed to get the display working via bit-banging GPIO in 6800 mode (the display driver is an SSD1963 device).

When I try to swap over to use the FlexBus, nothing happens. My FlexBus initialization code looks like this...

#define FLEX_BASE_ADDRESS  0x60010000

#define FLEX_DC_ADDRESS    0x60000000

#define FLEX_ADDRESS_MASK   0x00010000

void flexbus_init(void) {

  // Initializes the FlexBus peripheral

  SIM_SOPT2 |= SIM_SOPT2_FBSL(3);

  SIM_SCGC7 |= SIM_SCGC7_FLEXBUS_MASK;

  FB_CSAR0 = FLEX_DC_ADDRESS;

  // Set up the FlexBus for 16bit port, right adjusted with auto-ack

  FB_CSCR0 = FB_CSCR_BLS_MASK | FB_CSCR_PS(2) | FB_CSCR_AA_MASK;

  // Set the address range to 128k as the DC signal is on the address wire

  FB_CSMR0 = FLEX_ADDRESS_MASK | FB_CSMR_V_MASK;

}

void flexbus_senddata(uint16 data) {

  *((uint16 *)FLEX_BASE_ADDRESS) = data;

}

void flexbus_sendcommand(uint16 cmd) {

  *((uint16 *)FLEX_DC_ADDRESS) = cmd;

}

All the PCR registers are correctly configured as ALT5 with drive-strength enabled.

I'm at a bit of a loss for what to try next. I'm thinking that I may need some wait-states but given that the clock cycle time for the SSD1963 is 9ns, it seems unlikely to be the fix.

I'd be grateful for any suggestions.

Best regards,

K

[weblar]

It looks as though the following line of code always generates a hard fault exception.

*((uint16 *)FLEX_BASE_ADDRESS) = data;