CORTEX M7 : SDRAM Noob Advice

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Been developing heavily with the Cortex M4 for a few years now and have jumped into the M7 over the last year. I have never had to pick an SDRAM for an application so I have a couple of statements that may needs corrected, and questions I'm hoping someone can shed some light on. 
 

- Do I need to add a memory region to the linker script (along with setting attributes for global variables I want to sit in it) for it to work properly? Or do I somehow dynamically allocate the memory in the application during run-time?
- If SDRAM Controller only operates at 1/2 clock speed (i.e. V71 300 MHz / 2 = 150 MHz), is there any advantage to getting an SDRAM with a higher maximum clock speed? The main reason I ask stems from recent work with Memory Cards. While the MMC controller couldn't come remotely close to the max r/w speeds of cards I tested, using faster grade cards cued the end of read/write far faster than their slower class brothers. I'm wondering if I might see similar phenomenon with SDRAM. 

- Forcing aligned memory use will improve performance - T/F? 

- Despite the fact that DDR is a form of SDRAM, I'm assuming I can't use DDR because that would require sampling data on both edges of the clock and the SDRAMC doesn't support that...correct?

- Any recommendations for a high capacity (2 Gbits) SDRAM that doesn't operate at 1.8V typical... I have audio converters in the application that don't support 1.8V, and I really don't want to do level translation if possible...I'd have to use 1.8V for VDDIO to work with most of the SDRAMs I have seen but that won't fly with my audio ADC/DACs... Suggestions welcome, but it looks as though I may be dreaming...

Thanks.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can only answer to your first question: In my application with a SAME70 and an external SDRAM, I haven't configured anything special. I use ASF and only enabled SDRAMC driver, configured the correct pins, and write to addresses starting from 0x70000000.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you really want a sam5 or better. If the sdram controller doesn't support ddr, no ddr for you then. The sdram controller controls the clock speed - using faster ram won't make a difference. You should be able to find sdram with vddio of 3V3 - but maybe not in the density you want.

You chose how you want to handle the memory - you would normally do it in the linker but there's nothing to say you can't have your code manage it. You can hard code a pointer or create a memory segment in the linker and use an attribute on the vars you want to place in that ram.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman, thank you for the reply

Kartman wrote:
Sounds like you really want a sam5 or better.
 

No, I definitely don't and I'm not sure how you can arrive at a conclusion like that without knowing any of the other project requirements? 

 

Kartman wrote:
not in the density you want.
 

That's exactly the issue...nothing in 3.3 above 512Mbit as far as I can find.

 

Kartman wrote:
You chose how you want to handle the memory - you would normally do it in the linker but there's nothing to say you can't have your code manage it. You can hard code a pointer or create a memory segment in the linker and use an attribute on the vars you want to place in that ram.

I normally would do it in the linker, but the example projects for SAMV use the hard coded pointer - I had never done it this way so I found it a bit strange, but I guess it works and you're also suggesting it.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tom,

 

I've got a project on my desk at the moment with a M4 with external DDR and nand flash. The chip we're using (Kinetis K61) supports DDR and 1V8 interface and we're using a 1Gbit chip.  Then there's the cost issue - you pay for the on chip flash of your M7 whereas some of the Cortex A series are cheaper, higher performance, talk to DDR and so on. So we're at a nexus point. So my suggestion of a SAMA5 was only a suggestion, not a demand and ,yes, I don't know your other requirements. I can only assume you want a decent amount of cpu grunt - thus the choice of M7 and you want a big slab of ram.

The decision of addressing the sdram depends on what you're storing in the sdram - if you only want it for a big buffer and nothing else, then hard code a pointer otherwise, if you want the compiler to manage the allocation of ram then create a segment in the link file. The 'portable' solution would be to create a segment in the link file and that way if you compile the code on another platform, you can #define the segment either disappear or appear somewhere else. For example, I tend to test my code on a PC, so I have it compilable for both the PC and the target plaform. Having a hard-coded pointer would not work in this instance unless I did other shenanigans.