I am using LPC1788 and have successfully written EMC code. H57V2562GTR (SDRAM 16Mx16) is interfaced with the controller. Two ICs are used in parallel to write 32Bytes (16MSB in one chip and 16LSB in other). I have tested the code and it works fine (The read and write operations).
I know that by using __attribute__((at(address))) i can define variables at specific memory address.
Will i have to initialize the EMC before defining the variables in the external memory area?
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).
Note that the function have two auto variables, i.e. variables stored on the stack. This isn't really different from the assembler startup file using push/pop to store register content on the stack.
The startup file should prepare all RAM regions so they are accessible, and make sure the stack is usable.
That __main function may zero-initialize BSS and assign initial values to DATA globals. But __main() is called in a context where the stack is already usable.
Thank you Per for highlighting that. But the original problem still remains unsolved.
Do you still only get access errors when simulating, but not when running on real hardware?
That might means that your RAM setup code is working (the real hardware is happy with it). But have you verified if the real hardware actually manages to access the external memory and store data there? Have you tried to write different values to the external memory range and then read back the different values and see if you got the same values you did write?
Next question is if you have done everything correct, to let the simulator know about the existence of RAM in that address range. The real hardware don't need to know. As long as the memory controller is configured, the processor will just try to perform external memory accesses and you either manage - or you don't manage - to store data or read back data from the external memory. The simulator, on the other hand, can scream (since the main goal is to debug code) if any access is made to an address that the simulator (note: simulator - not linker) doesn't know exists.
Have you tried to write different values to the external memory range and then read back the different values and see if you got the same values you did write? Yes, the software works well when debugging the hardware.
The simulator, on the other hand, can scream (since the main goal is to debug code) if any access is made to an address that the simulator (note: simulator - not linker) doesn't know exists. In that case, i will not push further. only that i wanted to check if the there was any way of solving this.