Microcontroller external memory interfacing - Page 1
Forum section: electronics / beginners

author: confused_embeddor
author_rank: Newbie
timestamp: March 30, 2022, 08:55:14 pm
content: Hi forum,I am curious to know how external RAM or FLASH is interfaced and used with microcontrollers. I have read that the external memory/storage elements communicate via SPI/QPI/QSPI. I am wondering if they have to be in included in the memory map of the microcontroller to be used. For example, if the external RAM is to be used as a complete heap memory, (with some linker file modifications/inclusions), how would I redirect the malloc requests to use the external RAM. Also, if I were to use external FLASH to store the OTA image, how would I ensure that the SPI data is routed to this external FLASH location. I am confused about the whole process of interfacing and using the external memory interfaces with a microcontroller.Any help would be appreciated, thanks. Any suggestions with respect to microcontrollers & memory elements to practice this memory interface activity would be great.Thank you in advance.

author: Benta
author_rank: Super Contributor
timestamp: March 30, 2022, 09:06:23 pm
content: The easiest way to think about it is to regard the external SPI/QSPI devices as disks that need file systems and drivers.That's extremely simplfied, of course.But it's not directly accessible memory to the CPU, like built-in RAM and ROM.

author: ataradov
author_rank: Super Contributor
timestamp: March 30, 2022, 09:39:57 pm
content: Many modern MCUs have direct memory mapping for QSPI flash devices with XIP mode. But usually it is read-only, so have limited uses for QSPI SRAM.But on a basic level, you just use SPI peripheral to talk to the flash. There is no confusion, since the flash is connected to specific pins mapped to a specific SPI peripheral.There is no way to put heap in the QSPI RAM unless MCU has it mapped directly into the memory space. And if it does, then it is trivial to do via a linker script.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 30, 2022, 09:50:09 pm
content: Depends on device, of course. The usual ways are:- External memory: handled by user e.g. SPI, I2C. Most older and base level MCUs are this way.- Internal peripheral, SPI, QSPI, whatever, customized for this purpose. Might be IO or DMA driven. (Not sure that I've seen an example of this before; my MCU experience is somewhat narrow.)- Internal peripheral, (Q)SPI, parallel bus interface, whatever, memory-mapped. May be DMA driven, or use wait states to delay access until real time data access is had. Or some combination say to implement buffering/caching, using internal RAM or its own.- Direct bus interface. Pretty uncommon these days but older MCUs had this as an option, or really old i.e. CPUs you had to add everything yourself, ROM, RAM, timers, everything.Note that wait states date all the way back to the olden days; you'd have to implement it with a counter / latches in logic, but it can be set by device / address range, so that say for an IBM-PC, the internal DRAM is say 3 wait states, video RAM is unavailable during scan, expansion cards are whatever, etc.Which, MCUs do to this day, of course; usually for the slower units, Flash access is single cycle (or maybe one cycle pipelined, so, transparent except on branching or arbitrary read), SRAM is 1 or 2 cycles, etc. That works when the CPU is up to 30, maybe 60MHz. On the faster types, the CPU can run from small internal caches at its, whatever, 200+ MHz, but without shadow or larger cache to back the Flash, it's limited to basically the same rate as basic types. Which -- sometimes you opt for, when you need reliable cycle timing that a cache would spoil (i.e. disable the internal cache / Flash accelerator). In which case you still get the value of the additional complexity of a e.g. STM32H7 or whatever, just not the raw CPU speed.Also, many modern MCUs use multiple internal buses or matrices anyway, so that there's no 100% common bus attached to everything; in that sense, an external parallel bus interface acts more like an extension of that, than as a peripheral itself (it still needs configuration of course, so has registers dedicated to it; but you don't really need to touch them once it's set up). So, there's some mixing and matching here, and these aren't hard rules or technical definitions, just rough classifications.Tim

author: Benta
author_rank: Super Contributor
timestamp: March 30, 2022, 09:58:42 pm
content: Ah yes, XIP mode. Didn't think about that one.But as you say, it's R/O and is basically the QSPI controller tricking the CPU into thinking it's addressing normal ROM.

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2022, 04:59:01 am
content: Quote from: ataradov on March 30, 2022, 09:39:57 pmThe humble ATMega2560 has 8 KB of internal RAM, but supports up to a 64 KB uniform address space by attaching 64 KB of RAM (well, or 56 KB if you use small chips) to some of the GPIO. You can use the extra RAM for anything, including running code or storing data, but there are a couple of extra clock cycles used for each access to the external SRAM.Of course you can add much more than that if you use some more IO lines to output a "bank number", but you'll only be able to access maximum 56K of the external RAM at any one time without programmatically changing the bank number.

author: cgroen
author_rank: Unknown
timestamp: March 31, 2022, 05:55:56 am
content: Quote from: Benta on March 30, 2022, 09:58:42 pmHyperRAM (octal SPI) is also an option (RW) and on f.ex i.MXRT from NXP they are mapped into normal address space (and pretty fast too)

author: eugene
author_rank: Frequent Contributor
timestamp: March 31, 2022, 02:22:24 pm
content: TheRaspberry Pi RP2040 MCU(as used in the Pi Pico) has zero on-chip flash. From the datasheet:External Flash is accessed via the QSPI interface using the execute-in-place (XIP) hardware. This allows an external flash memory to be addressed and accessed by the system as though it were internal memory. Bus reads to a 16MB memory window starting at 0x10000000 are translated into a serial flash transfer, and the result is returned to the master that initiated the read. This process is transparent to the master, so a processor can execute code from the external flash without first copying the code to internal memory, hence "execute in place". An internal cache remembers the contents of recently-accessed flash locations, which accelerates the average bandwidth and latency of the interface. Once correctly configured by RP2040’s bootrom and the flash second stage, the XIP hardware is largely transparent, and software can treat flash as a large read-only memory. However, it does provide a number of additional features to serve more demanding software use cases.They have a justification for this that I couldn't find while writing this post. Paraphrasing: QSPI flash memory chips are an inexpensive commodity item. Leaving the flash off-chip allows the designer to decide how much to include. My thought is that if flash is so cheap, why not just put a couple of MB on-chip?

author: ataradov
author_rank: Super Contributor
timestamp: March 31, 2022, 03:19:17 pm
content: Their justification can be anything - the reality is that doing on-chip flash is the most expensive and annoying part of the MCU manufacturing process. It is very hard, and realistically would take more efforst and expertise than the rest of the system. And they did not have resources for that.A reasonable compromise here is what GigaDevices were doing with their earlier MCUs - put two dies in the same package. But that's also expensive, and for mass production (and < $1 price) may not be viable. And even GigaDevices switched to an on-die flash because it is way cheaper if you can make it work.External flash has one very big drawback - no code security whatsoever. This works for Arduino, not for real products. And having to source and populate the memory chip is also a negative here.So, them saying that they intended to do so is like Apple saying that iPhone will not have apps and you should use web sites. Of course it is, until they have time to figure out something better.

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 31, 2022, 03:37:28 pm
content: I can't see the real benefit on running from qspi flash, else than allowing really huge programs.Ex. On the rp2040 running at 133MHz, spi freq is 1/4th (33MHz) and it takes 4 clocks to feed just one 16-bit instruction.A cache miss woudl be very expensive, 16 CPU clocks, and It won't read-ahead, you get the 16-bit instruction, execute it, and you would have to wait again for the next instruction to arrive.And you have 2 cores to feed! What a terrible bottleneck.The 16KB cache might help but I can't see how it could hold against a 16MB program. Only small repeating loops will avoid the cache miss?A stm32 might have 3-5 wait clocks, but reads 64-128bit at once, so you'll get 4-8 instructions after the wait states, running at full speed until next cache miss happens.