Is it possible to add RAM?

Is there any way to add additional RAM memory to something like the Cerberus. Can you link to something external?

You can but with all the work involved, just get a hydra/spider and your benefit will be much higher.

I’d ask, for what purpose? If it’s storing data, would an SD card or the Flash module be suitable? If it’s for graphics, listen to Gus and upsize your device.

It’s for a custom board. The company I work for has been using STM32F4s running native code for a while now. Our current prototype is based on netmf and the Disco. My experience is based on your Panda and Cerberus, Cerb40 and Cerbuino Bee. Using this chip is important for backwards compatibility. We have 64MB SPI flash on our board and I’ve got that working just fine now.

I want the memory to cache a bunch of bits (fonts, icons, etc). I’m going to use flash for now (and for backwards compatibility) but I’d like to know what my options are.

…How exactly would I go about adding RAM?

Now I’m using flash to cache my screens. I’m building a portable scientific instrument, most the screens never change. For those areas of my app I’ll disable screen caching, but I’ll probably cache words (rendering fonts is so slow) and some other graphics.

My screen is a daylight visible monochrome 400x240 display (LS027B4DH01). Exactly 12,000 bytes per screen. Using my SPI flash (S25FL512S) at 30Mhz it takes around 125ms to load one screen worth of data into memory. About 950ms to write one screen worth of data. The write time is slow, but that’s fast enough for me.

Along the way I ended up improving the Flash library a bit. It now supports reading and writing in chunks (so if you’re running low on memory you can still read/write large files).

But I’d still like to know how you link to external RAM. My problem with using flash for caching (aside from the slow write time) is that it’s got a short shelf life. 100,000 writes per sector seems like a lot, but it really isn’t.

Well the first place you start is STM’s app note pool and look at how to interface external RAM. You can see how the Hydra does it (using Atmel processor) by looking at the open source eagle schematic and the netmf port, to see how the code interfaces with the hardware.

I also interested! I want to create a custom board with 1 or 2 megabytes o RAM so that I can perform RAM extensive algorithms on my board but I have no idea how to do that.

The Cerb’s STM32F405RG (LPQF64) has no FSMC signals needed for SRAM. But if you are designing your custom board you can go with VG or ZG (LPQF100 or 144) models that export the FSMC signals needed for external SRAM.
Take a look on ST site for STM32F4x7 eval boards, if I remind correrctly they have something about SRAM.

This is not a trivial task.

Also note that SRAM is limited in size. You can get 512KB or 1MB, but the price skyrockets. Also, the number of IO pins that must be sacrifised with SRAM is huge.

The newly released STM32F428 or 438 does have an SDRAM interface though. I have not investigated if you can use the 100 pin for SDRAM or if you will need the 176 or 208 pin versions…

Yes GMod.
I will consider to do something around G120 or G400 …
Unless you use BGA fat chips, you have to sacrifice lot of MCU features.

Hm, the F4 series continues to become more interesting!

Well, the STM32F438 does come in a 208 pin QFP format. Sure, it’s huge at 25mm or 30mm square, but it does have pins and not balls… :slight_smile:

I’m using the 100pin STM32F405VGT6. Our electrical engineer designed my board, I assume he can layout another with RAM. What software/firmware changes are needed on my end?

You have to open the porting kit and dig deep. As I said earlier, you can look at Hydra firmware to see some of the delta, but as everyone has said non-trivial.

You can also look at the firmware for the STM32F2xx from Oberon that is part of the Porting Kit. It has source for two boards, one with external ram and one without.

Since we’re on the second page of this thread and no one has bothered to actually answer your question…

First, you’ll need to download a copy of NETMF Porting Kit, and copy GHI’s open source ports on top of the porting kit.

You’ll need to either modify the existing FEZ Cerberus solution, or clone it. I’d recommend cloning it, making sure it compiles and works, and then modifying the cloned version. Work incrementally – when things break in the porting kit, it can be very difficult for a novice to be able to track down the problem (as there’s close to zero documentation out there to do anything, and the build process is quite a bit different from other embedded projects – even extremely complex, RTOS-powered ones)

