Using EMC on LPC1788

Will i have to initialize the EMC before defining the variables in the external memory area?

That question really makes no sense, because there is no such quality as "before defining the variables" --- at least none that initializing the EMC could possibly, ever have. You define variable before you run the compiler, but you only initialize the EMC at run time, which is forcibly later.

What you have to do is initialize your memory subsystem to a workable state before your code accesses those variables in any way --- and because the first such access is likely the initialization performed by the startup code, that tends to mean you have to do that inside the startup code. The alternative is to mark those variables as "not to be initialized by start-up code" and delay the initial write until you're done initializing the memory subsystem.

Add the regions in your target dialog, or scatter file. Then you can specify the segment rather than having to explicitly manage the address space, ie let the linker do it's job.

Add code in your startup.s file to initialize your external memory prior to calling __main, which is Keil's routine to copy/clear the static areas prior to calling your main() function.

Thanks Westonsupermare Pier for answering. I will investigate and post my results.

Thanks Westonsupermare Pier for answering. I will investigate and post my results.
Not my comment. some one has been using my name.

Add code in your startup.s file to initialize your external memory prior to calling __main, which is Keil's routine to copy/clear the static areas prior to calling your main() function.
I was doubtful about the technique. but now that doubt is cleared, will go with it.
But do i still have to use __attribute__? if no, then what is the other way around to let the compile know that 0xA0000000-0xAFFFFFFF memory area is available for allocation?

under debug menu, using "Using Function editor(open ini file)" option, i opened "External Ram.ini" file and compiled it. On compiling, i get "compilation complete, no compilation errors"

But the command window still displays

*** error 129: MapMem - map size truncated to 128MB

While debugging using JTag, i sometimes get this message when trying to stop the execution (especially in loops)
"Could not stop Cortex M Device!..."

I searched for the the error and came across threads where "increasing the jtag speed to 1MHz" was the suggestion. My jtag already runs at 1MHz. and the controller (LPC1788) runs at 120MHz.

Anyone any idea regarding this. Didnt get any reply for last 3 post.

Guys....has no one ever came across any such errors?
Andrew Neil, Per Westermark, Tamir Michael, Hans-Bernhard Broeker, Westonsupermare Pier

I solved this by unchecking the "default check box off-chip RAM1" in the "options for target->Read/write memory areas".

I added the ini file from the "options for target -> debug -> initialization file".
but i get the following error in the command window

BS \\edt_tx\../source/main.c\103
WS 1, 'i
WS 1, 'i
*** error 65: access violation at 0xFFFFFFF4 : no 'write' permission

kindly help me figure out whats wrong?

> I solved this by unchecking the "default check box off-chip RAM1"

If this is the case, I believe/guess I know the reason.

Do a simple test:

1. Check the "[default] off-chip RAM1".
2. Build all.
3. Read the generated map file, see what is been allocated in External SDRAM.
3a. I believe it would be the STACK that is allocated in External SDRAM.

4. Uncheck the "[default] off-chip RAM1".
5. Build all.
6. Read the generated map file, compare both map files to see what is the difference.

When you check the "[default] off-chip RAM1", the tool-chain would use off-chip RAM1 as the "[default] on-chip IRAM1".

Dear John,
you are absolutely correct. When i uncheck the box and generate the map file, i observed that all the variables base address start from 0x1000xxxx which is on-chip ram for lpc1788. and if i check the box, then the base address start from 0xA000xxxx which is SDRAM address.

But i get the following error in the command window when debugging in simulator.

*** error 35: undefined line number
WS 1, 'i
*** error 65: access violation at 0xA0064000 : no 'read' permission

when the code executes this specific line:
        Dummy = *((volatile uint32_t *)(SDRAM_BASE_ADDR | (0x32<<13)));

#define SDRAM_BASE_ADDR         0xA0000000

Why do i get access violation when i am declaring to the linker that there exist memory in the range 0xa0000000 - 0xafffffff?

the error comes when i uncheck the box.

Also, i add my customized lib file to the project. do i have to enable the same settings in the project that generates library file also?

The same error comes even if i check the box.

Not sure how you configure your project, but the basic/important concept is:

> Why do i get access violation

Author: Hans-Bernhard Broeker
Posted: 24-Apr-2013 20:24 GMT

What you have to do is initialize your memory subsystem to a workable state before your code accesses those variables [ in any way ] --- and because the first such access is likely the initialization performed by the startup code, that tends to mean you have to do that inside the startup code. The alternative is to mark those variables as "not to be initialized by start-up code" and delay the initial write until you're done initializing the memory subsystem.

Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  SystemInit
                IMPORT  SDRAM_H57V2562GTR_Init
                IMPORT  __main
                LDR     R0, =SystemInit
                BLX     R0
                LDR     R0, =SDRAM_H57V2562GTR_Init
                BLX     R0
                LDR     R0, =__main
                BX      R0
                ENDP

The =SDRAM_H57v2562GTR_Init code calls the function where i have initialized the Hynix SDRAM. The RAM code is same as the example code (except that some timings are modified as per datasheet of the IC).

Also, the line, on execution of which the error is reported in the command window is in the SDRAM_H57V2562GTR_Init function.

on execution of following line

  Dummy = *((volatile uint32_t *)(SDRAM_BASE_ADDR | (0x32<<13)));

void SDRAM_H57V2562GTR_Init( void )
{
        volatile uint32_t i;            //Does this cause a problem??
        volatile unsigned long Dummy;

        ...
}

The SDRAM initialization function defines 2 variables. Think this is not allowed before calling _main from the start-up (which initializes the RAM memory).