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

  • 6 months later...
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.

image.png

  • Like 5
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

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)

Edited by Wavicle
  • Like 1
Link to comment
Share on other sites

For those who like pretty pictures, here's the logic analyzer trace after I got it working. The two yellow dips in the middle were the problem children. If you draw a line straight down the middle of them you may note that the first 5 lines (from top to bottom) are "00011" ($03) representing VERA register $9F23 aka "DATA0" for both. The bottom 8 lines are 0010_0000 ($20) for the first and 0110_0001 ($61) for the second. Those are the correct values; previously it was reading $20 for both.

The more astute viewers may notice unusual spikes on D7 and WE_N appears to be asserted for the entire trace. D7 isn't working and I think it needs to be recalibrated. WE_N was "asserted" the whole time because the probe fell down out of position and I didn't notice 🤦‍♂️

 

DS1Z_QuickPrint6.png

Edited by Wavicle
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

Progress is slow, but steady. Tonight I was able to list the contents of an SD card - which happened to be blank.

image.png.f139dc1a6b0b127da3a3b8c6e04f6482.png

I've not yet stress-tested it to see if I can repro the SD card issue shown in the update video from August. Being built on a breadboard with an extra dose of stray capacitance on every single pin, I've not had luck running stable at 8MHz, but 4MHz seems to work okay.

Additionally, I have built an Arduino Nano based keyboard buffer that has fixed the keyboard issue - at least, it has for me. Even at 8MHz, KERNAL did not miss the single keystroke I was able to hit before it went haywire. We can say with certainty that the keyboard problem is entirely one of timing. Here is the 4MHz key-smashing test video I shared on Discord:

 

The Breadboard16 looks substantially less clean than it did before with numerous fixes, reworks, and outright kluges.
image.thumb.png.4dbd31982dd9dcb5de614bdcc57c1f76.png

Between the main board and the PS/2 connector in the lower right is the Arduino Nano key buffer that allows my USB to PS/2 keyboard adapter to work at 4MHz. Above and right of that, up against the multimeter, is the world's first third party X16 peripheral with two banks of 8 LEDs corresponding to $9F60 and $9F61 (assuming it is plugged it into the /IO3 select line). VERA and the SD card socket are on the left side. The unplugged component on the top half of the VERA breadboard is the DAC waiting its turn for integration testing. Resting above the two breadboards, posed just for this photo, is the assembled but not yet programmed or tested ATTiny and RTC board containing the power, reset, and NMI buttons. It will be exciting to get that working as my "reset switch" is currently the blue wire draped across the ROM (in the ZIF socket). To the upper right, the "reset switch" disappears under the YM2151 test rig waiting to get rebuilt onto the top half of the VERA breadboard.

  • Like 6
Link to comment
Share on other sites

  • 2 weeks later...

I have another quick update for this thread on progress with the SD card issue: The short version is: I've never seen my "Breadboard16" fail to recognize an SD card as seen in the update video from last August.

VERA will usually not come out of reset if an SD card is plugged in, but this is an electrical problem between the SD card SPI lines and the FPGA configuration flash SPI. (The v4 VERA fixed this by adding a digital switch that disconnects the SD card from the SPI bus until after the CDONE signal from the FPGA.) In fact, @Frank van den Hoef's VERA design and FAT32 code has been remarkably reliable (as long as files are named using only uppercase, that's a limitation of the original CBM code though). I've asked @Michael Steil about his SD card experience as well and he also has never encountered this issue.

I livestreamed my youngest playing both FlappyX16 and Chase Vault on my Breadboard16 compatible hardware to a small audience on Discord tonight which included @ZeroByte (author of FlappyX16) and @SlithyMatt (author of Chase Vault) and we all learned a bit about the differences between the hardware and the emulator and flagged some interesting corner cases for follow up (notably that the emulator significantly overestimates the available work units for sprite rendering in the hardware).

In any case, I've emailed David Murray about the details of his SD card because at this point I'm suspecting the problem is his card more than the X16 hardware or software. Hopefully it doesn't end up in his spam folder!

  • Like 3
Link to comment
Share on other sites

On 4/26/2022 at 2:06 AM, Wavicle said:

we all learned a bit about the differences between the hardware and the emulator and flagged some interesting corner cases for follow up (notably that the emulator significantly overestimates the available work units for sprite rendering in the hardware).

I would like to add that upon further investigation, we realized that it was not a sprite work units issue, but a sprite priority issue.

Namely, the VERA code draws sprites with the opposite priority as stated in documentation and as implemented in the emulators.

Documentation/Emu behavior: Sprite 0 on top of all sprites, then sprite 1, etc.....

VERA verilog behavior: Sprite 127 is on top, then 126, etc....

  • Thanks 2
Link to comment
Share on other sites

On 4/26/2022 at 12:33 PM, ZeroByte said:

I would like to add that upon further investigation, we realized that it was not a sprite work units issue, but a sprite priority issue.

Namely, the VERA code draws sprites with the opposite priority as stated in documentation and as implemented in the emulators.

Documentation/Emu behavior: Sprite 0 on top of all sprites, then sprite 1, etc.....

VERA verilog behavior: Sprite 127 is on top, then 126, etc....

Yep! Thank you clarifying that. I believe that I've fixed the Verilog causing this and sent a PR to Frank for consideration. (https://github.com/fvdhoef/vera-module/pull/11)

For all those not on Discord here are before (current VERA design) and after (VERA design w/ my sprite priority fix) photos rendered on real hardware (with hand-drawn red circled areas where sprites were hidden because the scoreboard background sprite was rendered on top of them):

image.thumb.png.cb07137dcaf30905434bb464512f9a37.png

  • Like 3
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