cancel
Showing results for 
Search instead for 
Did you mean: 

SSD1963 and DMA with FMC

davide
Associate II
Posted on May 10, 2015 at 01:14

The original post was too long to process during our migration. Please click on the attachment to read the original post.
14 REPLIES 14
davide
Associate II
Posted on May 15, 2015 at 17:26

I totally agree, the problem are for sure not so perfect timings of the command (WR,CS,DC) and data line. 

Maybe you already done it but you can try to rise the PLL of the SSD, right now I am using:

    //SOFTWARE RESET

    mySSD_Write_cmd(0x01); 

delay_ms

(5);

    

//EXIT SLEEP

    mySSD_Write_cmd(0x11); 

delay_ms

(5);

    

//WHITE SCREEN

    mySSD_Write_cmd(0x28);    

delay_ms

(5);

//SET THE INTERNAL PLL NM

    mySSD_Write_cmd(0xE2); 

delay_ms

(5);

//As the MPU runs FMC at 84Mhz

   

    mySSD_Write_data(47); 

delay_ms

(5);

//Set Multiplier to 47

    mySSD_Write_data(0); 

delay_ms

(5);

//Set Divider to 1

    mySSD_Write_data(0x0004);

delay_ms

(5);

//

Set 10Mhz*48/1=480Mhz PLL clock

//ENABLE PLL

mySSD_Write_cmd(0xE0); 

delay_ms

(5);

mySSD_Write_data(0x0001); 

delay_ms

(5);

//Reference clock , Enable PLL

mySSD_Write_cmd(0xE0); 

delay_ms

(5);

mySSD_Write_data(0x0003); 

delay_ms

(5);

//PLL clock , Enable PLL

    

//SOFTWARE RESET

    mySSD_Write_cmd(0x0001);

delay_ms

(5);

//Wait a stable condition

You also have to /4 all the LCD refresh timings... but maybe I misunderstood the manual of the SSD.

With this configuration I'm able to run a frame buffer in external SDRAM ( 64Mbits of the discovery kit) with really good performance, given the fact that i run at standard 168Mhz, pll-p = 2, AHB/1, AHB1/4, AHB2/2   -->  FMC Extended mode, Data-Setup-time=3 (other at zero). This gave me 34ms refresh time on 800x480 (only if i use DMA).

1HCLK should be fine, 8080 timing from p79 of ssd data-sheet show a 1ns Address-set-up at 9ns PLL clock period (111Mhz). Maybe things gets a little bit tricky with the Address-hold, data hold at the end.. unfortunately neither my future logic analyser will be able to detect such small amount of time and show me whats really happening at full speed... i'm still a student and sadly i cannot afford a real good one.

davide
Associate II
Posted on May 21, 2015 at 18:47

Hi everyone,

Thank you all... Even if the problem wasn't solved i'm glad that we have tried.

In order to continue my project i've bypassed the ssd1963 and now i'm driving the lcd in DPI interface using the embedded LTDC controller + DMA2D... I't faster than a bolt and i don't have any problem of data corruption/illegal pixels.

This is my honest advice to everyone's trying to work with ssd1963:

Buy a common 40pin tft adapter, desolder the one of your stm32f429 disco kit and go straight with it!!

Plus you can keep the good money of the ssd board or spend them to add more features to your project.

I know now that it's a real shame not to work with the embedded ltdc driver!

If anyone want the working init code just ask.

Thank you again

Davide Raggini

davide
Associate II
Posted on May 21, 2015 at 18:48

jpeacock
Associate III
Posted on May 22, 2015 at 19:10

Out of curiosity did you check the cycle time (not access time) on the SSD specs for worst case?  Some of these LCD controllers don't like back to back accesses too close together.  Manual access would give you longer cycle times compared to DMA.

Bus access timing for read but especially write should be based on worst case cycle time not average access time.

  Jack Peacock

jj2
Associate II
Posted on May 23, 2015 at 06:04

Jack: ''LCD controllers don't like back to back accesses too close together.''

Fully agree - however such cannot explain why only (some) data color ranges are impacted - and all others pass w/out issue!

I'd expect far more ''broken'' pixels - display ''disorder'' - should ''back to back'' access violations be, ''in play.''