Jump to content

SD card not recognized


Stefan
 Share

Recommended Posts

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.

  • Like 2
Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

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.

  • Thanks 2
Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use