• AVR Freaks

Hot!DSPIC33EP128GS702 - SD Card MOSI data line?

Author
arigead
Super Member
  • Total Posts : 445
  • Reward points : 0
  • Joined: 2011/02/07 06:58:31
  • Location: 0
  • Status: offline
2020/09/27 06:19:37 (permalink)
0

DSPIC33EP128GS702 - SD Card MOSI data line?

I'm a bit confused by what I'm getting out of the SPI interface from a dsPIC33EP128GS702 to an SD Card. There are pull up resistors from both the MOSI and MISO to 3v3, (circuit like [1]), so I'd expect the both lines to idle high. However when I look at the output on the logic analyser It's showing the MOSI as Idle low. I thought I might have a mistake in the hardware so I set the pin to a logic high, and didn't intialise the SPI Interface. That worked as expected with the pin going to 3v3, so no hardware issue.
 
So then I decided that it must be in the SPI Peripheral and, as I've no SD Card in the slot, I swapped the MOSI and MISO pins in my SPI configuration. So again with the swapped GPIO pin the MOSI was again low. I checked with a DMM and it's sitting at 1.17V. Maybe I should use a different SPI peripheral channel.
 
Given that issue, which may not be an issue at all, I have comms sort of working to the SD Card. I send the reset command and get back a response of 0x01, so the SD Card has gone into Idle mode. After I get that response I send a command to set the block size of 512 to the SD Card the response to this is two bytes 0xc0 and 0x7f. According to all I've read the first bit of the response from the SD Card has to be zero. So 0xc0 is wrong or miss-aligned and the response is probably 0x01 again.
 
I've not seen anything about this in the documentation I've found. Maybe it's not a problem in checking the ACK from a command, where you know you have a leading zero in the ack byte, but when it comes to reading data back from the card any missalignment will be a problem. I'll attach a screen shot.
 
 
[1] http://alumni.cs.ucr.edu/...card_appnote_foust.pdf

Attached Image(s)

#1

