[solved] SPIF gets cleared if ANY interrupt happens?

[Jubatian]

What are you trying to accomplish by the way here? (Or is it some top secret stuff for a new awesome project? )

I am just curious as we have a couple of SD code already, that I created along with the new bootloader should do pretty well (or does it also have problems with these cards?). If you need full-speed SPI with it for streaming type approaches, it is doable with some hacking. Of course it is assembly, if you want to specifically study the protocol for some other purpose (such as like a small SD library for another micro in some other project), then it might not be the best thing to go with.

[CunningFellow]

I concur the bootloader built in SD functions are the easiest thing to use.

If you need absolute full speed you can turn the CRC checking off and then graft in the SD_Simple block reading commands. It is hand crafted assembly intended to get absolute minimum clocks per data.

It also has "scatter/gather" data interleaving functionality built in. Though I imagine you just want linear data at maximum speed.

I hope you are aiming for 360x224

Or is it some top secret stuff for a new awesome project?

Well I've had a guess but I think we will have to wait and see.

[rv6502]

What are you trying to accomplish by the way here? (Or is it some top secret stuff for a new awesome project? )

I got a few projects that involve SD cards. Most not on Uzebox but it's got an SD socket and is hooked to my computer. And also learning FAT16/32 format.

And although I still don't know why SPI crashed before with the C++ code and doesn't anymore after using an identical asm function (not sure I want to spend time investigating that), I found out why the other cards didn't work.

SD_SendCommand(SDCARD_COMMAND_ACMD41_START_SD, (1 << 30));

No L suffix. headdesk

I gotta work on remembering int constants are 16bits.

What really threw me off was the 256MB SD card that came with the Uzebox kit.
it's not an SD card: It's an SDHC card.
It's under 2GB, sticker says plain "SD", but it won't accept MMC nor SD initialisation and it uses 512byte block addressing only.

it's a (reverse) fake SD card.

So 3/4 "SD" cards worked. Those that were actually SD cards. The "fake" SD threw me on a wild goose chase.

[Jubatian]

SD_SendCommand(SDCARD_COMMAND_ACMD41_START_SD, (1 << 30));

No L suffix. headdesk

I gotta work on remembering int constants are 16bits.

Didn't the complier send a warning on this one? It seems quite trivial for it to notice. If you don't do it already, it could be a good idea to complile with all warnings on (-Wall for GCC), and actually checking those warnings. False positives are rare, so usually it is better to just fix everything throwing a warning to be on the safe side. In case of shifting to the left, unless the type is clear, it is generally good practice to typecast or otherwise enforce a type of appropriate width (such as by these suffixes), avoids such situations!

What really threw me off was the 256MB SD card that came with the Uzebox kit.
it's not an SD card: It's an SDHC card.
It's under 2GB, sticker says plain "SD", but it won't accept MMC nor SD initialisation and it uses 512byte block addressing only.

Actually that was why the new bootloader was so important: it is not possible to get a definite SDSC any more (There are reasons for it, that unnecessarily complicated SDHC init was kind of a tollgate originally, however by now it is open, the many open source implementations independent of the SD association defeated it. Anyway, on the card end, to be SDHC compliant, you had to remove the MMC init, and I presume many companies ended up just using the SDHC firmware for smaller cards).

[rv6502]

Didn't the complier send a warning on this one?

Not when you accidentally that setting in the Makefile.