I think SD cards don't work with DI/DO tied together.
DI is CMD and DO is Data0 in SD mode, so data would be interpreted as commands.
In SPI mode the Interface is sometimes fullduplex, you can send new commands over DI while DO outputs the read data:
Thanks, Andy. That is probably why some systems just run a continuous clock to the SD card. If we wanted to, though, we could switch direction for different clock edges in SPI mode and get away with three pins and one resistor.
We need to get some SPI example code working for boot.
Chip,
I have posted P1 test code on the P1 forum for testing.
The code is well documented and full of debugging in case a problem is found.
I have not been able to test older SD V1 SD cards as I cannot find any.
MMC cards are not usable (don't think they are worthwhile supporting).
I have tested up to a no-name 64GB microSDXC and they test out fine.
Chip,
I have posted P1 test code on the P1 forum for testing.
The code is well documented and full of debugging in case a problem is found.
I have not been able to test older SD V1 SD cards as I cannot find any.
MMC cards are not usable (don't think they are worthwhile supporting).
I have tested up to a no-name 64GB microSDXC and they test out fine.
It's too bad the streamer can't input a clock signal, instead of only running off its NCO's rollover. It would make software a little simpler. As it is, you need to coordinate instructions in time to get things correlated. I'm going to look into making the streamer trigger from pin rise, fall, and change (DDR).
It's too bad the streamer can't input a clock signal, instead of only running off its NCO's rollover. It would make software a little simpler. As it is, you need to coordinate instructions in time to get things correlated. I'm going to look into making the streamer trigger from pin rise, fall, and change (DDR).
I looked deeply into this on Saturday and I realized there would be way too much latency from input-transition-sensed to doing anything, as the streamer is pipelined, itself.
Here's what I realized, though: I already had this somewhat covered in the design by making a command buffer in the streamer. This doesn't mean you can clock from an external source, but it means you can put the timing exactly where you want it for clocked I/O, where the Prop2 is generating the clock. I modified the docs to explain this:
There is a single-level command buffer in the streamer, enabling you to give it two initial commands before it makes you wait for the first command to finish before accepting a third, fourth, fifth, etc. This command buffer enables you to coordinate streamer activity with smart pin activity. By executing an XINIT and then an XCONT, you get time during the XINIT command to instantiate a smart pin to perform some operation which will then correlate with the queued XCONT command. Think of tossing a ball up gently, so that you can then hit it with a bat.
For cases where the Prop2 is generating a clock signal over a pin, this works great. Using an externally-generated clock with the streamer is still impossible, though. I know right where to modify it, however.
They claim that you don't need CS if only one device is on the SPI bus...
Hey, maybe we could do this with 2-pins?
This is 4 pin SPI where on the slave the CS is always tied low.
This works if everything is bug free, but is risky even for one device and not work for all devices. If for mistake one of your subroutines fail to give the right numbers of clocks then all the communication will remain out of sync for these many clocks/bits.
CS is used to sync the bus. To comunicate to the slave where the first bit of message is. If something goes wrong, driving CS, will put the things again in sync for the next transaction/frame.
Chip,
I have posted P1 test code on the P1 forum for testing.
The code is well documented and full of debugging in case a problem is found.
I have not been able to test older SD V1 SD cards as I cannot find any.
MMC cards are not usable (don't think they are worthwhile supporting).
I have tested up to a no-name 64GB microSDXC and they test out fine.
Here is the link to the P1 thread as it's already off the main page
I would really like to verify SD V1 works. My guess is they are old SD cards, perhaps before microSD - maybe 256MB or similar?
You will note the code actually outputs $FF before all commands (even between CMD 55 + ACMD41). I am not sure if this is required between the 55+41 pair, but I can certainly say that it is required with at least some commands otherwise some cards do not work. My problem was that my SanDisk didn't work but my unknown brand Mixza did. There were a few issues I had to get right.
The output actually traces all commands and replies to the card.
They claim that you don't need CS if only one device is on the SPI bus...
This is 4 pin SPI where on the slave the CS is always tied low.
This works if everything is bug free, but is risky even for one device and not work for all devices.
Not even that - it only works on parts like HC595, that do not need CS at all
Most SPI parts do qualify on the CS edges, and many do a MOD 8 check, as a simple clock noise filter.
You could infer a CS with a monostable-timeout on the Clock stream, (some LED string parts do this) but that moves away from Static CMOS, and any OS interrupt would then be dangerous and at risk of affecting SPI links.
Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff) ' classic M4 exit Dual command
Send_1b_CS(2,$ff) ' nibble coverage, in case any parts lack the above, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
' << by here, BUS should be back in Single-bit mode.
PollBusy ' confirm device connected, and confirm is not Busy
' Optional firm reset - for some newer, larger parts.
Send_1b_CS(8,$66) ' newer 66H,99H command pair
Send_1b_CS(8,$99) ' newer 66H,99H command pair
Wait(>40us) ' does more than a pin-mode change
PollBusy ' unclear if poll busy can be used for 40us timing
' check device ID for <> 00,ff as connected device.
Looking thru the newest parts data, the exit times from RESET are more defined, and more open, and can vary from 35~40us to 40~100ms, worst case for reset during chip erase (rare)
I think a slight variant may be needed, on the boot timing handling.
The simplest, most portable way to PollBusy looks to be to use the Read Identification (RDID) (9FH) JEDEC command & check device ID for <> 00,ff as connected device - as above comment.
All candidate parts look to support RDID_9FH.
Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff) ' classic M4 exit Dual command
Send_1b_CS(2,$ff) ' nibble coverage, in case any parts lack the above, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
' << by here, BUS should be back in Single-bit mode.
' SW Reset - for some newer, larger parts.
Send_1b_CS(8,$66) ' newer 66H,99H command pair
Send_1b_CS(8,$99) ' newer 66H,99H command pair
repeat
ID = RDID_9FH
Try++
until (ID <> 00,ff ) or (Try > Equiv120ms)
' here, device is in 1B SPI, and ready for commands..
Read_03H...
Result: Parts without a SW reset, exit very quickly, (as RDID_9FH reads first time) and those with a SW reset, adapt to match the device variable exit times, as needed by device/state.
This covers watchdog resets, & P2 SW resets, as well as the usual power-up-boot.
Some parts have a hardware reset pin, and that can be also used, without conflict of above, for most robust reset action.
Flash parts look to time from leading reset edge, (ie it's a finish-what-it's doing action), so I think a RST/WDOG that gives a 100ms pulse, will have P2 and Flash ready at the same time.
To test Quad-RST and RST pin, it looks like this part is stocked : MX25L25635FMI-10G FLASH 256MBIT 104MHZ 16SOP
That has similar timing and commands to the Octaflash part, and the 16SOP part has a separate RESET# pin, allowing hardware reset to be tested. (in SPI and QuadSPI modes)
Addit: reliable toggle and reset-exit of Quad mode, seems to vary with part/vendor.
Winbond W25Q80JV has QE bit with both volatile and non-volatile copies, and has commands to load non-volatile (50h). A reset can transfer QE_NV(default) to QE
Fremont FT25H16 documents QE as only non volatile & is unclear on exit-quad choices. FT25H04 is cheaper/smaller, but has no quad mode.
Macronix MX25L25635F mentions QE as non volatile, but does also say 'Enable QPI mode : By issuing 35H command, the QPI mode is enabled. After QPI mode is enabled, the device enters quad mode (4-4-4) without QE bit status changed.' - appears using 35H command, is a volatile/reset safe means to enter QPI ?
Addit2: More digging finds this series https://lcsc.com/search?q=FM25Q
Those parts are quite low cost ( FM25Q08A-SO-T-G Package: SOP-8_150mil 500+ $ 0.1719), with the Winbond style 50h QE handling, and SW reset support & EnableQPI(38h).
Addit3: QE handling only matters to the user, not the P2 Boot.
The simple rule is : any QuadSPI/OstSPI user, must use a part/mode that can reset back to SingleSPI.
That means W25Q80JV, MX25L25635F, FM25Q08A are all looking ok, provided user avoids non-volatile QE.
FT25H16 appears from the (old) data to lack a volatile Quad mode, & has no SW reset, so would be ok in SingleSPI use only.
Low cost, volatile QE, choices look to be (lcsc.com)
Comments
For SD, well, I don't know...
DI is CMD and DO is Data0 in SD mode, so data would be interpreted as commands.
In SPI mode the Interface is sometimes fullduplex, you can send new commands over DI while DO outputs the read data:
Andy
We need to get some SPI example code working for boot.
I have posted P1 test code on the P1 forum for testing.
The code is well documented and full of debugging in case a problem is found.
I have not been able to test older SD V1 SD cards as I cannot find any.
MMC cards are not usable (don't think they are worthwhile supporting).
I have tested up to a no-name 64GB microSDXC and they test out fine.
Super, Cluso! I will go look at that.
I looked deeply into this on Saturday and I realized there would be way too much latency from input-transition-sensed to doing anything, as the streamer is pipelined, itself.
Here's what I realized, though: I already had this somewhat covered in the design by making a command buffer in the streamer. This doesn't mean you can clock from an external source, but it means you can put the timing exactly where you want it for clocked I/O, where the Prop2 is generating the clock. I modified the docs to explain this:
For cases where the Prop2 is generating a clock signal over a pin, this works great. Using an externally-generated clock with the streamer is still impossible, though. I know right where to modify it, however.
This works if everything is bug free, but is risky even for one device and not work for all devices. If for mistake one of your subroutines fail to give the right numbers of clocks then all the communication will remain out of sync for these many clocks/bits.
CS is used to sync the bus. To comunicate to the slave where the first bit of message is. If something goes wrong, driving CS, will put the things again in sync for the next transaction/frame.
forums.parallax.com/discussion/165173/sd-card-boot-testing-to-be-used-as-a-basis-for-p2-if-successful#latest
I would really like to verify SD V1 works. My guess is they are old SD cards, perhaps before microSD - maybe 256MB or similar?
You will note the code actually outputs $FF before all commands (even between CMD 55 + ACMD41). I am not sure if this is required between the 55+41 pair, but I can certainly say that it is required with at least some commands otherwise some cards do not work. My problem was that my SanDisk didn't work but my unknown brand Mixza did. There were a few issues I had to get right.
The output actually traces all commands and replies to the card.
Most SPI parts do qualify on the CS edges, and many do a MOD 8 check, as a simple clock noise filter.
You could infer a CS with a monostable-timeout on the Clock stream, (some LED string parts do this) but that moves away from Static CMOS, and any OS interrupt would then be dangerous and at risk of affecting SPI links.
I've posted this before....
This P2 SPI assembly code boots from a file on SD.
Looking thru the newest parts data, the exit times from RESET are more defined, and more open, and can vary from 35~40us to 40~100ms, worst case for reset during chip erase (rare)
I think a slight variant may be needed, on the boot timing handling.
The simplest, most portable way to PollBusy looks to be to use the Read Identification (RDID) (9FH) JEDEC command & check device ID for <> 00,ff as connected device - as above comment.
All candidate parts look to support RDID_9FH.
Result: Parts without a SW reset, exit very quickly, (as RDID_9FH reads first time) and those with a SW reset, adapt to match the device variable exit times, as needed by device/state.
This covers watchdog resets, & P2 SW resets, as well as the usual power-up-boot.
Some parts have a hardware reset pin, and that can be also used, without conflict of above, for most robust reset action.
Flash parts look to time from leading reset edge, (ie it's a finish-what-it's doing action), so I think a RST/WDOG that gives a 100ms pulse, will have P2 and Flash ready at the same time.
To test Quad-RST and RST pin, it looks like this part is stocked : MX25L25635FMI-10G FLASH 256MBIT 104MHZ 16SOP
That has similar timing and commands to the Octaflash part, and the 16SOP part has a separate RESET# pin, allowing hardware reset to be tested. (in SPI and QuadSPI modes)
Addit: reliable toggle and reset-exit of Quad mode, seems to vary with part/vendor.
Winbond W25Q80JV has QE bit with both volatile and non-volatile copies, and has commands to load non-volatile (50h). A reset can transfer QE_NV(default) to QE
Fremont FT25H16 documents QE as only non volatile & is unclear on exit-quad choices. FT25H04 is cheaper/smaller, but has no quad mode.
Macronix MX25L25635F mentions QE as non volatile, but does also say 'Enable QPI mode : By issuing 35H command, the QPI mode is enabled. After QPI mode is enabled, the device enters quad mode (4-4-4) without QE bit status changed.' - appears using 35H command, is a volatile/reset safe means to enter QPI ?
Addit2: More digging finds this series https://lcsc.com/search?q=FM25Q
Those parts are quite low cost ( FM25Q08A-SO-T-G Package: SOP-8_150mil 500+ $ 0.1719), with the Winbond style 50h QE handling, and SW reset support & EnableQPI(38h).
Addit3: QE handling only matters to the user, not the P2 Boot.
The simple rule is : any QuadSPI/OstSPI user, must use a part/mode that can reset back to SingleSPI.
That means W25Q80JV, MX25L25635F, FM25Q08A are all looking ok, provided user avoids non-volatile QE.
FT25H16 appears from the (old) data to lack a volatile Quad mode, & has no SW reset, so would be ok in SingleSPI use only.
Low cost, volatile QE, choices look to be (lcsc.com)
FM25Q08A-SO-T-G Package: SOP-8_150mil 500+ $ 0.1719
FM25Q16A-S0-T-G Package: SOP-8_150mil 500+ $ 0.3201
FM25Q32-SO-T-G Package: SOP-8_150mil 500+ $ 0.3256
W25Q16JVSSIQ Package: SOIC-8_208mil 100+ $ 0.3072 << note wider package