FatFS on FR5969?

[madvoid 1]

Hi All,

 

I'm attempting to get an SD card working with the MSP430FR5969 (launchpad) and FatFS but I'm having a difficult time. Two questions:

 

1. Is it possible to get FatFS working with the MSP430? When I did a search of these forums I mostly saw PetitFat being used with MSP430s. Ultimately, PetitFat would be okay but I would prefer FatFS.

2. Has anyone gotten either PetitFat or FatFS working with the MSP430FR5969? If so, would you be willing to share your code or knowledge regarding it?

 

Thank you in advance for any help,

Nipun

[greeeg 460]

I have implemented fatFS on the MSP430F5438. A lot of people would use the petit version due to a lot of MSPs lacking Flash for the full version. The FR5969 should work.

 

FatFS is a large library. Notably for MSP support some low level SPI driver need to be made. (should be very similar to petit fatFS)

 

Are you having any particular issues?

[madvoid 1]

Hi greeeg,

 

Thank you for your quick reply! I'll explain what my problem is below, you may have some insight into what is going wrong.

 

A few months ago I got FatFS working on the TI Tiva launchpad thanks to code that I found online. Now that I switched to the MSP430FR5969, I thought I would go through and change the SPI drivers as you said. All the platform specific code should be in diskio.c, visible here. I also wrote the main function which mounts the SD Card and attempts to open a text file and append some text to it. You can view it here.

 

My problem is this: The main function will mount the SD Card just fine. However, when I try to open the file using f_open, the code hangs via the following path: f_open -> find_volume -> disk_initialize -> send_cmd -> wait_ready -> rcvr_spi. In rcvr_spi(), the code hangs on line 110:

while(!(UCA1IFG & UCRXIFG));    // Wait for RX buffer

Since it was having trouble simply receiving, I thought the issue might be hardware. However, the card works fine when plugged into my computer, and it is also the same card I used when testing with the Tiva launchpad. I also double checked my connections, which are as follows:

SPI_SOMI: P2.6
SPI_SIMO: P2.5
SPI_CLK: P2.4
SPI_CS: P3.4

These should connect the SD card to USCIA1 on the MSP430FR5969. Do you think there is a problem with sending the initial clock train that should put it into SPI mode? That was the one thing I could think of but I'm not sure.

 

Thanks again for your help, I appreciate it greatly!

 

- NG 

[greeeg 460]

Hey madvoid,

 

Glad to see you have made genuine efforts to get this to work.

I added a vanilla fatFS to a FR5969 project, added your diskio.c and tried calling disk_initialize. As per you're experience the debugger reported it hanging.

 

hooking up my scope I noticed no SPI activity.

 

I noticed your USCIA1 init code.

//Initialize USCI_A1 for SPI Master operation
UCA1CTLW0 |= UCSWRST; //Put state machine in reset
UCA1CTLW0 = UCCKPL | UCMSB | UCMST | UCMODE_0 | UCSYNC; //3-pin, 8-bit SPI master
//Clock polarity select - The inactive state is high
//MSB first
UCA1CTLW0 = UCSWRST | UCSSEL_2; //Use SMCLK, keep RESET
UCA1BR0 = 3; //Initial SPI clock must be <400kHz
UCA1BR1 = 0; //f_UCxCLK = 1MHz/(3+1) = 250kHz
UCA1CTLW0 &= ~UCSWRST; //Release USCI state machine
UCA1IFG &= ~UCRXIFG;

Notice the third line here actually clears the SWRST bit in the UCA1CTLW0 register.

 

I adjusted your code slightly

//Initialize USCI_A1 for SPI Master operation
UCA1CTLW0 = UCSWRST; //Put state machine in reset
UCA1CTLW0 |= UCCKPL | UCMSB | UCMST | UCMODE_0 | UCSYNC; //3-pin, 8-bit SPI master
//Clock polarity select - The inactive state is high
//MSB first
UCA1CTLW0 |= UCSSEL_2; //Use SMCLK, keep RESET
UCA1BR0 = 3; //Initial SPI clock must be <400kHz
UCA1BR1 = 0; //f_UCxCLK = 1MHz/(3+1) = 250kHz
UCA1CTLW0 &= ~UCSWRST; //Release USCI state machine
UCA1IFG &= ~UCRXIFG;

and no more hangs. Hopefully this will work with your hardware.

[madvoid 1]

Hi Greeeg,

 

That did the trick! Thank you very much, I don't know if I would have caught that in a million years! Quick question to help me understand your fix: Does setting the UCSWRST bit reset the USCI module, even if it has already been set?

 

To anyone else reading this thread, I've updated the code in my Github which means the links in my original reply to Greeeg now point to the correct version.

 

Thanks again!

 

- NG 

[greeeg 460]

From the family datahseet SLAU367e

 

 

Configuring and reconfiguring the eUSCI module should be done when UCSWRST is set to avoid unpredictable behavior.

 

From my understanding the module is held in reset WHILE the bit is high. Keeping the internal state machine reset aswell as clearing interrupts and other flags.

If the bit goes low, then the internal state likely moves from reset state into a state ready to accept data. If the registers have not been setup when this happens then you can get some strange unpredictable errors.

 

I spotted it because I have fallen victim to it before.

 

However it could  have been a bigger issue of the register not being setup at all. If we revist your original code

UCA1CTLW0 = UCCKPL | UCMSB | UCMST | UCMODE_0 | UCSYNC; //3-pin, 8-bit SPI master
UCA1CTLW0 = UCSWRST | UCSSEL_2; //Use SMCLK, keep RESET

All the bits set on the first line here are discarded when the next line executes.

 

Glad I could help.

[madvoid 1]

Ah, that makes sense. Thanks again!