SD card not recognized

Stefan · Post by **Stefan** » Fri Aug 27, 2021 6:54 am

There was some discussion in the above thread about the SD card not always being recognized by the last development board. It's a good idea to move that discussion to a separate thread, should anyone want to continue.

The simplified SD card spec may be downloaded here:

https://www.sdcard.org/downloads/pls/pdf/?p=Part1_Physical_Layer_Simplified_Specification_Ver8.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver8.00.pdf&e=EN_SS1_8

As @Wavicle said, it follows from section 4.4 that the host is not required to keep a continuous clock frequency. The clock may even be stopped for instance while the host is filling its output buffer. However, the specification also talks about exemptions to this, for example during the ACMD41 command (card initialization). I don't know if the exemptions are relevant, but they might be.

Anyway, if the SD card during the initialization command requires a continuous clock frequency in the range 100-400 kHz, and if the initialization request/response, as I understand the code in dos/fat32/sdcard.s:232-301, consists of multiple bytes, the X16 running at 2 MHz will not be able to keep up at 100 kHz.

I have no intention to look any further at this question myself, at least not for now. I think the right way to proceed, is to make the PS/2 keyboard work at 8 MHz, and thereafter look at the SD card issue if it doesn't work reliably when the computer runs at 8 MHz.

BruceMcF · Post by **BruceMcF** » Fri Aug 27, 2021 7:41 am

If a multi-byte command sequence must be sent maintaining a minimum 100kbps, at 8MHz, given that system clocks and the SPI clock have no reason to be synchronized, that means that fewer than 80 clocks can be guaranteed to occur between the completion of bit0 send and BUSY going low and then the next byte retrieved, stored, and then the rise of the SPI clock for b7. At 4MHz, fewer than 40 clocks. At 2MHz, fewer than 20 clocks.

But this is after the completion of sending the byte. The byte is sent at 399kbps, so ~400kbps. So after the byte is stored into SPIDATA, at 2MHz, the next store would have to happen between 40 clocks and 60 clocks later.

That solution at 2MHz would be straightforward ... fetch the data, LDA (CMD),Y, then store it in X, THEN busy loop until /BUSY, then store X to SPIDATA, increment the Y index, check it against the length of a multibyte command, then go back to the beginning.

In other words, take the fetch of the next data byte OUT of the delay between ending the busy loop and storing the data to start the write, perform it while the previous data byte is being written. That way, even if the BUSY flag drops the CLOCK AFTER the bit is read, the write completes 14 clocks after the BUSY flag drops.

This sketch assumes address of the first byte of the CMD string is stored at W in zero page and the length of the command is stored at CMDLEN at an absolute address.

LDY #0

-- LDA (W),Y

TAX

- BIT SPISTATUS

BMI -

STX SPIDATA

INY

CPY CMDLEN

BMI --

If that is the problem, it seems like the same routine works at higher speeds, just with more busy loops.

Wavicle · Post by **Wavicle** » Sat Aug 28, 2021 3:01 am

The exceptions are during initialization with the ACMD41 command. In other cases, the host is free to stop the clock and forget that the SD card is there at all, but ACMD41 starts the card power-up sequence and you must check back to see if that is finished at intervals of 50ms at most. You may stop the host clock during that interval, or leave it running, doesn't matter as long as it is getting polled every <= 50ms and the clock frequency, when the clock is on, is between 100 and 400 khz.

I've spent several years as a silicon architecture engineer finding hardware bugs and driving RCA on them. With just the 6502 source code and an unclear description of SD card problem though, it's challenging to do any meaningful analysis. If we could get the dev team to sell a pre-release VERA board (and maybe release the RTL), I should be able to find the problem.

BruceMcF · Post by **BruceMcF** » Sat Aug 28, 2021 3:20 am

20 minutes ago, Wavicle said:

The exceptions are during initialization with the ACMD41 command. In other cases, the host is free to stop the clock and forget that the SD card is there at all, but ACMD41 starts the card power-up sequence and you must check back to see if that is finished at intervals of 50ms at most. You may stop the host clock during that interval, or leave it running, doesn't matter as long as it is getting polled every <= 50ms and the clock frequency, when the clock is on, is between 100 and 400 khz.

