SDHC Interrupt Priority and Card Detect?

[Bill Greiman]

What is a reasonable interrupt priority for the SDHC DMA done interrupt?

I am testing with the priority that WMXZ uses.

  NVIC_SET_PRIORITY(IRQ_SDHC, 6*16);

My Interrupt Service Routine is small.

void sdhc_isr() {
  SDHC_IRQSIGEN = 0; 
  m_irqstat = SDHC_IRQSTAT;
  SDHC_IRQSTAT = m_irqstat;
  m_dmaDone = true;
}

Second question.

It appears that the microSD socket has a card detect switch. Is this true and is it connected to a pin?

Without a card detect switch it is possible to use the SD DAT3 pin. I don't like this method since it can't be used while the card is active.

SD cards have an internal 50K pull-up on DAT3. The card can be detected by the SDHC controller if there is a large external pull-down on DAT3.

NXP recommends a 750K pull-down that can be disconnected by software. I assume this is not present on Teensy 3.6.

 

[PaulStoffregen]

Priority 96 looks reasonable. DMA service interrupts should be in the 80 to 128 range. Don't go to 64 or less (higher priority) since those levels are used for things like Serial where data arrives in real time and would be lost if the interrupt is serviced too late.

There is no resistor on DAT3, nor any connection to the mechanical card detect switch. Detection will need to be done by querying the card's registers.

 

[Bill Greiman]

It's probably just as well not to have card detect. Users expect to just pull a card.

This sort of works on many devices, PCs, phones, and tablets, since the multi-threaded OS flushes everything to removable media after some time of inactivity.

I plan to post a SdFat-beta soon. It will not have the optimized large multiple block transfers.

Unfortunately it will have another performance hit due to the four byte alignment requirement for DMA. I use an internal one block buffer for transfers that are not properly aligned. I use memcpy() to move the data to the internal buffer. This can turn a large transfer into many slow single block transfers.

Here is an example of a subtle side effect.

  uint8_t buf[64*512];

  // Write a single byte.  
  file.write(64);

  // This write will be slow.
  file.write(buf, sizeof(buf));

Writing the single byte will cause the 32 KiB write of buf to be slow. 511 bytes of buf will be copied to the cache block and written to the SD. the write for the rest of buf now starts at buf[511], and is not four byte aligned. The write ends with the last byte of buf in the data cache so the next write of buf will also be slow.

Edit: The bench example without the one byte write:

File size 5 MB
Buffer size 32768 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
12641.46,8528,2093,2576
12451.84,8568,2110,2616

Starting read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
15093.14,4211,1741,2171
15231.61,2747,1747,2149

Done

With the one byte write:

File size 5 MB
Buffer size 32768 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
596.07,75324,47349,54951
598.57,73703,47303,54720

Starting read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2187.41,17151,14804,14977
2190.30,15902,14814,14957

This is a factor of 21 slower for write.

Here is the same misaligned test using the optimized SPI version of SdFat.

File size 5 MB
Buffer size 32768 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
3255.38,22045,9914,10038
3238.45,20084,9917,10089

Starting read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
3128.60,12387,10419,10475
3134.51,11826,10420,10453

I will start work on the optimized SDHC version after I post a first beta.

The documentation for the SDHC controller suggests it is possible to do very large multi-block transfers with pauses but there are no examples in the SDK and the documentation is not very clear about limitations.

If I can't make DMA pauses work, I will try polled FIFO transfers for misaligned addresses.