How to know the maximum External SPI Flash memory supported by a 32-bit MCU?

[madhu.wesly01]

Hi everyone,

I am working with ATSAMD21G18A-MF micro-controller and want to interface an external SPI NOR Flash memory to the MCU.

Please, can anyone tell me how to know the maximum External SPI Flash memory size that can be supported by a 32-bit MCU (say ATSAMD21G18A-MF) chip?


Thanks in advance.

[ataradov]

It is just SPI flash, MCU does not care how much of it you have. There is nothing there specifically for the flash inside the MCU. It won't even know you are talking to the flash, and not some temperature sensor.

[madhu.wesly01]

Thanks for the quick reply. Please clarify my few more queries in this regard:

a) What will be the maximum size available for SPI NOR flash memories in the market?
b) Won't be there any problem with address allocation and data storage if I use some GB sized memory with SPI interface?

Thanks in advance.

[ataradov]

a) What will be the maximum size available for SPI NOR flash memories in the market?

I have no clue. This is a trivial search.

b) Won't be there any problem with address allocation and data storage if I use some GB sized memory with SPI interface?

There is no allocation. You specify the address and read the data one byte at a time. I also doubt there is SPI memory anywhere close to GB.

[madhu.wesly01]

Hi Alex,

I also doubt there is SPI memory anywhere close to GB. - Yeah, I just used it to convey the max size.

So, finally, you are saying that there will not be any size limitation for the external memories talking with an MCU using SPI/I2C, yes??

[ataradov]

No. Download the datasheet for any memory and see how the interface looks. This is pretty fundamental stuff for a system design.

[madhu.wesly01]

It is just SPI flash, MCU does not care how much of it you have. - You told here that there will not be a problem with how much memory you are interfacing to MCU using SPI.

[ataradov]

There will be no problems. But if you need to read both flash and MCU datasheets and understand why it is the case.

How do you know that flash if going to be fast enough for your application, if you don't fully understand how it works?

[madhu.wesly01]

Yes, I will go through the datasheets and understand how it works.

[dgtl]

SD cards can be used in SPI mode. So technically you can connect a multi-GB SD card to your microcontroller for a large storage. (Of course, SD cards are not NOR, usually TLC NAND) But does it make sense? The SPI interface is quite slow, so unless you intend to log some data for a year or so and then read back with an external reader, the large storage is no use if you do not have enough bandwidth to do anything useful there.
The NOR flashes are not GB-s large, the technology takes too much silicon space. Larger flashes are NAND-based, either SLC, MLC or TLC. Number of times a block can be reprogrammed goes down for the more dense technologies, the order would be FRAM, EEPROM, NOR flash, SLC NAND flash, MLC NAND flash, TLC NAND flash. FRAM quite indefinitely reprogrammable, TLC can wear out at ~100 rewrite cycles.
If you need fast and large storage, consider native SD/MMC interface and then either add a SD card socket or solder on-board eMMC chip. There are plenty of microcontrollers with 8-bit SD/MMC interface, that is plenty fast with 8-bit eMMC chips or 4-bit SD cards. For example, STM32F2xx. SD and eMMC perform wear-levelling (internal remapping) of blocks, so you can't wear out one block before the others. At least the industrial grade ones do, I would not trust commercial grade SD cards.

[Yansi]

Sorry to disrupt your disscussion, but having a specialized peripherals to directly map the external (Q)SPI memory into the memory map of the MCU is nowdays quite common.  The MCU's peripherals will then take care of reading the data from the external device. Code and data can then be fetched directly from the external device, without any software intervention.

In this case, there may (or may not) be limitations to what size of memory can be mapped in there. Frankly, MCUs capable of mapping these (Q)SPI memories are typically 32bit ones, so there is enough memory space to map even the largest of (Q)SPI memories on the market.

I think the largest (Q)SPI memories on the market are somewhere in the hundred MB size. (64MB being the typical large ones you can see put into designs).

But almost always the (Q)SPI peripheral of such MCU supports a mode with all SW control. Then you can address whatever memory you want, heck not even memory, as the QSPI or SPI interface is also typically used as a rather nice high speed interconnect between FPGA and MCU in some designs.

[ataradov]

Sorry to disrupt your disscussion, but having a specialized peripherals to directly map the external (Q)SPI memory into the memory map of the MCU is nowdays quite common.

I would not say it is very common, you see QSPI with direct memory mapping on high-end devices and primarily for XiP functionality.

SAM D21 does not support QSPI in any way.

[Yansi]

I don't know if STM32 devices are considered high end, but almost all new devices in the L4, F4, F7, H7 line are equipped with QSPI peripheral that can map the QSPI device directly into the MCU's memory map. Code and data can then be fetched from the external memory chip without any SW intervention. Is this functionality really that rare on MCUs?

[ataradov]

I don't know if STM32 devices are considered high end, but almost all new devices in the L4, F4, F7, H7 line are equipped with QSPI peripheral that can map the QSPI device directly into the MCU's memory map. Code and data can then be fetched from the external memory chip without any SW intervention. Is this functionality really that rare on MCUs?