8 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28671
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/09/27 17:09:26 (permalink)
    5 (1)
    MOSI will never float, so the pullup won't have any effect on it.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    Aussie Susan
    Super Member
    • Total Posts : 3769
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/09/27 19:45:49 (permalink)
    2 (1)
    Please be careful with your terminology. 
    For example you refer to the 'first bit' but I think you mean the first part of the response. However, given your problem might be a mis-aligned read, then bits are most certainly relevant to the overall answer but your use of the word here is misleading.
    Also you talk abut the 'ACK from a command': when I see that I immediately think of the ACK signal in the I2C protocol where a lot of users have issues. I think you mean the acknowledgement of the command at the start of the returned byte sequence, but it took me a few moments and several reading to work this out.
    If the mis-alignment you refer to is at the bit level and only on the MISO signal, then check the SMP setting on the SPI registers to make sure that you are sampling on the correct clock transition and when the data is stable.
    Susan
    #3
    arigead
    Super Member
    • Total Posts : 445
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/09/28 04:15:48 (permalink)
    0
    From [1]

    The SD card responds to each command frame with a response. Every command has an expected response type. The type of response used for a particular command depends only on the command number, not on the content of the frame. Three response types are defined for SPI mode:R1, R2, and R3. The bit field designations are described in Tables 3, 4, and 5, respectively.
    Byte 1:
    Bit Meaning : 7 Start Bit, Always 0
                           6 Parameter Error
                          5 Address Error
                          4 Erase Sequence Error
                          3 CRC Error
                          2 Illegal Command
                          1Erase Reset
                           0 In Idle State

     
    Sorry I should not have used the term acknowledgement, but response. So as stated in the info above the SD Card responds to each command with a response. The first bit of which is zero, (Bit 7) Hence when I say that I'm getting a response of 0xC0 that suggests that the response is misaligned, given that the first bit should be zero. I'm asking about this because whilst when I'm waiting for a response from a command issued I know that the first bit of the response will be zero when I'm reading data from the SD Card 0xC0 would be valid data byte and I've no idea how or if it is misaligned.
     
     
    [1] http://alumni.cs.ucr.edu/...card_appnote_foust.pdf
    post edited by arigead - 2020/09/28 04:21:26
    #4
    du00000001
    Just Some Member
    • Total Posts : 3980
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/09/28 09:40:48 (permalink)
    0
    @arigead
    1. Your plot (initial post) shows a byte transfer that shouldn't have taken place (resp. isn't filled with data from the slave).
    2. Could it be the slave would require a bit more time prior being "asked" for a response to the command? Might be so...
    3. Your reference is not error-free: the flow diagram shown a sequence that's not logical (CMD41 followed by CMD55) - the correct order (CMD55 followed by CMD41) is to be found in the source code provided. Might be the reference has more errors to provide.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #5
    LdB_ECM
    Super Member
    • Total Posts : 454
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/09/28 17:20:44 (permalink)
    0
    duo is correct throw the reference away the sequence given is illegal.
     
    Try something like
    https://openlabpro.com/gu...trollers-with-sd-card/
    #6
    arigead
    Super Member
    • Total Posts : 445
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/10/01 04:08:03 (permalink)
    4 (1)
    Thank you for the good advice, ("throw the reference away"). I'm still struggling with this but have moved to the actual SD Card standard document. It differs from the document you sent, [1], but that might be down to my misunderstanding things.
    I'm currently sending a 'Reset/CMD0' to the card and getting a good response 0x01. I then send a CMD8 with the voltage request for 2.7 - 3.6V. I'm operating at 3v3 so that should all be good. The reference sent [1] suggests the response to the CMD8 should be either 0x01 or 0x05 whereas the SD Card standard has an R7 response, 48 bits. In either case the leading bits of the response should be zeros and that's not what I'm seeing. Again I'm getting A response of 0xC1 0x7F...
     
    If I was only getting one leading '1' bit I might assume that I've got the SPI Bus mode or SMP incorrect, but since I'm getting 0xc1 two MSbits are wrong. That and the fact that the CMD0 command went through fine, and I don't think it's SPI Bus mode, or SMP setting. So it's the SD protocol which I have wrong. But as far as I can see CMD0 followed by CMD8 is good and the response, to CMD8, whether R1 or R7, has to have MSbits of zero.
     
    Trying to make progress I compiled the example in the Microchip MLA but that is constantly sending a CMD0 to the SD card and isn't happy with the response from the SD Card of 0x01 so keeps re-transmitting the CMD0. So I don't think that the MLA SD Card example is any use either. Perhaps the 'comprehensive_sd_card_demo' choice was the wrong one.
     
     
    [1] https://openlabpro.com/gu...trollers-with-sd-card/
    #7
    arigead
    Super Member
    • Total Posts : 445
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/10/01 04:42:08 (permalink)
    0
    Aragh!!! Found someone with a problem on stack overflow, [1], and they added extra 'dummy' byte write at the tail end of the previous command. I'd tried delays after the CMD0 but what harm. Now getting a response of 0x09 to the CMD8. That's more like it! OK the CRC was wrong, but i just filled it is as 0x95.
    So I've got a second command working, that only took days, or what felt like forever. Now for a third command to the SD Card. Hopefully I'm getting the hang of this.
     
    [1] https://stackoverflow.com...-sd-card-in-spi-issues
    #8
    du00000001
    Just Some Member
    • Total Posts : 3980
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: DSPIC33EP128GS702 - SD Card MOSI data line? 2020/10/01 05:46:55 (permalink)
    0
    Transmitting a dummy byte might turn out to be counter-productive if you attach a card reacting (way) faster than your current one.
    Your reference already gives the hint: wait until MISO becomes low prior starting the cycle to request the response!
    (See my prior post (#5) about waiting not long enough.)
     
    This "wait until MISO goes low" might apply to each and every command sequence.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    Jump to:
    © 2020 APG vNext Commercial Version 4.5