FatFS SPI and 8Gb SD card ?

[antonius]

Posted on January 24, 2016 at 09:48

Guys,

Can I use 8Gb SDcard with FATFs? it's formatted FAT32 Here's the debug message from UART....it seemed that it's initialized properly but can not read the file system...

. à. f_mount ff.c find_volume! 
....-é÷O­õ}F.�?OôzzOð. TFSF#''v¡}HÆø.’get_LDNUMBER Line2136
.ø . -éøO L!MOôzx®òžgà!(Fü÷€ù.(ù�?''1F(Fü÷~ù.''1F(Fü÷yùCF ''!FHý÷¨ù 4¼BæÙ.''F_OPEN BEGIN Line2447 
....ø . FA_FA_CREATE NEW Line2450 
...CREATE get_LDNUMBER Line2136
.ø . -éøO L!MOôzx®òžgà!(Fü÷€ù.(ù�?''1F(Fü÷~ù.''1F(Fü÷yùCF ''!FHý÷¨ù 4¼BæÙ.''Find_volume Line2195 
.ø . FR_INVALID_DRIVE Line 2196
FR_INVALID_DRIVE Line 2196
....à. FR_NOT_ENABLED LineFR_NOT_ENABLED Line 2200
..find_volume ff.c disk_initiDISK INITIALIZE SUCCEDED! 
....ø . DISK INITIALIZE FINISHED! 
...0´FIë€.F@hi F0¼G..P. pµFDISK INITIALIZE FINISHED! 
...0´FIë€.F@hi F0¼G..P. pµF
F ¹±è�? p½ p½HÀx..ÔROô.v,Ffind_volume ff.c disk_initialize LINE 2218! 
..FR_OK Line 2210

Test function :

void test_write()
{
UINT bw,size;
FRESULT fr; /* FatFs return code */
char line[82],size_char; /* Line buffer */
unsigned char result;
f_mount(&FatFs, ''0'', 0);
if (f_open(&Fil, ''newfile.txt'', FA_WRITE | FA_CREATE_ALWAYS) == FR_OK) 
{
HAL_UART_Transmit(&huart1, ''FOPEN \n\r'', 15, 1000); // As a pointer, with a length
f_write(&Fil, ''Test write line1 !\r\n'', 17, &bw); /* Write data to the file */
f_write(&Fil, ''Next line test\r\n'', 16, &bw); /* Write data to the file */
HAL_UART_Transmit(&huart1, ''FWRITE \n\r'', 15, 1000); // As a pointer, with a length 
HAL_GPIO_WritePin(GPIOE, GPIO_PIN_6 , 0 );
HAL_Delay(5000);
HAL_GPIO_WritePin(GPIOE, GPIO_PIN_6 , 1 );
f_close(&Fil); /* Close the file */
HAL_UART_Transmit(&huart1, ''FCLOSE \n\r'', 15, 1000); // As a pointer, with a length
}
} 

Any clues ? thanks

[Tesla DeLorean]

Posted on January 24, 2016 at 14:40

Any clues ?

 

Really not able to draw any correlation between the diagnostic output, and that of the supplied code.

I would start by debugging and testing the underlying IO code, only once I had done that would I test it at the FatFs level, and I would start there with Read tests as they are typically non-destructive in nature. If all that worked I'd look a Write tests.

[antonius]

Posted on January 24, 2016 at 15:29

Does it matter if I replace all of

const BYTE *p to BYTE *p ?

Because if I use const BYTE *p, I can't compile it, but if I change it, it can be compiled well...

Ok, I'll give a test from reading a file and IO test from SPI level,

Is that what you suggested ?

I can see disk initialized is passed from the message....I'll test with something else,

the code is working fine with atmega128, I want to port it to STM32F107....

Thanks

[Tesla DeLorean]

Posted on January 24, 2016 at 17:44

Yes, I'm suggesting you focus on the low level code, because if that doesn't work properly then the high level stuff surely isn't going to work either.

I'm pretty sure you are not the author of the AVR code, that it works there is somewhat irrelevant if the SPI interactions you create on the STM32 are different. You're basically copying code you don't fully understand, onto another platform you don't understand. It's not entirely surprising things do not work as expected.

You need to focus on how the SPI interactions work on your AVR platform, at a signals level, and then compare that with what you've created on the STM32 side. Where your implementation doesn't work, you need to look at how the interaction and responses differ. If you can't glean this from the data, then you'll need a scope or logic analyzer to look at the signals directly.

[antonius]

Posted on January 24, 2016 at 21:05

I'm sure as well that ST is not the author of Chan FATFs too,that's what I've been thinking, on the low level, since from Chan FATFs, it's using const *byte....

but in here I can't compile it, it's not compatible with HAL_SPI_Transmit which is uint8.... I'll see with logic analyzer, what it's doing from the beginning of SPI2...

Yes I'm basically copying between STM32 and AVR, but not completely, because if it's completely copying, I will not get the trouble finding out why is not compatible, right ? :)

Anyway, I've checked with my logic analyzer previously to send a simple 0x00, 0x01 at SPI2, and it works, but I haven't seen it sending the function I've ported on diskio.c....

There's another question between diskio.c and user_diskio.c.....Can I ignore user_diskio.c...or anyone from ST can tell me what is this file for to make me understand easier ?

So far I ported all my codes from my AVR inside diskio.c, when I call f_mount, I can see from UART, it's doing the job....

Thanks

 

I'm pretty sure you are not the author of the AVR code, that it works there is somewhat irrelevant if the SPI interactions you create on the STM32 are different.

[antonius]

Posted on January 24, 2016 at 21:32

I will start from these functions :

 

xchg_spi

 

 

xmit_spi_multi

 

 

rcvr_spi_multi

that's what I've been trying to understand between const * byte and *byte, and then must be entered into

HAL_StatusTypeDef HAL_SPI_Transmit(SPI_HandleTypeDef *hspi,  uint8_t *pData, uint16_t Size, uint32_t Timeout)

I can easy call those function into my main(), see what happen for a test...

Anyway, thanks a lot for your suggestion, I'll keep on posting the progress

[antonius]

Posted on January 25, 2016 at 13:04

I've tested xmit_spi_multi and it did the job properly,

void test_function()
{
//test function from diskio.c here
uint8_t data_test[8] = { 0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07 };
xmit_spi_multi (data_test,8);
}
//test only
void xmit_spi_multi (
BYTE *p, /* Data block to be sent */
UINT cnt 
)
{
while(HAL_SPI_GetState(&hspi2) != HAL_SPI_STATE_READY); 
HAL_SPI_Transmit(&hspi2,p,cnt,100);
}