Well, yes, all new M4 and M7 parts tend to have it. And I don't know of any M0+ or other architectures that would (including used here SAM D21).

As a global percentage, I'd say it is rare.

[Yansi]

When one is in need of gigabytes of data, I do not recommend SPI for an SD card.  There are cheap MCUs with proper SDIO interfaces. Makes for faster transfer (and life easier, as the HW peripheral then can handle some stuff by itself).

[westfw]

I would not say it is very common, you see QSPI with direct memory mapping on high-end devices and primarily for XiP functionality.

SAM D21 does not support QSPI in any way.

SAMD51 does/will. (It's a CM4, despite the "samD" moniker.  Note that CM3/CM4 cpu designs include support for cache, while CM0/CM0+ doesn't.  QSPI without cache would be ... unpleasant.  (OTOH, you can implement whatever you want in the memory block outside the cpu itself.))  The current datasheet for SAMD51 says there are 16Mbyte in the QSPI address space.

The other popular chip with direct SPI support is the ESP8266 (and the ESP32 too, I guess.)  I wouldn't call it "high-end", either.

(It's interesting the way that low-end CM4 chips (SAMD51, MSP432) seem to be filling up the space I'd've thought would be occupied by CM0 chips.  Perhaps that lack of cache support, combined with the low speed of most flash memory processes, ends up being a problem...)

[Yansi]

Maybe also omitting the FPU from the CM4 is also a show stopper for many. Not sure if this "SAMD21" has it or not.  Most vendors omit the FPU, unlike STMicro, where the FPU is present in all CM4 devices. Have noticed that typically NXP/Freescale being those who omit the FPU for no apparent reason. You will not save much space on the die with that.  I consider that FPU a damn good property of such CPU.

[ataradov]

SAM D21 is a Cortex-M0+ device, so there is no FPU. Also, I'm not sure that "most" vendors do omit the FPU.

I'm not sure why this has degraded into Cortex-M7 discussion and what FPU has to do with SQPI. And nobody even asked about QSPI in a first place.

[Yansi]

Just responding to the last paragraph from westfw. Is there any problem with that? I hope it is not 

[ataradov]

Just responding to the last paragraph from westfw. Is there any problem with that? I hope it is not 

Well, he was talking about SAM D51. And it does have FPU and caches.

[Yansi]

Sorry my fault, didn't notice the difference 21/51.

[MT]

Octa SPI!

[bson]

Maybe also omitting the FPU from the CM4 is also a show stopper for many. Not sure if this "SAMD21" has it or not.  Most vendors omit the FPU, unlike STMicro, where the FPU is present in all CM4 devices. Have noticed that typically NXP/Freescale being those who omit the FPU for no apparent reason. You will not save much space on the die with that.  I consider that FPU a damn good property of such CPU.

It's not about die space, but about interrupt latencies.  With the FPU enabled every interrupt has to save its entire state - all 72 bytes of it - on the stack, then restore it on return.  This is done in hardware, and since Cortex-M eliminated FIQ and multiple register sets (other than PSP/MSP) there's no such thing as fast interrupts on the Cortex-M with the FPU enabled.  Without it they're pretty quick since they only stack up R0-R3 and R12.

Compare the exception state stored on the stack with vs without the FPU enabled:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html

The NXP LPC4078 I have in front of me has the FPU. I don't use it though.
The Kinetis K64 I'm looking at has it as well.  I believe with the Kinetis SoC's you can get it either with or without FPU (e.g. K64F has it, K64 doesn't, but I could be mistaken - I only just started looking at them).

[JPortici]

.. But if the interrupt routine doesn't use the FPU you don't need to save/restore its context, right?

[Siwastaja]

.. But if the interrupt routine doesn't use the FPU you don't need to save/restore its context, right?

Right. IIRC, some Cortex-M processors have "lazy" FPU context push that only happens when the ISR hits the first FPU instruction. This way, it's not even all-or-none - you can do the stuff requiring low latency first in the ISR, then calculate something on FPU. (I might remember wrong.)

[ataradov]

Right. IIRC, some Cortex-M processors have "lazy" FPU context push that only happens when the ISR hits the first FPU instruction.

I don't think this is the case. This will prevent other optimizations like tail-chaining.

But FPU context save can definitely be disabled on all Cortex MCUs with FPU enabled. And not using FPU in ISRs is probably a good idea anyway.

[westfw]

some Cortex-M processors have "lazy" FPU context push that only happens when the ISR hits the first FPU instruction.

I don't think this is the case. This will prevent other optimizations like tail-chaining.

I should work.  I don't see why it should interfere with tail-chaining, either.  Effectively, it changes the "internal return address" of the ISR to different microcode.  Sort-of CISC-y, but not too bad.  (There are already effectively two different sets of ISR epilogue depending on whether FP save is enabled at all...)

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/BCGHEEFD.html

(Back in the day, we sped up our ISR by not using floating point anywhere, and moving the main CPU registers into the FP registers, instead of stacking them.  (on MIPS or PPC, I think.  Probably without multiple interrupt priorities, or perhaps only for the ISR level that we considered most important.))