What type of SD cards are supported?

[Jubatian]

I was trying to run a game on the hardware. First (without much reading, I admit) I copied a .bin file onto a micro-SD I had lying around, plugged it in the Bitbox, and using an USB keyboard I assume I started it (the file's name showed in the selector, I tapped Enter). Then the screen went blank, my monitor wouldn't sync any more (the game is bitbox-jump by the way).

Then (as I couldn't get to have an image at all) I read how to reset it into the bootloader, and that the card should be containing a second boot binary. I copied that off from this repo (that builds for me) onto the card, and with that, I could successfully return to the second bootloader. However it is different, it wouldn't list any files on the card, even though I still had the game on it.

The card is an SDSC (256Mbytes), it was formatted FAT-16. After reading the Wiki, and seeing FAT-32 mentioned in it, I reformatted it, but still, the game's file wouldn't display (even though the second boot loader starts). I presently don't have any SDHC Micro cards, so I can't try what would happen with one.

For me it seems like that this second boot, compiled from the repo, doesn't support SDSC cards (or at least that seems to be the most plausible explanation to my experience), and maybe neither FAT-16, while probably the first boot does (as it apparently could load the second boot from the card).

Could this be? (The card is certainly an SDSC, I tested its protocol in another project)

[Jubatian]

I confirmed this now. The 1st bootloader certainly can use my SD cards, I compiled a smaller example program into RAM (LINKER_RAM = 1 in the Makefile), and naming it 2nd_boot.bin, it loads as a 2nd bootloader proper. So I can actually mess around with the box this way! (so the 1st bootloader what I have on the BitBox apparently can use my cards) It is a rev.2.5 board.

[pulkomandy]

On Fri, Jun 08, 2018 at 03:59:38PM +0000, Sandor Zsuga wrote: I confirmed this now. The 1st bootloader certainly can use my SD cards, I compiled a smaller example program into RAM (LINKER_RAM = 1 in the Makefile), and naming it 2nd_boot.bin, it loads as a 2nd bootloader proper. So I can actually mess around with the box this way! (so the 1st bootloader what I have on the BitBox apparently can use my cards) It is a rev.2.5 board.

I think I have a similar problem witn 2nd_boot failing to show any files. But I'm not sure which version of it I'm using currently.

[makapuf]

Hem. It seems 2nd boot needs definitely needs some love.

[Jubatian]

I did some experiments on the 2nd bootloader. As far as I could track, the program dies in an infinite loop within game_init(), there within f_mount(), and there within find_volume(). That latter was too big for me for now to figure out (it is in sdk/kernel/fatfs/ff.c).

[makapuf]

Fatfs is an independent library I used - it's used everywhere and I guess it runs much better than my own code, being gameinit or the fatfs to lower layers adapter.

[Jubatian]

"or the fatfs to lower layer adapter" - I am also thinking that the most possible, however the way I attempted to debug it would be necessary to go through the Fatfs library until pinpointing an interface routine. I simply comment out code and look at the results, it is quite simple: if the bouncy smiley is there, then game_init() passes, if not, then it doesn't. Very tedious as for every attempt it is necessary to check it on the BitBox (and I have only an SD reader, not Micro-SD, and only a single monitor, so that's a lots of plugging in & out for a single test).

EDIT: Maybe if there was a way to print stuff on-screen on the code path to see how far it goes in... Guess that could work given that the stuff printed earlier than the deadlocking function displays.

[Jubatian]

I tracked the execution path further, finding this:

game_init() -> ff.c/f_mount() -> find_volume() -> diskio.c/disk_initialize() -> stm32f4_discovery_sdio_sd.c/SD_Init() -> SD_EnableWideBusOperation() -> SDEnWideBus(ENABLE) -> FindSCR()

There it gets stuck in the loop starting as "while(!(SDIO->STA & (...".

I have absolutely zero experience with ARM so far or these libraries, so I am passing from this. I am planning to experiment with small stuff anyway, for that, the first boot for me is OK for now.