Trying to Figure out SPI lines on P2

Duane Degn

I'm working on a board which will use the P2, flash and SD card. I figured copying the schematic from the demo board would be a good place to start.
I just noticed the clock lines of the flash and SD card are not controlled by the same pin.
It appears that there's a reason for this but I haven't managed to make sense of this yet.


Am I correct in thinking the flash and SD card will have different Clock and chip select lines than one would expect when using multiple SPI devices?

I've tried searching the forum for these answers but I got lost in the pages of results which appear to discuss possible pin combinations.

jmg

Duane Degn wrote: »

I just noticed the clock lines of the flash and SD card are not controlled by the same pin.
It appears that there's a reason for this but I haven't managed to make sense of this yet.

FWIR, that's a bit of a kludge to keep the interface compact, otherwise separate chip select lines would be needed in a 'classic SPI' design, and SD needed to be a 'zero overhead' or hidden option.
There are other combinations that are tolerated by the passive device, and P2 does not care which pin the clock is. The boot ROM manages all this via the tables above, as it searches for fitted devices.
In a similar way, sometimes i2c bus designs swap SCL and SDA to give a second set of phantom address / devices.

Peter Jakacki

Yes, we wanted to keep the number of "dedicated" I/O to a minimum and when I designed the first hardware reference in the form of P2D2, the Flash was already situated in software on P61..P58 although it had never really been used in FPGA designs since the boot ROM didn't exist.

Rather than use up another I/O line I was able to confirm that the SD card could be connected to the same lines with CLK and CS swapped and co-exist with a Flash device. There was one small problem though in that SD cards are not totally SPI compatible in that when the CS is released the MISO data line "might" and usually do not float. Some do, some don't. This is not a problem during boot but only if you want to use Flash after using SD. The solution was to make sure that the Flash could still drive the line by inserting a series resistor in the SD's Data Out (MISO).

BTW, I further dedicate P57 and P56 for an I2C bus on the P2D2 rather than taking my chances trying to mix that with the already mixed SPI lines The other 56 I/O are totally uncommitted.

I've included a schematic and note that the RESn line requires a pull-up since P2 does not have any internal pull-up. However the latest version of P2D2 has a pull-down to allow for a RUN instead.

rogloh

Peter Jakacki wrote: »

Rather than use up another I/O line I was able to confirm that the SD card could be connected to the same lines with CLK and CS swapped and co-exist with a Flash device. There was one small problem though in that SD cards are not totally SPI compatible in that when the CS is released the MISO data line "might" and usually do not float. Some do, some don't. This is not a problem during boot but only if you want to use Flash after using SD. The solution was to make sure that the Flash could still drive the line by inserting a series resistor in the SD's Data Out (MISO).

It is important that this detail is captured somewhere in the P2 documentation. This resistor is one of those little things that could cause a problem for people who don't realize it is required in order to reliably use both SPI Flash and SD together with the P2. I don't think it is currently covered anywhere apart from being mentioned once or twice in the forums. New users and anyone else who has forgotten about it may not automatically include this and then stumble into a problem when reading Flash after SD. They'd then have no idea why things stop working without debugging HW, so it really needs to be included somewhere in the document, probably in the Boot Process section which apparently needed more editing anyway according to its title.

Peter Jakacki

@rogloh - there are so many things I've wanted to be able to add to Chip's documentation but even if I had edit permissions I'd be reluctant to mess with his documentation. At the very very least I'd fix up a cover page and a table of contents, perhaps moving sections around and giving them headers etc. I know I did the pinout artwork originally for the unofficial datasheet, and then added to the front page of the document, but while it was a good placeholder at the time, it needs to go into a hardware description section.

It would be good however if that document or somewhere had links to contributed documentation.

btw, while it has been proven that software sequences can convince the SD card to release its data out signal, this is not always guaranteed either, hence the simple just-in-case resistor hack.

@"Duane Degn" - If you (and anyone else) are including USB serial, please consider using the EFM8UB3 chip in QFN20 or QSOP24 packages for this instead of the usual and limited FT232 chips. The bonus is that it can give you a clean RUN reset signal if you use a pull-down on the RESn line and it can automatically disable SD and Flash boot when loading the P2 serially. Also it ignores DTR transitions that aren't load pulses and also adds a smart reset button feature as well as brown-out (and "brown-in") if you use a pull-down for RESn which forces the P2 into reset unless there is a valid RUN signal. You can load the firmware via the USB serial with a simple loader from the PC.
This chip has been tested to work reliably up to 8Mbd in TAQOZ which has proven to be a more punishing test than any of the more predictable echo tests.

If you interface to it via I2C (I use P57 and P56) then besides the 1.8V monitoring that I use, I'm also adding a 'EEPROM" feature to it for non-volatile and persistent data apart from Flash and SD. There's a 128-bit UUID that's also usable.

Duane Degn

Thanks for all the information guys.
I can't say it's all clear to me yet but your replies have certainly helped.

Thanks for the suggestion to use the EFM8UB3 chips. I'll look into this possibility.