Small addition to what i said above. A controller reset does not trigger the card detection timer but it does reset the whole reg so both timeout and card detection are set to 14. 15 is probably a test mode as said to test your driver for proper error handling (less useful for card detection).nocash wrote: ↑Mon May 17, 2021 7:28 am Okay, now I got the delay reproduced using SDMMCCTL on 3DS. I don't know if there's a similar way to trigger the delay by software on DSi.
I got the same timings on 3DS, "400h SHL (0..14) HCLKs" for value 0..14. And "100h HCLKs" for value 15.
Status bit4 and bit5 get set after that delay.
Alongsides, I've noticed that Status bit9 and bit10 are also getting set about 2D000h..36000h HCLKs (=circa 3ms) after activating SDMMCCTL. That happens even without cart inserted, it's not useful, but it's interesting: Apparently, at that time, the data line pull-up resistors are receiving enough volts to be treated as "high", though the supply is probably still less than 3.3V at that point. So I've scope-checked the SD Slot 3.3V power pin on DSi and Old3DS...
On the DSi, it does increase almost linearily from 0V to 3V within 3ms, and then suddenly jumps from 3V to 3.3V. That's happening on power-up, before booting from SD/MMC, so software won't have to care about that.
On the 3DS, it does increase somewhat sine-like from 0V to 3.3V within 4.2ms (once when activating it via SDMMCCTL bit0=0?). Together with the 1ms card boot up time, the delay should be at least 5.2ms. So, yes, setting 9 (almost 8ms) sounds right, and 8 (almost 4ms) would be too short.
I didn't knew the toshsd.* source code. Yup it looks closer (or more complete, the other chips should have the Error bits, too, but the tmio source code didn't mind to define that bits).
Yeah, bit 9 and 10 are the DAT3 versions of 4 and 5. It's wonky in practice and Process9 does ignore these bits (9 is also getting masked). Something i have not tried with SDMMCCTL is if we can move the SD card port glitch-free from one controller to the other if we leave the power on. I also don't know how the power bits are implemented in hardware. Maybe it's a few more GPIOs that go to the PMIC or mosfets? I doubt the silicon is switching that load since SD cards can pull a few hundred mA.
Jumping from 3V right up to 3.3V is quite odd. The spec recommends a smooth ramp-up.
Toshiba seems to be making a huge number of variants of these controllers matching the requirements of the customer. I really think Nintendo could have chosen a better one. The power of 2 divider alone is a no-go (Why Toshiba? A integer clock divider is piss easy to implement.). But i guess they went with it for cost. But them implementing a whole bunch of per-CMD response types in hardware requires a lookup table and die space again. This is so inconsistent. And let's not even start with the 32 bit FIFO they duct taped on top...