I've spent several years as a silicon architecture engineer finding hardware bugs and driving RCA on them. With just the 6502 source code and an unclear description of SD card problem though, it's challenging to do any meaningful analysis. If we could get the dev team to sell a pre-release VERA board (and maybe release the RTL), I should be able to find the problem.

If they are getting close to beta testing, maybe they can send a board, once they clear up the PS2 issue.

BruceMcF · Post by **BruceMcF** » Wed Mar 16, 2022 11:14 pm

Update: Note that with the Vera design now public, maybe it would be possible to sort out how to get hardware to @Wavicle to try to sort out the SD card issues.

Wavicle · Post by **Wavicle** » Thu Mar 17, 2022 2:02 am

On 3/16/2022 at 4:14 PM, BruceMcF said:

Update: Note that with the Vera design now public, maybe it would be possible to sort out how to get hardware to @Wavicle to try to sort out the SD card issues.

Last I heard it sounded like they may be down to two working VERA boards. I'm in the process of modifying an iCE40UP5K dev kit to be as close as possible to a real VERA. Everything is on a breadboard, so I doubt that I can run at 8MHz stable, but I'll keep my fingers crossed. Someone elsewhere pointed me towards the Upduino which looked like it might also work and was only $25 (so I have ordered 2). As lo ng no wires come out of my breadboarded X16 and there are no fires to put out at work, I might have something to test with in a week or two.

Stefan · Post by **Stefan** » Thu Mar 17, 2022 5:51 pm

A lot of dedication shown by @Wavicle !

BruceMcF · Post by **BruceMcF** » Thu Mar 17, 2022 11:25 pm

On 3/16/2022 at 10:02 PM, Wavicle said:

Last I heard it sounded like they may be down to two working VERA boards. I'm in the process of modifying an iCE40UP5K dev kit to be as close as possible to a real VERA. Everything is on a breadboard, so I doubt that I can run at 8MHz stable, but I'll keep my fingers crossed. ...

I wonder whether running 4MHz stable would be fast enough.

One idea if they want to hold onto the ability to run 2MHz, and 2MHz turns out to be too slow for the initialization to be stable, is to set it up so it can initialized into SPI mode with the micro-controller and after that be accessed via the Vera SPI.

Wavicle · Post by **Wavicle** » Sat Apr 02, 2022 4:38 am

After lots, and lots of debugging -- finally breaking down and pulling out the logic analyzer probe, I think I may have identified a bug on VERA that affects reads. So far it has only been seen on back-to-back auto-incremented VRAM reads, so it is possible the issue is specific to auto-incremented reads, but if the issue is caused by fast back-to-back reads then SD card read accesses (e.g. getting a directory listing, loading a program, etc.) is going to be heavily impacted by this.

It's still possible that this issue is caused by an error in my I2C->GPIO implementation, and I'm hoping that is the case. I've sent the logic analyzer trace to Frank; hopefully he will have time to take a look.

Wavicle · Post by **Wavicle** » Sat Apr 02, 2022 10:24 am

I root-caused the auto-increment issue to a VERA address bus hold time requirement. VERA is taking action on the register read based on the contents of the address bus when CS# (or RD#) is deasserted. The GPIO expander was changing all of those within a few hundred picoseconds of one another. By changing the code to first deassert CS# and RD# and then change the address bus, the issue went away.

On the CX16, CS# assertion appears to be combined with PHI2 which in theory causes them to change at the same time but in reality delays the critical CS# deassertion by the propagation delay of the gate(s) between the two and the stray capacitance of the signal wires. Pushing things to the edge like this is quite the game of chicken. If you push timing margins like this too close to the edge, small variations in board and IC manufacturing could cause instability in a relatively large percentage of devices in the field.

That said, the big question now is: could this be the cause of the SD card issue? After looking at the HDL again with this in mind, I think I found the problem with SD card access. It's a little technical but there is a reasonable-sized window of opportunity where CS# needs to deassert while the read strobe is active or the SPI auto transfer will not start. This bug would exhibit itself to the user as the disk randomly just not responding after they start some activity such as loading a program or the disk directory.

Does that sound anything like what was demonstrated in a video a few months ago?

More technical details posted on the VERA repo on GitHub: Narrow timing window may prevent SPI auto tx from initiating · Issue #5 · fvdhoef/vera-module (github.com)