0

Metro M4 SD card
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Metro M4 SD card

by lond on Sun Jul 08, 2018 8:22 am

I'm planning to move one of my current project to the "M4"-flavor and I have the following questions:

Can I increse the speed of the R/W on a SD-card? Can I use DMA?
Can I instead of a SD-card increase the size of the onboard SPI memory? Or replace the SPI memory with a SD-card?
What is the R/W speed of the onboard SPI memory? What is the expected lifetime of the SPI memory?

/// Marcus

lond
 
Posts: 2
Joined: Sat Jul 07, 2018 8:26 am

Re: Metro M4 SD card

by adafruit_support_mike on Tue Jul 10, 2018 3:53 pm

SD cards have two data interfaces: the high-speed one that you have to be a dues-paying member of the SD Association to use (and then can only use under the terms of an NDA), and a basic SPI interface.

The SPI interface has gotten faster as the cards have evolved, mostly because the Flash arrays and microcontrollers inside the cards have gotten faster. It takes more work to slow those pieces down, and isn’t worth the effort.

The maximum transfer rate varies from one manufacturer to the next, but the ultimate limit will be the SPI speed of either the microcontroller you program or the one in the card. The M4’s maxium SPI rate is pretty fast, so you should probably see some improvements when you do lots of large reads.

The maximum rate for writes is limited by the Flash array, and will be at least a couple orders of magnitude slower than the SPI rate. Speeding up the communication between the microcontroller and the card will have a negligible effect there.

You can try doing DMA if you want to go past the M4’s SPI rate, but you’ll have to configure the output as an SPI channel.

adafruit_support_mike
 
Posts: 54164
Joined: Thu Feb 11, 2010 2:51 pm

Re: Metro M4 SD card

by westfw on Thu Jul 12, 2018 3:07 am

