RTX with External SDRAM LPC1788 - causes bus fault

Hello,

Thanks for your reply.

Yes this initialization of the SDRAM works fine when RTX is not involved.

I don't do an exhaustive test of the SDRAM because I've already tested it quite a bit without RTX.

but just to satisfy myself my main does a little test as follows and always passes:

int main (void)
{
    volatile uint32_t *wr_ptr;
    uint32_t data;
    uint32_t i;

    PINSEL_ConfigPin(LED_PORT, RED_LED_PIN, 0);
    PINSEL_ConfigPin(LED_PORT, GRN_LED_PIN, 0);
    GPIO_SetDir(LED_PORT, RED_LED_PIN_MASK, GPIO_DIRECTION_OUTPUT);
    GPIO_SetDir(LED_PORT, GRN_LED_PIN_MASK, GPIO_DIRECTION_OUTPUT);


    wr_ptr = (uint32_t *)0xA0000000;
    for (i = 0; i < 0x100; i++)
    {
        *wr_ptr++ = 0x12345678;
        //*wr_ptr++ = i;
    }

    /* Verifying */
    wr_ptr = (uint32_t *)0xA0000000;
    for (i = 0; i < 0x100; i++)
    {
        data = *wr_ptr;
        //if (data != i)
        if (data != 0x12345678)
        {
            while(1);
        }
        wr_ptr++;
    }

    os_sys_init(init);                        /* Initialize RTX and start init */

    while ( 1 );
}

Any other ideas suggestions would be most appreciated.

Mac

Hello,

Thanks for your reply.

Yes this initialization of the SDRAM works fine when RTX is not involved.

I don't do an exhaustive test of the SDRAM because I've already tested it quite a bit without RTX.

but just to satisfy myself my main does a little test as follows and always passes:

int main (void)
{
    volatile uint32_t *wr_ptr;
    uint32_t data;
    uint32_t i;

    PINSEL_ConfigPin(LED_PORT, RED_LED_PIN, 0);
    PINSEL_ConfigPin(LED_PORT, GRN_LED_PIN, 0);
    GPIO_SetDir(LED_PORT, RED_LED_PIN_MASK, GPIO_DIRECTION_OUTPUT);
    GPIO_SetDir(LED_PORT, GRN_LED_PIN_MASK, GPIO_DIRECTION_OUTPUT);


    wr_ptr = (uint32_t *)0xA0000000;
    for (i = 0; i < 0x100; i++)
    {
        *wr_ptr++ = 0x12345678;
        //*wr_ptr++ = i;
    }

    /* Verifying */
    wr_ptr = (uint32_t *)0xA0000000;
    for (i = 0; i < 0x100; i++)
    {
        data = *wr_ptr;
        //if (data != i)
        if (data != 0x12345678)
        {
            while(1);
        }
        wr_ptr++;
    }

    os_sys_init(init);                        /* Initialize RTX and start init */

    while ( 1 );
}

Any other ideas suggestions would be most appreciated.

Mac

Your test is not very good.
Try this one:

www.esacademy.com/.../software-based-memory-testing.html

Hello,

Thanks. I implemented the test as shown on that web page. It passes the test but still faults as os_sys_init.

However, that lead me to try reducing the EMC speed (from 120MHz to 60MHz) and it was ok.

So yes this is a memory issue it looks like. If the test passes what else can I try to see what is going wrong as I would really like to run at 120 MHz.

Thanks

M

I should have advised you to do so earlier - interestingly enough, I posted a bootloader from a LPC2478 to a LPC1788 lately, and I have the very same problem! Had to run the EMC clock at 60MHz. I assumed then it was a routing issue, but NXP themselves gave up conflicting statements about the maximum clock speed of the chip...

Just an update.

I got it running at 96MHz and it seems alright.
I also spoke with someone at NXP and they said it should run at 120?

Maybe it is a layout issue on the EA dev board or something along these lines.

Cheers.

Mac

Ok so another update on this topic.

I contacted NXP support and they told me something different than the FAE.

Here is support's response:

"Thank you for contacting NXP Semiconductors.
The EMC in the LPC177x/8x family can run at a maximum speed of 80 MHz (see the Tcy(clk) = 12.5ns minimum in the data sheet).
You should divide the clock down using the EMCCLKSEL registers."

I guess I missed that in the datasheet.

Hope this is of use to someone else.

Regards,

M

Now it's 80 MHz?
Time to make up your minds NXP :-)

I believe this is incorrect. The data sheet (Table 15. Dynamic characteristics: Static external memory interface, page 81) is referring to a static external memory.

The tables after this (Table 16-18. Dynamic characteristics: Dynamic external memory interface, page 83 - page85) are the ones that pertain to running a SDRAM.

I believe this clock, called the EMC_CLK, is a function of the ouptut from the PLL, and the EMC_CLOCK_DIVIDER, as shown in the user's manual on page 35, Fig. 7.

According to Section 4.6.3 on page 51 of the user's manual, this clock can be the same as the CPU clock, and the CPU clock can be 120Mhz, so this clock can be also.

I personally have driven my EMC clock at 108Mhz without and problems from my EMC or the SDRAM (MT48LC2M32B2).

I did experience a problem running it at 120Mhz, but I attributed this to a poor PCB layout.

I hope this helps,

-Dave

Good observation.
I too was able to run at slightly higher rates than 80MHz but I think this is actually the "official" limit for the EMC (static and/or dynamic).
The "clock cycle time" is more directly related to dynamic memory than static so maybe this is just in the wrong spot in the datasheet?

Also, in our target product we have static mem as well so that pretty much decides that.

Thanks.

M

