This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SD Card Initialization Failing with MSP-FET Connected, works without

Other Parts Discussed in Thread: MSP-FET, MSP430FR5969

First off, my setup.

IDE/compiler:  IAR EW430 6.50.1
Programmer: MSP-FET   (Jtag speed set to Medium in IAR, also have tried with Fast)
Micro: MSP430FR5969
SD Card:  Kingston microSD 16GB SDHC as well as 64GB and 1GB cards

I am trying to integrate Chan's FatFS on the MSP430FR5969 designed into a custom PCB.  I am able to initialize the SD card (put it into Idle State, then put it into run mode).  The issue I am having is when I have the MSP-FET connected, I have three problems:

  1.   It takes about 1.3 seconds for the SD card to go into run mode (it should take hundreds of milliseconds)
  2.  The data received from the SD Card indicates a SDSC, when the card is actually an SDHC
  3. Once initialized, the SD Card returns an invalid command to a read block request

I post this here because when I remove the MSP-FET, the SD card:

  1. Initializes in 0.14 seconds
  2. Reports back as SDHC
  3. Allows Block Request commands

I'm wondering if this has to do with clocking from the MSP-FET, or some setting that I can change (hopefully).  It's going to be difficult to debug from here out if I have to disconnect my debug tool every time.

Thanks for the help in advance!
-MC

  • Hi MC,

    May I ask what the frequency of your DCO is as well as the SPI clock source and speed? Are you using DMA to transfer SPI bits? Debugging with a FET tool requires additional clock cycles that appear to be interfering with your SPI communication (bottleneck situation). If you could increase the DCO, decrease the SPI clock frequency, or source the SPI with a 24 MHz HFXT then I would recommend doing so to decrease the burden on the CPU. This could be only for debugging purposes, you could revert to your original settings once the application is ready for production.

    Regards,
    Ryan
  • Hi Ryan,

    Thanks for the response.  I had been running the DCO at 8MHz with a 250KHz SPI Clock.  I tried using the HFXT with an 8MHz crystal, same problem.  Next I tried increasing the DCO to 24MHz, and decreasing the SPI to 100kHz, but I'm still seeing the same issue.  I don't have a 24MHz crystal here, so I'll order one and try that next.  

    Regards,

    Matt

  • Hello Matt,

    The highest DCO frequency available on the MSP430FR5969 is 16 MHZ, but I would have expected some slight improvement with that and a decreased SPI clock. Can you present any oscilloscope or logic analyzer shots of the SPI data during both states to demonstrate your issue?

    Regards,
    Ryan
  • Hi Ryan,

    First off, here is the Clock setup (in case you see some error):

    /* Configure the clock                */
      /* DCO running at 16MHz               */
      /* HFXT is 8MHz                       */
      /* LFXT is 32.768kHz                  */
      /* ACLK running on LFXT 32768Hz       */
      /* SMCLK running on HFXT 8MHz      */
      /* MCLK running on DCOCLK, 16/2MHz       */
      /* LFXT Driver on low power           */
      
      /* Add wait states to FRAM to keep at 8MHz */
      FRCTL0 = FRCTLPW | NWAITS_2;
      
      /* Unlock CS Register */
      CSCTL0_H = CSKEY >> 8;                    
      CSCTL1 = DCOFSEL_4 | DCORSEL;                       // Set DCO to 8MHz
      CSCTL2 = SELA__LFXTCLK | SELS__HFXTCLK | SELM__DCOCLK;
      CSCTL3 = DIVA__1 | DIVS__1 | DIVM__1;     // Set all dividers to 1
      CSCTL4 |= LFXTDRIVE_3 | HFXTDRIVE_3;
      CSCTL4 &= ~(LFXTOFF | HFXTOFF);
      
      do
      {
        CSCTL5 &= ~(LFXTOFFG | HFXTOFFG);       // Clear XT1 and XT2 fault flag
        SFRIFG1 &= ~OFIFG;
      }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag
      CSCTL0_H = 0;                             // Lock CS registers

    Next is my SPI setup:

    /* Put UCA0 In Reset */
          UCA0CTLW0 = UCSWRST;
          
          /* Put UCA0 in 3-Pin, 8-Bit, Synchronous SPI Master Mode */
          /* No Modulation */
          UCA0CTLW0 |= UCMSB | UCMST | UCMODE_0 | UCSYNC | UCCKPH;
          UCA0CTLW0 |= UCSSEL__SMCLK;
          UCA0BR0 = 0x50;
          UCA0BR1 = 0;
          UCA0MCTLW = 0;
          
          /* Initialize USCI State Machine */
          UCA0CTLW0 &= ~UCSWRST;
          UCA0IE |= UCTXIE | UCRXIE;
    
    

    Now the screenshots.

    First set is one sample with the debugger attached.  There is a capture of the full sample, then the OCR request (Data following MOSI 0x7A should be MISO 0xC0, not 0x80), finally a capture of a block read request (MOSI 0x51 should be followed with a MISO 0x00)

    Second set is one sample with the debugger removed.  This time I receive a 0xC0 for the first byte of the OCR, and a 0x00 for the Read Request.

    Interesting note: There has been two times when I have changed the clock frequency that the SD card has initialized correctly with the debugger attached.  It was immediately after downloading, but when I restart the program from the debugger I cannot recreate.  nor does power cycling and re-downloading.  

    Thanks for the help.

    -Matt

  • Hi MAtt,

    Out of curiosity, why the increased wait states? If you are only getting up to 8 MHz then I'd recommend using no wait states, a max of NWAITS_1 for 16 MHz. But I don't think this will affect your issue and the rest of your initialization code looks fine.

    In the third screenshot, it can make sense that the debugger overloading the CPU could cause a 9-bit delay (0x0A to 0x05 shifted one byte over) on the MOSI line, but the 0xC0 OCR register value with no debugger vs 0x80 with debugger is another clue that calls the system's power supply capabilities into question. When the debugger is connected, the card power up status bit is low to indicate that the card has not finished the power up routine. This suggests either an invalid voltage range or the need to wait longer for the card to properly power up.

    Is the debugger providing power to the system when connected? I'm thinking that it isn't and that JTAG pin 4 is connected so that the FET tool uses the system's voltage level from a power supply, but the FET tool may be overloading the power supply. Your notes at the end of the last post are ever-more a reason to investigate the Vcc lines and see if there is a difference between the two operating states. Maybe with the debugger connected a longer delay is required to get the SD card's power up routine completed?

    Regards,
    Ryan
  • You, sir, win the prize...

    There was a FET switching power to the SD card. I jumpered power over it, and now it's all working with the debugger. In fact, it initializes in just over 10ms. Now I'll be able to enjoy the weekend.

    Thank you for all the assistance.
    -Matt
  • P.S. The increased wait states were a remnant of some trial and error with changing the clock freq. I had set it for Wait_1 for 16Mhz, then upped it just to see what would happen. Thanks for pointing that out.

**Attention** This is a public forum