cancel
Showing results for 
Search instead for 
Did you mean: 

Run code from SDRAM with STM32F4 (e.g. STM32F229)

stcom9
Associate II
Posted on November 18, 2014 at 14:14

Hello,

we are considering to use the STM32F4, probably the STM32F429 or STM32F427. For our application we would need to run the program from SDRAM.

I was looking around for application notes, but could not find something specifically on that topic. E.g. in the AN2606 on page 75 it described to boot to ''RAM'' or ''System memory'', but does that include SDRAM? I am going through other application notes, and maybe I will find something, but it would be great if someone could point me to the right document(s).

Especially interesting would be for us

- how to configure boot to SDRAM

- the update of the flash initiated e.g. from a USB host, when the MCU is running code from the SDRAM

With an MCU from another vendor this turned out to be somewhat complicated, and I have to ask what support from ST there is in the form of application notes (and the like) for this use case - we are a bit reluctant to spent time to have to ''reinvent the wheel'', when there is no support for this from the vendor.

Kindest regards,

Tony
13 REPLIES 13
stm322399
Senior
Posted on November 18, 2014 at 14:34

Tony,

booting from SDRAM is a bit weird, because SDRAM is a volatile memory. The code is normally stored into flash, has some bootloader to copy/decompress itself into SDRAM and jump.

I would like to catch your attention to the fact that executing code from SDRAM has a number of drawbacks, the most noticeable being the performance. Expect a slow down of around 10x compared to execution from internal Flash of the MCU.

ST probably never did such an application note, because that kind of MCU does not target execution from SDRAM.

I am curious about your need to run from SDRAM, could you tell us more ? I know at least another MCU that *is* designed to run from SDRAM, maybe this is the one you need ?

--

laurent

stcom9
Associate II
Posted on November 19, 2014 at 12:36

Hello Laurent,

I asked a colleague, and I missunderstood our requirments (sorry, I am new to this company and project).

The problem is as follows, with our current MCU we need to move code execution to the SDRAM, in order to update the flash - cumbersome and it was difficult to implement.

So for the STM32F4, I would need to know the update process for the flash (if the update can be done without code execution from SDRAM, that would be good). But I will first read some more documentation, and then ask again a question if necessary.

Thanks,

Tony

Posted on November 19, 2014 at 13:05

In STM32F4, you can erase/program FLASH while running from FLASH (of course a different sector than the one being erased/programmed): if there is a single FLASH bank, the proccessor will stall; if there are two FLASH banks (in devices with >1Mbyte FLASH), you can run from the other bank uninterrupted.

You can also run from internal SRAM during programming, uninterrupted (you can't run from CCM RAM); but that's as cumbersome as running from SDRAM, except that way faster.

There may be an additional issue with the caches - you should flush/disable FLASH caching during programming.

Read RM0090 rev.7 ch.3.6 ''Erase and program operations''.

JW

stcom9
Associate II
Posted on November 19, 2014 at 15:19

Hello Jan,

thanks for that info! I see, having two internal banks would be the simplest solution with regards to firmware. Unfortunately for cost reasons we will have to choose a processor with only one internal flash bank.

I have gathered some more information from my colleague: During normal operation we run from internal flash. During our update process, we get the new firmware image (from an external component) and write it into SDRAM. Then we need to get the firmware somehow from SDRAM into internal flash.

Our options are (as far as I can see):

1. Currently we load a ''progammer'' into SDRAM, switch execution to SDRAM, and the programmer writes to internal flash. This is cumbersome, and furthermore we would need to port that process to STM32F4. If we can avoid this, this would be good.

2. As an alternative: we have an external flash, where we (maybe) could store something in external flash (e.g. the firmware image, or an programmer, or possibly both). Can this make things easier? We could for example:

- write firmware image to external flash

- switch code execution to external flash

- then write the firmware image from external flash to internal flash

- and then switch execution again to internal flash?

Another variant could be: Instead of switching execution during the update process, we might be able boot from external flash. Would that make the update process easier?

Sorry that I have to ask these question, I have no experience in that area and need to get ''up to speed''...

Kindest regards,

Tony

Posted on November 19, 2014 at 16:05

Unlike other platforms the ST FLASH doesn't not become completely usable while erasing/writing. Where others would return status information instead of valid data, the STM32 stuffs wait states on flash reads until it completes the pending operation. This can be a problem for meeting peripheral service windows, but can be avoided with RAM execution. The internal SRAM (non CCM) should be sufficient.

I'd suggest reviewing some of the IAP examples ST has for the platform. The USART ones use an Y-Modem type protocol, which like X-Modem is self throttling.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on November 19, 2014 at 16:07

If there is no other requirement than to copy the new image from SDRAM to FLASH (i.e. no other functionality needs to run while the update happens), then I'd run the programmer either from one dedicated sector (a small 16kB one) from FLASH or from internal SRAM. The ''copy'' routine itself is next to trivial; in the former case the program would stall automatically during erase/program, but it does not matter as it does not do anything during that time anyway.

If you need to maintain some functionality alongside the update (other than a LED indicating progress or similar), the task suddenly becomes highly nontrivial.

JW

Posted on November 19, 2014 at 17:12

Staging the entire image in SDRAM is reasonably ideal. The images I pull tend to be packaged and provide information about size, and integrity. The ability to hold the whole image greatly reduces the failure mechanisms where it is streamed and burned on the fly.

Generally speaking I would avoid situations where you completely erase the F4, you should have a boot loader, ideally fitting in the first 16KB sector, and capable of checking and flashing the image from SDRAM (SD, EEPROM, etc), and providing a de-bricking option, where say the SDRAM couple be filled via USART and XMODEM.

The code foot-print for a subroutine or subroutines to update the flash is pretty small, and can easily be copied to SRAM for that purpose, SDRAM is viable too, but as pointed out it's SLOW.

Your downloaded firmware image could include a flasher applet, but I'm honestly not seeing the benefit of running the ''new'' image in SDRAM, the Cortex-Mx have some hurdles with respect to address agnostic code.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
stcom9
Associate II
Posted on November 20, 2014 at 12:16

I had a bit difficulty finding example code on the ST website. Is the Discovery board related examples what you refer to?

http://www.st.com/stonline/stappl/productcatalog/app?page=partNumberSearchPage&levelid=SS1532&parentid=1734&resourcetype=SW

Or do you mean IAR? I there something publicly available? Or should I contact IAR?

stcom9
Associate II
Posted on November 26, 2014 at 12:14

FYI:

I now have the application note AN3965 (DM00036049.pdf) regarding ''STM32F40x/STM32F41x in-application programming using the USART'' - this should apply to the STM32F42x as well, but I could not find it at the F4x section on the website.

Will read it and see if it applies to our problem.