STM32 & Epson S1D13A05

[andya]

Posted on April 22, 2009 at 08:42

STM32 & Epson S1D13A05

[sjo]

Posted on May 17, 2011 at 13:07

Hi,

We have connected the stm32 to both the SSD1906 and SSD1961.

Solomon pretty much share similar connections as epson - the Generic 2 should work fine.

FSMC_NBL0 - A0

FSMC_NBL1 - WE1

FSMC_A0 - A1

FSMC_A1 - A2

... for rest of addresses

FSMC_A17 - M/R

FSMC_OE - RD

FSMC_WE - WE0

FSMC_NWAIT - WAIT

BS, RD/WR - pullup

using 16bit data mode.

We do sell prebuilt tft adapter boards for str9/stm32 and adapters for a variety of tft panels (Sharp/Hitachi) - www.anglia-displays.com

Hope this helps.

Cheers

sjo

[andya]

Posted on May 17, 2011 at 13:07

Hi All,

I am trying to interface an Epson LCD controller (S1D13A05) to an STM32 via the FSMC. However from looking at the datasheets for the two devices, I cannot see that the two are in fact compatible. I am surprised if this is the case and so I am assuming I am missing something.

Has anyone out there either 1) achevied the interfacing I am after or 2) arrived at the same conclusion.

I am also interested in hearing from anyone who has interfaced an STM32 to an off-chip LCD controller (not a Chip-On-Glass controler)

TIA

Andy

[sjo]

Posted on May 17, 2011 at 13:07

Hi,

we are not using burst mode, the fsmc config is as follows:

/* fsmc setup */

p.FSMC_AddressSetupTime = 2;

p.FSMC_AddressHoldTime = 0;

p.FSMC_DataSetupTime = 40;

p.FSMC_BusTurnAroundDuration = 0;

p.FSMC_CLKDivision = 0;

p.FSMC_DataLatency = 0;

p.FSMC_AccessMode = FSMC_AccessMode_A;

/* Color LCD configuration --

LCD configured as follow:

- Data/Address MUX = Disable

- Memory Type = SRAM

- Data Width = 16bit

- Write Operation = Enable

- Extended Mode = Enable

- Asynchronous Wait = Disable */

FSMC_NORSRAMInitStructure.FSMC_Bank = FSMC_Bank1_NORSRAM4;

FSMC_NORSRAMInitStructure.FSMC_DataAddressMux = SMC_DataAddressMux_Disable;

FSMC_NORSRAMInitStructure.FSMC_MemoryType = FSMC_MemoryType_SRAM;

FSMC_NORSRAMInitStructure.FSMC_MemoryDataWidth = FSMC_MemoryDataWidth_16b;

FSMC_NORSRAMInitStructure.FSMC_BurstAccessMode = FSMC_BurstAccessMode_Disable;

FSMC_NORSRAMInitStructure.FSMC_WaitSignalPolarity = FSMC_WaitSignalPolarity_Low;

FSMC_NORSRAMInitStructure.FSMC_WrapMode = FSMC_WrapMode_Disable;

FSMC_NORSRAMInitStructure.FSMC_WaitSignalActive = FSMC_WaitSignalActive_DuringWaitState;

FSMC_NORSRAMInitStructure.FSMC_WriteOperation = FSMC_WriteOperation_Enable;

FSMC_NORSRAMInitStructure.FSMC_WaitSignal = FSMC_WaitSignal_Enable;

FSMC_NORSRAMInitStructure.FSMC_ExtendedMode = FSMC_ExtendedMode_Enable;

FSMC_NORSRAMInitStructure.FSMC_WriteBurst = FSMC_WriteBurst_Disable;

FSMC_NORSRAMInitStructure.FSMC_ReadWriteTimingStruct = &p;

FSMC_NORSRAMInitStructure.FSMC_WriteTimingStruct = &p;

and the ssd1906 config is:

/* using ssd Generic #2 interface */

/* CLKI: 25MHz BCLK: 25MHz MCLK: 25MHz PCLK: 6.25MHz */

/* PCLKI uses CLKI/4 */

/* MCLK >= PCLK * 2 (16bit/pixel) */

for the clock we use an external 25MHz, but you could easily use the MCO from the stm32.

Yes things are good in the uk - starting to warm up now.

If you need any more help then use the contact email from the above website.

Cheers

sjo

[ This message was edited by: sjo on 24-03-2009 11:00 ]

[andya]

Posted on May 17, 2011 at 13:07

Hi,

