Add CRC7 and 16 to SD Card routines

[harrowm]

This one needs some testing by someone on different kit/SD Cards to mine. I have tested on a 020 and 010 board with FW 2.4 and a cheap 8Gb and Samsung 64Gb SD Card.

Maybe I should have feature toggled this via a #define .. let me know if I add that in.

My SD Card set up is "better" but not perfect. I don't think this code makes the SD Card 100% reliable on my setup, but I also don't think it does any harm to have it there ..

[harrowm]

Omg.  Let me recheck :oThanks for spending the time on this. On Nov 11, 2023, at 2:05 PM, Ross Bamford @.***> wrote: @roscopeco requested changes on this pull request.

Hmm, this seems to have introduced issues for me Tested here with 2 SDHC cards (both 32GB, one Kingston, one Phillips) and one SDv2 (2GB, transcend). All working reliably across multiple reads and writes (using sdfat_menu) under development firmware. With this change, the only card that came close to working was the Kingston, which did at least write and verify some of the file (though never the whole thing). I noticed writes were significantly slower here too. The other two cards "wrote" very (suspiciously) quickly and then consistently failed immediately at sector zero on the read back.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[harrowm]

You think the card is not storing the crc16 but recalculating and comparing to what’s been sent ?  Do all cards support crc16 ? Is it optional ?  (Or if they don’t support they just ignore?) On Nov 12, 2023, at 8:35 AM, Thomas Jager @.***> wrote: @0xTJ commented on this pull request.

In code/firmware/rosco_m68k_firmware/blockdev/bbsd.c:

• // Get checksum too (and ignore it ;) )
• BBSPI_recv_byte();
• BBSPI_recv_byte();
• result = true;

• // Check the checksum. Checksum stored big endian on sd card
• // Allow for any legacy rosco SD Cards written with a dummy checksum

I don't think this comment on legacy rosco_m68k cards having been written with a dummy checksum is correct. As far as I know, the CRC is used to protect against over-the-wire errors, not the integrity of blocks on disk, so I don't think that 0xFFFF being read is related to 0xFFFF having been written.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>