the SAMD51 has a SD/MMC Host Controller (SDHC) peripheral. Does that mean that Atmel (Microchip) has "paid the dues", or does each end-product that wants to use have to join up as well?
(It looks like it uses the same pins as the QSPI interface (plus more?), so it wouldn't be available on the Metro M4 anyway, but I curious about the licensing issues.)
User avatar
westfw
 
Posts: 1459
Joined: Fri Apr 27, 2007 1:01 pm
Location: SF Bay area

Re: Metro M4 SD card

by adafruit_support_mike on Thu Jul 12, 2018 3:46 am

From what I can tell, you still have to pay to play.

The Simplified Specification is available here:

https://www.sdcard.org/downloads/pls/

and while they say it's the non-confidential version, the document you download is full of sections like this:

8.1.3 Interrupt Period Definition
This section is not included in the Simplified Specification.

Figure 8-1 : Continuous Interrupt Cycle
8.1.4 Interrupt Period at the Data Block Gap in 4-bit SD Mode (Optional)
This section is not included in the Simplified Specification.

8.1.5 End of Interrupt Cycles
This section is not included in the Simplified Specification.

8.1.6 Terminated Data Transfer Interrupt Cycle
This section is not included in the Simplified Specification.

The SAMD51 contains the registers listed in the spec (they'll tell you what those are), but to develop or distribute code that uses the registers, it looks like you need the complete/confidential spec.

In that sense, it would be like the Bluetooth Classic features of the ESP32: the hardware is there, but to use it you have to pay the working group for a vendor ID number.

adafruit_support_mike
 
Posts: 54164
Joined: Thu Feb 11, 2010 2:51 pm

Re: Metro M4 SD card

by alkire on Sat Jul 28, 2018 9:17 pm

I rewrote the SDHC driver for the SAMD51 and have FatFS working. It does work reliably but... it was slow.
The data sheet is vague on the SDHC and missing crucial performance data. Requiring an NDA might explain a lot.

Even at full clock rate, Read 512 byte block Transfers was 637KB/s. That is, the measurement was from the time the command to read a block is sent to when the buffer is ready to read was 784usec. I used the TCC register with software events for timestamp on a custom board to measure this. It probably would be better to use the SERCOM as SPI master for talking to a MicroSD than the SDHC.
I asked Microchip about the performance with a similar timed example from their FatFS example on the E54 dev board. Microchip is usually pretty good at getting back to me although this question was asked in May and is still at the MCHP Internal Feedback stage of response.
So we decided to drop the MicroSD from our product.
Bob

alkire
 
Posts: 5
Joined: Mon Feb 12, 2018 3:04 pm

Re: Metro M4 SD card

by lond on Mon Aug 06, 2018 7:14 am

I would like to share my current design of my 10-DOF data logger:
It's currently based on the M0 platform.

Image

Image

Image

Image

And now the new design based on the M4 that I'm working on:

v9_a.png
v9_a.png (82.12 KiB) Viewed 209 times


Due to the speed limit of the SD-card, my thought is to use the SPI-memory in the M4-design as a buffer for the data and after the measurement is complete move the information to the SD-card. Or is the the SPI-memory in a formated state and it also suffer speed limitations? Can I increase the size of the SPI-memory? Should I add a extra SPI-memory to the "normal" SPI-bus?

/// Marcus

lond
 
Posts: 2
Joined: Sat Jul 07, 2018 8:26 am

Re: Metro M4 SD card

by alkire on Mon Aug 06, 2018 5:34 pm

I wrote an article on the SDHC on the D5x and E5x processors here -> http://alkgrove.com/index.php/2018/08/0 ... md51-sdhc/

You can try out the SDHC on the E54 Xplained development board with the FatFS example on start.atmel.com and see if it performs as you would like. Adafruit added external memory using the QSPI interface on their dev boards. Since it can do execute in place (ala ESP32), the performance is probably decent. I haven't tried it yet, but would look there for an external memory interface.


Bob

alkire
 
Posts: 5
Joined: Mon Feb 12, 2018 3:04 pm

Re: Metro M4 SD card

by vincentp on Thu Sep 27, 2018 2:06 pm

alkire wrote:I rewrote the SDHC driver for the SAMD51 and have FatFS working. It does work reliably but... it was slow.
The data sheet is vague on the SDHC and missing crucial performance data. Requiring an NDA might explain a lot.

Even at full clock rate, Read 512 byte block Transfers was 637KB/s. That is, the measurement was from the time the command to read a block is sent to when the buffer is ready to read was 784usec. I used the TCC register with software events for timestamp on a custom board to measure this. It probably would be better to use the SERCOM as SPI master for talking to a MicroSD than the SDHC.
I asked Microchip about the performance with a similar timed example from their FatFS example on the E54 dev board. Microchip is usually pretty good at getting back to me although this question was asked in May and is still at the MCHP Internal Feedback stage of response.
So we decided to drop the MicroSD from our product.
Bob


I thought I would bump this topic as well, as I'm in the same boat for implementing SD card on a SAMD51 design, migrating from older microcontrollers. The read delay is expected for single block read (CMD17) and was confirmed to be just the same on my former board. It highly depends on the SD card used, though. A bad sandisk fake / clone can reach 3+ ms before giving you the block access, while a 512 MB (genuine) sandisk from 10 years ago has 366 µS.
I check with the oscilloscope, once the block is ready to be read, the SAMD MCI sucks up the bytes at the right / expected pace with a 25 MHz clock and 4 bit interface and it takes only 40 µs to read.

I'm now looking for some proper code to get CMD18 implemented, I don't know how it will work in with integrated MCI : I used to send the command (via SPI) then feed dummy bytes until sending the stop command. I can read the first block, I just don't know how to proceed.

Finally, I've also implemented FATFS (using single block read, as it seems to be really block oriented) and it takes 23ms to f_read to return, while sectors are still read in 400 µs (ish)

(alkire, I've emailed you regarding this topic)
vincentp
 
Posts: 110
Joined: Tue May 15, 2012 3:29 am

Re: Metro M4 SD card

by vincentp on Sat Sep 29, 2018 5:52 am

to echo on this with today's work : I managed to implement a multi block command on the SAMD51 (CMD18) in order to compare single block read and performances are stellar. The block preparation time (CMD17 and CMD18 for the first block) will always take time but it depends on the card, really. I got a huge variance testing several cards, from 340µs to 3.16ms. After this, the card controller (SD card size) is smart and will start preparing the next block whatever you do. If you do multi block read, the block access time will drop drastically as there is no need to send a new command, just to wait for the card to be ready to deliver. If you do another single block command on the next sector, the wait time drops a bit in general. If you keep reading the same sector (which tells the controller to "rewind" the NAND flash pointer) access time remains long.

On my 8GB card, I get an initial block access time of about 360µs including the read of the block. If I keep reading with multi block read, the overall time per block decreases rapidly when averaged over a large number of blocks. The block time read itself with a 4 bit interface @25 MHz is about 41µs. I converge toward 42µs after about 1500 block read.

Bottom line : I can get close to 12 MB/s read with multi block and about 1/10th of this with single block read. 1MB/s remains sufficient for my application. I don't think there are a lot of FAT library that really support "smart" cluster chain look up, even with a bit of cache. As a result, only single block read operation (single sector) are generated but I have to check. The smart part would be to find out if you reading a new cluster, but that works only if you're going to buffer that whole cluster. Based on memory usage, most application would buffer 1 or best case 2 sectors, which doesn't really take advantage of the multiblock read (30-40% gain, still).
vincentp
 
Posts: 110
Joined: Tue May 15, 2012 3:29 am

Re: Metro M4 SD card

by danhalbert on Sun Oct 14, 2018 9:36 am

@vincentp, is your code available in github or elsewhere? I'd be interested in your implementation. Thanks!

danhalbert
 
Posts: 1284
Joined: Tue Aug 08, 2017 12:37 pm

Re: Metro M4 SD card

by vincentp on Sun Oct 14, 2018 9:43 am

danhalbert wrote:@vincentp, is your code available in github or elsewhere? I'd be interested in your implementation. Thanks!


I've mostly played with Alkire's code !
vincentp
 
Posts: 110
Joined: Tue May 15, 2012 3:29 am

Re: Metro M4 SD card

by danhalbert on Sun Oct 14, 2018 10:21 am

Thanks -- did you add the multiblock command yourself? I'm particularly interested in that.

danhalbert
 
Posts: 1284
Joined: Tue Aug 08, 2017 12:37 pm

Re: Metro M4 SD card

by vincentp on Sun Oct 14, 2018 10:44 am

danhalbert wrote:Thanks -- did you add the multiblock command yourself? I'm particularly interested in that.


it's already in the SDHC driver (which originates from ASF, heavily cleaned by Alkire). What application are you working on ? do you implement multiple block read on a FAT type system or RAW SD ?
vincentp
 
Posts: 110
Joined: Tue May 15, 2012 3:29 am

Re: Metro M4 SD card

by danhalbert on Sun Oct 14, 2018 10:48 am

It's implemented at the block level, in CircuitPython: https://github.com/adafruit/Adafruit_Ci ... _sdcard.py. I'm interested because we have a bug (https://github.com/adafruit/Adafruit_Ci ... /issues/11) that causes some kind of hang on the read after a multiblock write. I wanted to see your implementation to see your command sequencing and waiting for command completion. I'll look at the ASF driver as well -- thanks for the reference.

danhalbert
 
Posts: 1284
Joined: Tue Aug 08, 2017 12:37 pm

Re: Metro M4 SD card

by vincentp on Sun Oct 14, 2018 10:59 am

NP. Sorry I can't help on python implementation, I'm not python savvy yet (training course in november at work)
vincentp
 
Posts: 110
Joined: Tue May 15, 2012 3:29 am

Please be positive and constructive with your questions and comments.