Thanks for that - it is encouraging that you got something similar working. If you could give us a bit of detail about how you had the

STM32 FSMC configured that would help a lot.

Presumably you used the synchronous burst mode of the NOR/PSRAM controller on the FSMC as our understanding of the STM32F10xxx Reference Manual is that the wait signal is only available for burst mode (section

18.5.6 ''NOR/PSRAM controller registers''). Is this correct?

If using burst mode - how do you ensure that the burst length is 1? (Or is this guaranteed if you are always doing 16 bit reads and writes via the AHB)?

Do you have the FSMC_CLK signal connected to the CLKI pin of the SSD1906? (We weren't sure if the FSMC_CLK signal was issued the entire time or just during the burst transfer. Because of this we were considering piping the STM32 clock signal out to the LCD Controller CLKI input via the STM32 MCO output, but were worried that this might introduce some phase shift on the clock relative to the HCLK used by the FSMC).

Incientally, I have taken a look at your website (mentioned by you above) snd there are some other bits'n'pieces I am interested in so we can take this off-line if you prefer.

Regards

Andy

PS - How are things going in the UK? (I am originally from Dorset).

[andya]

Posted on May 17, 2011 at 13:07

Hi,

Thanks for that - it is encouraging that you got something similar working. If you could give us a bit of detail about how you had the

STM32 FSMC configured that would help a lot.

Presumably you used the synchronous burst mode of the NOR/PSRAM controller on the FSMC as our understanding of the STM32F10xxx Reference Manual is that the wait signal is only available for burst mode (section

18.5.6 ''NOR/PSRAM controller registers''). Is this correct?

If using burst mode - how do you ensure that the burst length is 1? (Or is this guaranteed if you are always doing 16 bit reads and writes via the AHB)?

Do you have the FSMC_CLK signal connected to the CLKI pin of the SSD1906? (We weren't sure if the FSMC_CLK signal was issued the entire time or just during the burst transfer. Because of this we were considering piping the STM32 clock signal out to the LCD Controller CLKI input via the STM32 MCO output, but were worried that this might introduce some phase shift on the clock relative to the HCLK used by the FSMC).

Incientally, I have taken a look at your website (mentioned by you above) snd there are some other bits'n'pieces I am interested in so we can take this off-line if you prefer.

Regards

Andy

PS - How are things going in the UK? (I am originally from Dorset).

[andya]

Posted on May 17, 2011 at 13:07

Hi Sjo,

I have tried to contact you via the anglie-display website. Did you ever get the email?

Cheers

Andy

[andya]

Posted on May 17, 2011 at 13:07

Hi sjo,

Thanks for the info. Will look into this ASAP and if I need any more help will get back to you via the website 'contact' link.

Thanks for your help.

Andy

[sjo]

Posted on May 17, 2011 at 13:07

It is hard to say, if you connect as per the above message and use the same config then it should work ok.

we use 8bit access to the ssd registers with no problems - sorry i cannot be of more help.

currently we are connecting the new SSD1963 to the stm32, boards due this very soon.

Cheers

Spen

[stefanobettega]

Posted on May 17, 2011 at 13:07

Hi sjo,

we're trying to interface a STM32F103Z to a SSD1906, but we have a problem when reading a register using byte access: even if the code contains a LDRB instruction, both NBL0 and NBL1 lines remain to low level, and so I think the access is performed with a word access. In write mode NBL0 and NBL1 are one the complement of the other one, and so the acccess is performed in byte mode. We used your code snippet to initialize the µc, and we're using the new CMSIS-compatible v3.0 library. Is there any special initialization that must be done with the µc to make things working properly?

Another thing: our code now looks like this:

#define RegisterBase 0x6C000000

int main()

{

vu8 test = 0;

InitClock();

InitGPIO();

for(;;)

{

SET_TP_ON;

test = *(vu8*)(RegisterBase);

*(vu8*)(RegisterBase + 1) = test;

SET_TP_OFF;

}

}

SET_TPxx uses bit banding to turn on or off a debug GPIO line, used to trigger access. Well, when we run the demo, the chip enable line of SSD1906 is active BEFORE the debug GPIO line is turned on, and it happens during the write access. If we remove the write access and insert another read access, CS line works exactly as expected.

So, do you have any suggestion? Do you have any sample code you can send us?

Thanks in advance

Stefano

[ This message was edited by: Ste76 on 22-04-2009 11:28 ]

[sjo]

Posted on May 17, 2011 at 13:07

Sorry been training the last few days - catching up with emails as i speak !!

Cheers

sjo