TM4C129XNCZAD: SDRAM compatibility: ESMT vs Alliance

Hi Marco,
Did your board change with Alliance memory chip in any way that affects the capacitance on the traces compared to before?

May I note that your "Good Image" reveals less color saturation for both the green and orange colors. (finding 1)

Your attempt at providing an, "A-B" comparison of images is sub-optimal as the new image fields are "wider" than the old ones.    (90mm vs. 84mm on my monitor - that's > 6% - makes the new image appear bolder!)   (finding 2)   

Note too - there is a clear "regularity" displayed by the slight, blue, vertical bars (new image) - such regularity argues against the finding of "noise."   (may suggest an "address routing issue.")   (finding 3)

Review of both specs - as you request - can be greatly assisted by   your (first) pre-viewing - and "Highlighting" the differences.      Forcing such high effort upon your remote "helpers" seems outside your best interest.       (i.e. although I've long been successful w/in the display field - I've no taste to perform that "pre-work" for you  -  that's "common courtesy" - is it not?)

And - as always - no indication is provided as to the number of such "new boards" which reveal this issue.       Single board anomalies hold NO interest (bad solder joint, wrong component etc.) - multi-board issues prove far more interesting, compelling, impacting - thus warrant (much higher) effort & attention...   (especially so when "such issue" strays FAR from the forum's MCU focus - as this (clearly) does!)

Hi cb1.

I'll try to reply to your consideration point by point so I cannot make mistake.

1."May I note that your ...": You should consider that the pictures were taken with a camera and different light sources. So the issue is not saturation. 

2. "your attempt at providing...":  the dimensions of the pictures are not the main concept that I want to show you, but my focus is on vertical lines.

3. "note too - there is a clear...": this suggestion is quite good, but I've already done a check for addressing issue and I didn't find it.

4. "Review of both specs...": It's strange that someone who worked a lot on the display field could not find the information in the tables I sent. This is not "common courtesy", but it's just a matter of knowing whether or not to find information in the tables above.

5. "And as Always - no indication...": I've already filtered this kind of information. We have done a pre series with 'n' boards and all of them suffer of this kind of issue. No other issue like bad soldering, wrong compoment, etc..

Since this is not the first time that you use such a rude approach to my post, I ask you to refrain from answering any more, as I think your considerations are of little interest.

Regards,

Marco Crivellari

Hi Marco,

  I don't know which version of each memory device you have. I try to compare the widest extreme between the two. The Alliance -7 is somehow slower than ESMT -5. Can you still modify your firmware? Can you play (i.e. adjust timing) with these timing parameters in the EPI to see if it makes a difference? 

Marco Crivellari said:

"And as Always - no indication...": I've already filtered this kind of information.

Yet - you failed to provide such information - did you not?        Presenting your "checks & findings" saves the time/effort of your "helpers" - who (predictably) may "duplicate your efforts" - when such efforts are "unmentioned & withheld!"

Your judge of  "rudeness"  is not shared (rudeness does not result from simple, "statement of fact.")      Images - when presented to others for comparison & analysis - should be as "consistent as possible!"    (thus camera angle, settings, focal length should strive for consistency - did yours?)      

Your  "expectation" that (others) would "comb thru your (voluminous) Non-MCU device data" - suggests "less than full" care/concern for your  "MCU-based, forum helpers."    You had (most likely) "already done such" - thus would have been easy for you to "highlight those areas of difference" - saving that unwanted effort (forced) upon your "would be" helpers...

Surely you must realize that, "Speeding & Easing the efforts of others - operating entirely "in your behalf" - makes great sense.     (likely enhances those efforts - which of course - was my objective...)

Despite your attitude - my hope is that you do (finally) succeed.       Read w/a more "open, accepting  and less hostile mindset"  - those guidelines clearly, "intend to and can aid/assist."     (such is FAR from rude...)

Hi Charles.

1. the PCB layout is the same.

2. Work in progress...

3. I'm going to replace the Alliance  with ISSI as soon as the samples will arrive

4.I'm going to repllace Alliance device with ESMT in the board, but this will take a little time

I'll let you know.

Regards,

Marco

Hi.

Just a simple update for this post.

All PCB constains and signals integrity are ok.

The SDRAM is configured as:
 - EPIModeSet(EPI0_BASE, EPI_MODE_SDRAM);
 - EPIDividerSet(EPI0_BASE, 1);
 - EPIConfigSDRAMSet( EPI0_BASE, (EPI_SDRAM_CORE_FREQ_50_100 | EPI_SDRAM_FULL_POWER | EPI_SDRAM_SIZE_64MBIT), 900 );
 - EPIAddressMapSet(EPI0_BASE, EPI_ADDR_CODE_SIZE_16MB | EPI_ADDR_CODE_BASE_1 );
and it's correct for both ESMT and Alliance, i.e. the unit test runs with no error for both (see unit test code at the bottom):

In order to get good picture again, we modified the pixel clock divisor for the LCD Controller:
old --> LCDModeSet(LCD0_BASE, LCD_MODE_RASTER | LCD_MODE_AUTO_UFLOW_RESTART, (120000000/4), 120000000UL);
new --> LCDModeSet(LCD0_BASE, LCD_MODE_RASTER | LCD_MODE_AUTO_UFLOW_RESTART, (120000000/6), 120000000UL);

There's only one side effect in doing this adjustment: the unit test on SDRAM is about 1.3 times slower than before.

Regards,
Marco

-----------------------------------------------------------------------
UNIT TEST FOR SDRAM @ 0x10000000
-----------------------------------------------------------------------

        HAL_MEM_DATA_PATTERN                (0x55AA55AA)
        nLocation = SDRAM_NUM_BYTES / 4;
        divisor = 4;
        buffer.word = HAL_MEM_DATA_PATTERN;       

        timetick = OS_GetTimerTick();

        // ------------------------------------------------
        // WRITING...
       
        g_puiEPISdram32 = (uint32_t *)SDRAM_BASE_ADDRESS;
        g_puiEPISdram16 = (uint16_t *)SDRAM_BASE_ADDRESS;
        g_puiEPISdram8  = (uint8_t *)SDRAM_BASE_ADDRESS;

        for( i=0; i<nLocation; i++ )
        {
            switch(divisor)
            {
            case 1:
                // write 4 word 8 bit
                EPIWorkaroundByteWrite( g_puiEPISdram8, buffer.byte.b1 ); g_puiEPISdram8++;
                EPIWorkaroundByteWrite( g_puiEPISdram8, buffer.byte.b2 ); g_puiEPISdram8++;
                EPIWorkaroundByteWrite( g_puiEPISdram8, buffer.byte.b3 ); g_puiEPISdram8++;
                EPIWorkaroundByteWrite( g_puiEPISdram8, buffer.byte.b4 ); g_puiEPISdram8++;
                break;

            case 2:
                // write 2 word 16 bit
                EPIWorkaroundHWordWrite( g_puiEPISdram16, buffer.halfword.low  ); g_puiEPISdram16++;
                EPIWorkaroundHWordWrite( g_puiEPISdram16, buffer.halfword.high ); g_puiEPISdram16++;
                break;

            case 4:
                // write 1 word 32bit
                EPIWorkaroundWordWrite( g_puiEPISdram32, buffer.word ); g_puiEPISdram32++;
                break;

            default:
                break;
            }
        }

        // ---------------------------------------------------
        // READING...
       
        g_puiEPISdram32 = (uint32_t *)SDRAM_BASE_ADDRESS;
        g_puiEPISdram16 = (uint16_t *)SDRAM_BASE_ADDRESS;
        g_puiEPISdram8  = (uint8_t *)SDRAM_BASE_ADDRESS;

        for( i=0; i<nLocation; i++ )
        {
            buffer.word = 0;

            switch( divisor )
            {
            case 1:
                // read 4 word 8 bit
                buffer.byte.b1 = EPIWorkaroundByteRead( g_puiEPISdram8 ); g_puiEPISdram8++;
                buffer.byte.b2 = EPIWorkaroundByteRead( g_puiEPISdram8 ); g_puiEPISdram8++;
                buffer.byte.b3 = EPIWorkaroundByteRead( g_puiEPISdram8 ); g_puiEPISdram8++;
                buffer.byte.b4 = EPIWorkaroundByteRead( g_puiEPISdram8 ); g_puiEPISdram8++;
                break;
            case 2:
                // read 2 word 16 bit
                buffer.halfword.low  = EPIWorkaroundHWordRead( g_puiEPISdram16 ); g_puiEPISdram16++;
                buffer.halfword.high = EPIWorkaroundHWordRead( g_puiEPISdram16 ); g_puiEPISdram16++;
                break;
            case 4:
                // read 1 word 32 bit
                buffer.word = EPIWorkaroundWordRead( g_puiEPISdram32 ); g_puiEPISdram32++;
                break;
            default:
                break;
            }

            if( buffer.word != HAL_MEM_DATA_PATTERN )
            {
                aCnt++;
                printf( "0x%08X @ 0x%08X \n", buffer.word, SDRAM_BASE_ADDRESS + (i*divisor) );
            }
        }

        timetick = OS_GetTimerTick() - timetick;

       printf( "\n time: %d [ticks]\n", timetick );

If I may - the pixel clock has been reduced from 30MHz to 20MHz via your SW change.

• is that pixel clock w/in the spec of the display?
• is any "flicker" noted?
• is the depth of any of the primary colors impacted?

Lowering the pixel clock - if (not) impacting any of the above - usually produces a more robust (forgiving) interface & lessens current-draw.

Experience teaches that it would be wise for you to test these changes upon several displays - especially those w/most recent "date codes."

Are you satisfied w/your current results?    (I - possibly others - cannot tell from this posting)