SD Card SPI Interface Issue - Read Operation Returns 0x3F/0xFF instead of 0x7F/0xFE
I figured it out. The issue has to do with these two cards being sensitive to my releasing the CS line between issuing the read command (CMD17) and starting to "poll" for the token. All other cards work fine (and in fact, all other SD SPI driver implementations that I can find do release CS between the command and the poll). I went back and reviewed the SD SPI documentation, and I have to say it's not very specific on this point. In any case, the modified driver not only works on the two cards that were failing, but my entire stack of test cards.

To clarify: My original driver (based on my interpretation of the SD spec and looking at other drivers I could find) treated CMD17 like a normal command: assert CS, send the command sequence, read back the response byte, and then deassert CS. For CMD17, the next step would assert CS again, then start looking for the "data token". This actually worked on most of my test cards, but not on two of them. The change treats CMD17 (as well as other read and write commands) specially, so it leaves CS asserted after sending the command and looking for the "data token"; it works perfectly on all cards I have.