After reading your response, I decided to play around with the values used to program the EMC, and now I am able to get my SDRAM to work at 120Mhz.

Here are my results:

...clearing SDRAM (8388608 bytes)...............complete! (92 ms.)
...testing SDRAM 16-bit write (2097152 words)...complete! (154 ms.)
...testing SDRAM 16-bit read (2097152 words)....complete! (310 ms.), Errors: 0
...testing SDRAM 32-bit write (1048576 dwords)..complete! (87 ms.)
...testing SDRAM 32-bit read (1048576 dwords)...complete! (148 ms.), Errors: 0

You are welcome to try it for yourself. Here are the values I used:

LPC_SC->EMCCLKSEL = 0x00000000;  // EMC uses a clock rate equal to CPU clock rate...
LPC_SC->CLKOUTCFG = 0x00000100;  // enables clock, sets clock source as CPU clk / 1...
CAS_Latency = 2;
RAS_Latency = 2;
DelayConstant = 0x00000A05;
.
.
.
LPC_SC->EMCDLYCTL   = DelayConstant;

I still believe the time entry in the datasheet is specific to the table that it is listed in, namely static memory. It is referenced throughout that table in other timing parameters, but no where else in the data sheet.

I put in another tech support request to NXP for clarification on this subject, and referenced this forum thread for them...

Good luck,

Dave

Dave,

Please post any NXP response here. Thank you.

For sure, I will. I also will be posting it at this new forum I just signed up for, which is LPC specific:

www.lpcware.com/.../lpc17xx

Hopefully, as this processor becomes more popular, others can contribute there as well...

-Dave

I got a response from NXP:

David
Thank you for contacting NXP Semiconductors.
The maximum clock frequency of the EMC is 80 MHz.
In the data sheet, it specifies Tcy(clk) clock cycle time = 12.5ns min.  This equates to an 80 MHz clock.
You can divide the main clock by two by using the EMCCLKSEL register.

Regards
Paul

So naturally, I responded with this:

I received this response:
>Thank you for contacting NXP Semiconductors.
>The maximum clock frequency of the EMC is 80 MHz.
>In the data sheet, it specifies Tcy(clk) clock cycle time = 12.5ns min. This equates to an 80 MHz clock.
>You can divide the main clock by two by using the EMCCLKSEL register.
>
>Regards
>Paul

However, I disagree with these statements.
If you look closely, you see that Tcy(clk) (listed in Table 15 on page 81) refers to "Static external memory interface". The value for Tcy(clk) is uses as a basis for many other parameters within this table.

Tcy(clk) is used as a parameter for the SSP, USB, SD/MMC, etc..., and in each case is defined for that particular device/condition.
My interface is to SDRAM, which is dynamic memory, and I believe better suited to parameters listed in Table 16 on page 83. Since there is no minimum time listed in this table, I presume the maximum clock would be the maximum value for EMC_CLK, which is the CPU clock frequency.
I have tested this, and am using my SDRAM at 120Mhz without errors.

Can you please verify your answer for me.

Also, would you please address Table 19 on page 86 - here, the minimum value for Tcy(clk) is 40ns, or 25Mhz. This cannot be true.

Thank you in advance,

-Dave

I'm waiting on a response once again...

It would be helpful if someone else with with SDRAM connected to their LPC1788 could test their device at 120Mhz to verify it works correctly. You can find my initialization code for the EMC here to use as a reference:

www.lpcware.com/.../dk-57vts-lpc1788-configuring-emc-sdram

-Dave

Dave,

Thanks for the update. Yes, the data sheet conflicts itself as other NXP individuals and documents...

I agree. It's unfortunate. The last time I contacted NXP with a concern (there was an error in their latest CMSIS file system_lpc17xx.c), the response I got was the following:

Hello David
Thank you for contacting NXP Semiconductors.
I reviewed the system_LPC177x_8x.c file and it seems to be correct.
Please download the latest version and let me know if you still see the problem.
You can download the latest example code from: " tab at the bottom, and press the "Expand All" button at the top.
Notice the check boxes for the Power Control for Peripherals Register (PCONP). <Only the first one is checked>

Now, press the "Text Editor" button at the bottom, and go to line #200. Notice the PCONP value does not match the check box settings?

Now take a look at line #197, which has the following code:

#define USBCLKSEL_Val (0x00000001|(0x02<<8))

Notice the first numeric value matches the check box settings?

Return to the "Configuration Wizard", and check the first 4 boxes in the PCONP setup.
Now return to the "Text Editor" and take a look at line #197.

Notice the first numeric value has changed from 0x00000001 to 0x0000000F?

This is because of a mis-alignment in your macro settings for the Wizard.

The fix is simple, but I think Paul should take a closer look...

Best Regards,

David Brooks

David
I have reviewed the system_LPC177x_8x.c file and agree with your findings.  I changed the following starting on 188:
#define CLOCK_SETUP  1
#define SCS_Val   0x00000021
#define CLKSRCSEL_Val  0x00000001
#define PLL0_SETUP   1
#define PLL0CFG_Val  0x00000009
#define PLL1_SETUP   1
#define PLL1CFG_Val  0x00000023
#define CCLKSEL_Val  0x00000001
#define USBCLKSEL_Val  0x00000001
#define EMCCLKSEL_Val  0x00000001
#define PCLKSEL_Val  0x00000002
#define PCONP_Val  0x042887DE
#define CLKOUTCFG_Val  0x00000100




I have notified the microcontroller applications engineer and it will be fixed in the next version.
Regards
Paul

NXP sample code tends to look like it was written by students. Their code packages can potentially be used as a complement to the datasheet when figuring something out, but in most situations, the code needs to be rewritten - or not used at all.