How to know the maximum External SPI Flash memory supported by a 32-bit MCU? - Page 1
Forum section: electronics / general

author: madhu.wesly01
author_rank: Regular Contributor
timestamp: February 10, 2018, 06:08:33 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 10, 2018, 06:30:19 am
content: 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.

author: madhu.wesly01
author_rank: Regular Contributor
timestamp: February 10, 2018, 07:48:26 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 10, 2018, 07:50:38 am
content: Quote from: madhu.wesly01 on February 10, 2018, 07:48:26 amI have no clue. This is a trivial search.Quote from: madhu.wesly01 on February 10, 2018, 07:48:26 amThere 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.

author: madhu.wesly01
author_rank: Regular Contributor
timestamp: February 10, 2018, 07:58:02 am
content: 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??

author: ataradov
author_rank: Super Contributor
timestamp: February 10, 2018, 07:59:52 am
content: No. Download the datasheet for any memory and see how the interface looks. This is pretty fundamental stuff for a system design.

author: madhu.wesly01
author_rank: Regular Contributor
timestamp: February 10, 2018, 08:04:03 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 10, 2018, 08:08:20 am
content: 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?

author: madhu.wesly01
author_rank: Regular Contributor
timestamp: February 10, 2018, 08:10:46 am
content: Yes, I will go through the datasheets and understand how it works.

author: dgtl
author_rank: Regular Contributor
timestamp: February 10, 2018, 10:56:15 am
content: 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.

author: Yansi
author_rank: Super Contributor
timestamp: February 10, 2018, 12:19:49 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 10, 2018, 05:20:53 pm
content: Quote from: Yansi on February 10, 2018, 12:19:49 pmI 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.

author: Yansi
author_rank: Super Contributor
timestamp: February 10, 2018, 05:55:09 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: February 10, 2018, 05:58:59 pm
content: Quote from: Yansi on February 10, 2018, 05:55:09 pmWell, 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.

author: Yansi
author_rank: Super Contributor
timestamp: February 10, 2018, 09:34:01 pm
content: 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).

author: westfw
author_rank: Super Contributor
timestamp: February 11, 2018, 12:57:56 am
content: QuoteSAMD51 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...)

author: Yansi
author_rank: Super Contributor
timestamp: February 11, 2018, 02:16:51 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 11, 2018, 02:19:49 am
content: 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.

author: Yansi
author_rank: Super Contributor
timestamp: February 11, 2018, 02:26:42 am
content: Just responding to the last paragraph from westfw. Is there any problem with that? I hope it is not

author: ataradov
author_rank: Super Contributor
timestamp: February 11, 2018, 02:28:25 am
content: Quote from: Yansi on February 11, 2018, 02:26:42 amWell, he was talking about SAM D51. And it does have FPU and caches.

author: Yansi
author_rank: Super Contributor
timestamp: February 11, 2018, 02:48:47 am
content: Sorry my fault, didn't notice the difference 21/51.

author: MT
author_rank: Super Contributor
timestamp: February 12, 2018, 05:43:15 pm
content: Octa SPI!

author: bson
author_rank: Unknown
timestamp: February 20, 2018, 02:02:56 pm
content: Quote from: Yansi on February 11, 2018, 02:16:51 amIt'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.htmlThe 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).

author: JPortici
author_rank: Super Contributor
timestamp: February 20, 2018, 03:04:21 pm
content: .. But if the interrupt routine doesn't use the FPU you don't need to save/restore its context, right?

author: Siwastaja
author_rank: Super Contributor
timestamp: February 20, 2018, 03:42:00 pm
content: Quote from: JPortici on February 20, 2018, 03:04:21 pmRight. 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.)

author: ataradov
author_rank: Super Contributor
timestamp: February 20, 2018, 05:39:07 pm
content: Quote from: Siwastaja on February 20, 2018, 03:42:00 pmI 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.

author: westfw
author_rank: Super Contributor
timestamp: February 24, 2018, 08:04:14 am
content: QuoteI 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.))