Is it possible to use the QSPI peripheral on the NRF52840 as an SDIO (4-bit wide) interface to an SD card?
Is it possible to use the QSPI peripheral on the NRF52840 as an SDIO (4-bit wide) interface to an SD card?
Hello,
I assume it is. I have never tried it against an SD Card, but if you know what to write to the SD card, then I don't see why it shouldn't work. We have some examples in the SDK using the QSPI, which you can test with. Just be aware that it will not work with breadboard wires if the frequency is too high. Check out this site to see how to test the QSPI with the nRF52840 PDK.
Please also be aware that there is an errata regarding power consumption using the QSPI. Remember to add the workaround in a product. The errata is found here. (Errata number 122).
Note that if you want to have the QSPI GPIOs to the pins on the nRF52840 PDK, you need to fix the solderbridges SB20-SB25 and SB10-SB15. These are explained on the PDK, and you will also find this information on infocenter.
Best regards,
Edvin
Looking at the QSPI documentation http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fqspi.html it seems it has a hard-wired protocol implemented. It seems software is not in control of the commands, and can just issue commands, read from addres xxxx, write to address xxx. This would mean the SD card has to accept these commands.
Looking at the description of the IFCONFIG0 register, it mentions opcodes that do not correspond with the SD card commands. Therefore I doubt it will work.
Thanks for the help guys.
Looking at the documentation, the section on 'Sending Custom Instructions' combined with that on 'Long Frame Mode' suggest that it's possible to implement a custom protocol, though I could be seeing the world as I'd like it to be rather than as it actually is :) Streaming audio while logging to file wasn't working out for me on my current DK, but have one on the way with Rev C silicon (i.e. no 8MHz SPI limit). 16MHz might be enough that I don't need to worry about QSPI. Though would still be nice to get it going -- I'd imagine it would mean more time in idle -> better power efficiency?
I have not tested the QSPI with custom protocol, but I assume that it is working.
But yes, in general more time in IDLE -> better power efficiency. Just remember that if you go with the QSPI, you have to use the PAN workaround that I mentioned in the first reply, or else you have a not-so-great power efficiency :)
BR,
Edvin
I have not tested the QSPI with custom protocol, but I assume that it is working.
But yes, in general more time in IDLE -> better power efficiency. Just remember that if you go with the QSPI, you have to use the PAN workaround that I mentioned in the first reply, or else you have a not-so-great power efficiency :)
BR,
Edvin
