none
Windows CE 6.0 - memcpy and LCD flickering while loading new image or copying data to flash/SDRAM RRS feed

  • Question

  • Hi, I'm working on i.Mx27 based platform, with Windows CE 6.0.

    Problem:

    When Windows CE desktop loads at boot time, LCD flickers and then stabilizes.

    When a GUI image is loaded, the LCD flickers. Close the GUI image and relaunch it. The LCD does not flicker.Note: All GUI images are stored in NOR flash.

    Now load a different GUI image. The LCD flickers. Close this second GUI image and relaunch it. The LCD does not flicker.

    Copy few files from pen drive to NOR flash. The LCD flickers as long as copy operation is done.

    Solution tried out:

    The LCD flickering disappeared when in the NOR flash driver, all memcpy () functions were replaced with custom iw_memcpy () function, which is:

    void iw_memcpy(void *to,const void *from, int len)
    {
      int index;
      for (index = 0; index < len; index ++)
      {
        *((unsigned char *) to + index) = *((unsigned char *) from + index);
      }
    }.

    Basically, even the memcpy in standard library would do the same byte to byte transfer and not block...right? How does this solve the flickering problem?

     

    Is this the exact cause of the problem and can I state it as a solution? Or something else could be the culprit? Like DMA or bus arbitration, etc.

    Please Note following additional observations:

    If a number of files are copied from wince desktop (RAM) to any subfolder (on RAM), flickering does not happen.

    Flickering happens when files are copied 1) from NOR to RAM 2) NOR to NOR 3) External USB driver to NOR 4) NOR to external USB.

    Regards,

    Neil

     

     

     

     


    Thursday, August 25, 2011 7:40 AM

All replies

  • The way you describe it, It sure sounds like it could be some sort of starvation or arbitration problem. Can't say I have encountered LCD flicker on a imx27 caused by NOR access, but I guess it is not impossible to achieve if you have a huge LCD (fast clock) and/or really slow RAM settings. Is it just the NOR flash code that causes the flicker or can you cause the LCD to flicker if you just copy larger chunks of data in RAM with memcpy?

    Regarding a memcopy there's a lot going on behind the scenes with cache lines and such that may or may not result in burst writes/reads and how big those bursts are.

     


    Henrik Viklund Windws Embedded MVP http://www.addlogic.se
    Thursday, August 25, 2011 9:13 AM
  • The way you describe it, It sure sounds like it could be some sort of starvation or arbitration problem. Can't say I have encountered LCD flicker on a imx27 caused by NOR access, but I guess it is not impossible to achieve if you have a huge LCD (fast clock) and/or really slow RAM settings. Is it just the NOR flash code that causes the flicker or can you cause the LCD to flicker if you just copy larger chunks of data in RAM with memcpy?

    Regarding a memcopy there's a lot going on behind the scenes with cache lines and such that may or may not result in burst writes/reads and how big those bursts are.

     


    Henrik Viklund Windws Embedded MVP http://www.addlogic.se

    Hi Henrik,

    The LCD size is huge. It is 800 x 600 pixels, 16 bpp. All flickers involve NOR flash except in one case: When WinCE boots up, the desktop image flickers in the beginning and then stabilizes. I think I need to check the RAM settings. May be I need to configure it to work faster??? The memcpy change was done only in NOR flash device driver.

    Regards,

    Neil
    Thursday, August 25, 2011 12:30 PM
  • bump
    Friday, August 26, 2011 5:26 AM
  • I'd make a little test app that do decent chunk memcpys (to ensure the cachelines are flushed to RAM) in a high-priority thread just to make sure it is the RAM memory arbitration that starves the display DMA, and not some subtle NOR flash interface problems.

     


    Henrik Viklund | Windows Embedded MVP | http://www.addlogic.se
    Friday, August 26, 2011 6:36 AM
  • I'd make a little test app that do decent chunk memcpys (to ensure the cachelines are flushed to RAM) in a high-priority thread just to make sure it is the RAM memory arbitration that starves the display DMA, and not some subtle NOR flash interface problems.

     


    Henrik Viklund | Windows Embedded MVP | http://www.addlogic.se


    Hi Henrik,

    I wrote a small test application to copy 2 KB of data from source buffer to destination buffer on RAM. I executed it continuously for 1000 times and there wasn't any flickering observed on the display. I set the priority of the thread to 50. Here's the sample code:

    #define SIZE (1024*1024*2) /* 2 KB */

    DWORD WINAPI lpStartAddr (LPVOID param)

    {

     

    int *src;

     

    int *dest;

     src = (

    int*) malloc (sizeof (int ) * SIZE);

    dest = (

    int*) malloc (sizeof (int ) * SIZE);

     

    if(NULL == src || NULL == dest)

    {

    printf (

    "\r\n Failed to allocate memory" );

    }

    printf (

    "\r\n Copying using memcpy " );

     f

    {

    memcpy (dest, src, SIZE);

    printf (

    "\r\n %d" , index);
    or (int index = 0; index < 1000; index++)

    }

    printf (

    "\r\n Copied using memcpy" );

     

     return

    0;

    }

    I would also like to tell you that the Access time of the RAM is fixed to 6.0 ns (133 MHz). This is the maximum allowed by the processor even though the mounted RAM chip allows the followings:

    208 MHz (4.8ns), 185 MHz (5.0ns), 166MHz (5.5ns) and 133 MHz (6.0ns).

    Regards,

    Neil

     


    Friday, August 26, 2011 12:52 PM
  • Anyone for any suggestions?
    Monday, August 29, 2011 9:16 AM
  • If my memory serves me right, the imx27 has 16kB L1 I- and D-cache so a single run of 2kB memcpy is most likely to little to make a noticable effect. You need to really stress the memory bus to check if that is the problem.

    You could try to use VirtualAlloc to allocate two substantial chunks of memory (say a MB or so) and then copy one over the other repeatedly, memfill one of them etc. Also do the tests with both cached and uncached memory buffers and see if there is any difference (my theory is that cached memory should cause a higher degree of burst reads and burst writes to the RAM).

    If you still see no interference, I'd look into the NOR memory interface settings, if the interference only occur when you're messing with NOR adresses, if it is when you copy from NOR to RAM etc.


    Henrik Viklund | Windows Embedded MVP | http://www.addlogic.se
    Monday, August 29, 2011 11:58 AM