Shop OBEX P1 Docs P2 Docs Learn Events
Can I access a SD card when a P2 Evalboard booted from the flash memory? — Parallax Forums

Can I access a SD card when a P2 Evalboard booted from the flash memory?

I tested booting a P2 eval board from a SD card (and it works :) )

As I can see on a schematic, to boot from SD I have to disconnect the flash CS which means I cannot access the flash when I boot P2 Eval from a SD card.

What if the P2 Eval board boots from the flash with a SD card inserted? (tested: it boots and the "flash" switch selects a boot source)

Can a P2 program boot from flash and then access a SD card or there are conflicts on pins which prevent accessing both devices in one configuration?

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2021-02-11 11:02

    I do this all the time. I have disabled SD boot so that only Flash boot works and then I just access the SD as normal. There can be a problem however if the SD data out is nor released properly since it is not totally dependent on the SD CS. However that would only affect the Flash and I have a 220R in series with SD data in case it doesn't release just to make sure. But we tested this all out thoroughly before we had P2 silicon and assured Chip that mixing the Flash and SD on the same 4 pins would work.

  • Cluso99Cluso99 Posts: 18,069

    As Peter said, not a problem.
    On P1 I share the sd card with the SRAM where I run Catalina C and also Z80 RAM emulation. No problems!

  • So you built a 64 GPIO microcontroller that typically uses pins in groups of 8 and you skimped on one chip select pin?

    Mike

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2021-02-11 22:26

    @iseries said:
    So you built a 64 GPIO microcontroller that typically uses pins in groups of 8 and you skimped on one chip select pin?

    Mike

    If we wanted to make it easier for ourselves we would have had 6 I/O for QSPI Flash (just in case) and at least 4 I/O for SD although some might want 4-bit mode etc. As is always the case, no matter how many I/O the chip comes with, somebody will want to use n+1. Some chips used to come with full JTAG support but some people want more I/O, less JTAG, so now they come with SWD etc (just my opinion there).

    Chip's booter only handled serial and Flash over 6 I/O total, but we wanted to add SD as well with TAQOZ and the debugger, but IIRC Chip didn't want to dedicate any more pins just for booting, and we felt the same way too since we design hardware for commercial use and know that too often we run our of I/O. Understanding how the SPI bus works and knowing that using the clock of one as the chip select for the other, and vice-versa, would work, then why wouldn't we do it that way? That's called working smart.

    All too often on the interwebs there are "designs" that have all this extra crud, "just to be safe", when in fact it's just that they don't understand stuff well enough. I know I have seen endless designs use a pullup on the SD chip select, but I use a weak pull-down for good reason.

    So, we could have used extra I/O for booting "just to be safe" but this would limit P2 designs, not enhance it.

  • So adding to this discussion. I am using the FSRW for the P2 Edge, SD card software app (29 May 2020) . Do I need the standard 10K pull up resistors on all 4 of the SD card i/o control lines?

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2021-02-12 00:14

    @PropGuy2 said:
    So adding to this discussion. I am using the FSRW for the P2 Edge, SD card software app (29 May 2020) . Do I need the standard 10K pull up resistors on all 4 of the SD card i/o control lines?

    No, they are not "standard" at all for an SD card. I don't use any pull-ups at all on my SD card because normally the CS is an output from the micro and the card itself has an internal pull-up, which is how we can detect that a card is inserted without having to use an I/O for the card detect switch. BTW, that internal resistor has always been in the SD card spec but the interweb people don't read that. Now SCK and MOSI are outputs and don't need pull-ups while MISO is an input and would be the only one you might need a pull-up on. But that is easy enough to hold this pin as a low output until the card is detected anyway.

    I'm not sure if FSRW uses the card's pull-up to detect it though. This was a common design oversight in most drivers.

    The note in Table 3.1 of the SD Card Association's "Physical Layer Simplified Specification Ver8.00" says this:

    3) At power up this line has a 50KOhm pull up enabled in the card. This resistor serves two functions Card detection and
    Mode Selection. For Mode Selection, the host can drive the line high or let it be pulled high to select SD mode. If the host
    wants to select SPI mode it should drive the line low. For Card detection, the host detects that the line is pulled high.

    Hence my reason for a 1M pull-down on the chip select since I simply read in a low for "no card" or a high for "card detected". The pull-down saves having to do a more complicated float test which also depends upon the clock speed anyway.

  • AribaAriba Posts: 2,682

    There is a built in 150k resistor in every pin, which you can use to detect if the SD card is connected, no external 1M needed.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2021-02-12 01:42

    @Ariba said:
    There is a built in 150k resistor in every pin, which you can use to detect if the SD card is connected, no external 1M needed.

    Absolutely true except the card's internal pull-up is 50k'ish. It's the ish part (of both) that I allow for an external pull-down (even if I don't use it) although the P2 threshold is 50% and would work. Perhaps all the drivers should enable that pull-down then as well as a pull-up on MISO (or make it low).

Sign In or Register to comment.