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
Solved! Go to 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
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
Hi Kevin !
Can I ask you which driver do you use for the SSD1963?
Thanks a lot !
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
Yes but you use a driver for the SSD1963 no ?
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.
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 !
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.
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
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
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;
}
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
It looks as though the following line of code always generates a hard fault exception.
*((uint16 *)FLEX_BASE_ADDRESS) = data;