Next, you’ll need to write code to initialize the RAM (ST has example code of how to do this). This is actually probably the easiest part.

Slightly more challenging: you’ll need to figure out where to put the code. Remember that there’s basically three folders where native code is stored for the FEZ Cerberus:

\DeviceCode\Targets\Native\STM32F4 – this folder contains HAL-level functions specific to the STM32F4

\CLR – this folder contains TinyCLR, which calls HAL/PAL functions and provides the runtime.

\Solutions\FEZ_Cerberus – this folder contains solution-specific code.

Every TinyCLR “Solution” is basically a Target plus the CLR folder.

You may be tempted to put the code in the STM32F4_Bootstrap.cpp file located in the STM32F4 Targets folder. It will certainly work there. However, this will get compiled into every solution that uses the STM32F4 target, which probably isn’t desirable. For example, any time you build FEZ Cerberus, you’ll end up building in that memory controller initialization code, which will most certainly hang the device or do other weird things.

To this end, normally, external memory init code is stored in your Solution’s DeviceCode folder, since memory is generally considered to be peculiar to a specific board.

It’s a stupid place to put it, but I’d probably just put it in IO_Init.cpp and be done with it. If you want to do it the right way, you can create a new CPP file with just the memory init code in it, modify the .proj file to compile it, and then make sure it’s getting linked into your firmware file, but if you just want to get it done, put it in the BootstrapCode_GPIO() function in the IO init file (which you know is already compiling). That function will be called before any writes to RAM or anything else, so it’s safe to put it there.

If you were to put it somewhere else, it will get called too late – i.e., after NETMF has already tried to write something to RAM.

Next, you’ll need to tell NETMF how much RAM you have and where it is. Modify platform_selector.h with the correct values for SRAM1_MEMORY_Base and SRAM1_MEMORY_Size.

Note that since external RAM and internal RAM are located at different, non-contiguous addresses, if you want to use both the internal and the external RAM, you’ll need to add additional defines for each bank of RAM. I’m not sure if the porting kit automagically detects how many banks you have total, or if you have to specify that somewhere, but I’m sure you can figure it out.

Optional: if you want to be able to load the firmware into RAM (useful for testing – it uploads much faster and doesn’t waste flash writes), you’ll also need to modify your scatter file for TinyCLR and/or TinyBooter. If you don’t need the ability to flash the firmware to RAM, don’t mess with the scatter files.

The GHI port won’t compile out of the box with GCC – you’ll need MDK. Other people on the forum have directions for how to get GCC working with the STM32F4 port.

As others have said, this certainly isn’t trivial – especially for the novice – but I’m sure you’ll be able to figure it out!

Just a tip – you may want to move the discussion over to the native programming board; it’s where all of us native/interop/RLP people tend to hang out :slight_smile:

Good luck!

1 Like

@ patc - I may be missing something, but Jay has answered your question by telling you exactly how to add memory. the only thing missing is the word “yes”.

@ Mike - The question was from @ untitled not @ patc :wink:

I just didn’t think those posts really helped answer his question. If someone tells you that 30 MHz SPI flash memory is too slow (see post #4), linking him to a 25 MHz SPI SRAM part is probably not particularly helpful, especially after he said:

Anyway, I was just trying to answer his question. I’m sorry I offended you to the point where you’ve felt the need to start arguing about who did/didn’t answer his question.

Let’s get back to the topic at hand!

Untitled, let us know if you have any issues configuring the memory controller – I can’t be of much help (I’ve never worked with the STM32F4 FSMC), but I’ll try my best to lend a hand!

@ Patc, I think we’ve all made assumptions on what skill levels people have; and this task really has been rated based on individual’s own perception and the unknown of the requestor’s skill. So we’re all right, in our own way - again, we all know different things and would only feel comfortable putting someone on a path when we know that it’s completely achievable. You obviously have a lot of knowledge of the internals and relevant code examples the vendors provide, which is great, but if the requestor is totally new to programming then the task is still much harder than you portray it - it’s all relative. I think it’s awesome that you’ve given great pointers in getting the job done, and have reassured that this is achievable with a level of work, now we need to see if all this gets taken further.