I can't find anything that coherently explains how to make the SDRAM useable. There is example code (semc_sdram) but it uses absolute memory addresses and thus is useless for typical programs where we need variables and arrays in SDRAM. And in that example the SDRAM is not accessible until BOARD_InitSEMC() is called, in main(), so static variables in SDRAM cannot be initialized to zero at startup, as C requires.
There seem to be a lot of moving parts involved:
- the pin config - is there a list of the pins we need to config and how to set them, in the Pin view?
- the Peripherals view - what settings does the SDRAM require in the big list on the SEMC page, and should the Mode be "general" or "DCD"?
- how does DCD work with regard to the SDRAM?
- even if we have the DCD setting the SDRAM correctly on boot, is it true that downloading an app with DAPlink will not configure the SDRAM correctly? If not, do we need a LinkServer script? If so, what script, and is it a Reset script or a Connect script?
- in one other response re SDRAM on RT1050 it was mentioned to define XIP_BOOT_HEADER_DCD_ENABLE=1 (and some linker script settings) but is XIP even relevant if I'm executing from RAM, not flash?
Thanks
Norm
Hi Norm Campbell
Are you using MCUXpresso IDE? you can add the SDRAM functionality as memory allocation in boot time with the DCD. The DCD allows the Boot ROM code to obtain the configuration of an external image, for example, it allows to configure the SDRAM before the execution of the reset handler.
If you are using MCUXpresso IDE you can enable the DCD of the onboard SDRAM with the MACROS:
XIP_BOOT_HEADER_DCD_ENABLE=1
SKIP_SYSCLK_INIT
The first one will enable the DCD table in the file evkmimxrt1064_sdram_ini_dcd.c. and the second one is a part of the MCU configuration that skips the disable of the SEMC module.
After this, you only have to ensure that the SDRAM memory is the first memory RAM used in your project:
Hope this information could help you, please don't hesitate to contact me if you have any other question about this.
Best regards
Jorge Alcala
Jorge,
I could definitely use some help from you.
I am simply trying to use the SDRAM on the MIMXRT1064-EVK for a place for the heap and stack. (Most likely also for .data and .bss).
I followed your instructions but I am still not able to have a fully functional board with lwip_mqtt_freertos demo app.
With default memory configuration and compiler options,
I see via debug console logs that the app is running and talking to the mqtt broker.
With the changes you described above, I only see the following in the console logs:
Initializing PHY...
************************************************
MQTT client example
************************************************
Getting IP address from DHCP...
Previously I had moved the SDRAM to be the first RAM in Memory Configuration (without the compiler option changes you described) and that resulted in Hard Fault error.
Obviously your instructions are taking me further but something still must be missing.
I ran into some information (that may be related to the issue I am seeing) in RT1060_BriefOverview_v102.pdf, which said
"Note: in SDK version 2.5.x the 32MB SDRAM region is configured so the last 2MB will not
be cachee:
MPU->RBAR = ARMmuMPUmuRBAR(8g 0c81E00000U)e;
MPU->RASR = ARMmuMPUmuRASR(0g ARMmuMPUmuAPmuFULLg 1g 0g 0g 0g 0g ARMmuMPUmuREGIONmuSIZEmu2MB)e;
If a project is created with the SDRAM as the frst RAM region then the stack will
automatically be located at the end of this region i.e. within this uncached region of
memory. Since uncached SDRAM will see hugely degraded performanceg this situation
should be avoided!"
I could not make out exactly what this means especially since I don't currently understand how MPU configuration works in terms of cached/uncached, etc.
Maybe this has nothing to do with my issue and perhaps you know what I might be missing?
As Norm Campbell brought up, it is really puzzling how this kind of information is not easily found.
I would think most applications that people develop for 1064 level of microcontrollers require use of SDRAM for SRAM is not big enough.
Regards,
James
Thanks Jorge. I do have the SDRAM working now, when running with the debugger. I'm still a bit puzzled though.
1. I'm using MCUXpresso
2. The last problem I had was that my pin setup for the DQS signal was wrong. Which leads me to ask again: which pins need to be set up in the pin configurator, and to what values? Should we just copy all the pin settings in the semc tester app?
3. I have not yet set XIP_BOOT_HEADER_DCD_ENABLE=1 and SKIP_SYSCLK_INIT, yet the SDRAM is writeable and readable as soon as the debugger (using SWD and LinkServer) loads my program and is sitting at the start of main(), before I have called any SEMC initialization code. I have no debugger Reset or Connect scripts set up. So why does the SDRAM work? What is initializing all those registers?
4. Is it true that I'll need to set up XIP_BOOT_HEADER_DCD_ENABLE=1 and SKIP_SYSCLK_INIT burn that to flash before my board will boot without the debugger connected?
Thanks
Norm
Hey Norm,
Maybe I can add to the confusion. I've been working with the RT1052, and now the RT1064 for a while.
In our application we're using the SDRAM as the main memory for both the stack and heap running at 600 MHz.
In the SDK 2.6.0 examples, like semc, in clock_config.c, in the BOARD_BootClockRUN() function I found this code:
/* Setting the VDD_SOC to 1.275V. It is necessary to config AHB to 600Mhz. */ DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0x13); /* Waiting for DCDC_STS_DC_OK bit is asserted */ while (DCDC_REG0_STS_DC_OK_MASK != (DCDC_REG0_STS_DC_OK_MASK & DCDC->REG0))
I'm assuming the comment for 1.275V is correct. I haven't found where this is documented in the reference manual yet.
Since the example operates using internal RAM for stack and heap that works fine.
Since I'm operating expecting the external SDRAM to be functional, that doesn't work for me.
From ResetISR() the first JSRs would be using non-reliable SDRAM. I verified this was happening.
The SDRAM contents around the stack had multiple locations corrupted while single stepping.
So, I needed to re-configure the DCD before our code ran.
The only thing that I could find to do that was to alter the DCD to also configure the DCDC's REG3.
I tried using the new DCD tool in MCUXpresso 11.0.1 but it limits which peripheral registers can be used.
Maybe next release it will be more flexible.
So I did it "by hand": (Note: When altering the dcd_data[], do not forget to update the image length!)
Before the SEMC configuration commands I added these commands after the version:
/* group: 'DCDC' */ /* #1, command: write_value, address: DCDC_REG3, value: 0x113, size: 4, comment: 'Setting the VDD_SOC to 1.275V. It is necessary to config AHB to 600Mhz.' */ 0xCC, 0x00, 0x0C, 0x04, 0x40, 0x08, 0x00, 0x0C, 0x00, 0x00, 0x01, 0x13, /* #2, command: check_any_bit_clear, address: DCDC_REG0, value: 0x80000000, size: 4, comment: 'Waiting for DCDC_STS_DC_OK bit is asserted' */ 0xCF, 0x00, 0x0C, 0x0C, 0x40, 0x08, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00,
With these added I increased the size to 0x04, 0x48.
I've attached my file including the new dcd_data[] definition.
I hope this helps you and maybe helps the tools get better.
Steve
PS: if anyone can point to the documentation for the 1.275V: thanks!
Hi Norm Campbell
4. Is it true that I'll need to set up XIP_BOOT_HEADER_DCD_ENABLE=1 and SKIP_SYSCLK_INIT burn that to flash before my board will boot without the debugger connected?
Yes, you can see the DCD value in the XIP folder of the project.
If you want to use the SDRAM before jumping to the reset handler, you need to initialized the SDRAM with the ROM code, and this is performed with the DCD in the image that you flash. You don't need to worrie about the pin init if you already have the SDRAM running form the ROM code.
Regards
Hello @jorge_a_vazquez , as mentioned by others in this thread, is there any documentation or any such pointers for getting SDRAM working on EVK board? I tried different approaches mentioned in this thread. But nothing seems to be working.
Any pointers on this are highly appreciated.
Regards,
Mahesh.