FAT Keeps Returning 255

[rocket200]

So I just got Flowcode V5 for AVR, and I'm loving it so far! I have one problem though. I am trying to init a FAT16 SD card with the flowcode 5 FAT component in hardware mode. For some reason it always returns a 255, indicating no card, even though there is one. I got the SD card to communicate correctly in flowcode 4, but for some reason it doesn't work in 5. Please help! Thanks!

[Jordy101091]

Hi rocket200

I dont think FAT16 Format will work with flowcode try to format your card as FAT and try it again.
Also it could be that your code is not 100% correct so if you can upload your code so I can take a look.

If everything works fine can you try to create a file and add some text to it because I'm having trouble to get this to work.

Let me know how you moving along

Regards Jordy

[rocket200]

Hi rocket200

I dont think FAT16 Format will work with flowcode try to format your card as FAT and try it again.
Also it could be that your code is not 100% correct so if you can upload your code so I can take a look.

If everything works fine can you try to create a file and add some text to it because I'm having trouble to get this to work.

Let me know how you moving along

Regards Jordy

Thanks for the reply! I'm pretty sure FAT is FAT16. I attached the C code output, and the Flowcode 5 project file. Thanks again!

[Jordy101091]

Oke a quick llok at your C code because I use Flowcode for PIC not AVR so, tells me that you have the init part not correctly,
this is what you need to do:



I cannot give you this code because it will not load into your version of flowcode.

You need to make a variable that will hold the retval of the INIT macro "FAT_InitOK" before you continue to the Init macro this variable needs to be greater then 0 thus 1

char Init_Fat ( void )

Initialises the card and starts up the FAT driver, points the directory to root.
Current directory is specified as Root.


Retval = 0 - Init OK
Retval > 0 - Init Not OK

next you enter a loop that runs the Init macro for one second for ever until this macro returns a 0 and Init is OK.

Try this hope it works for you,

Regards Jordy

[rocket200]

Oke a quick llok at your C code because I use Flowcode for PIC not AVR so, tells me that you have the init part not correctly,
this is what you need to do:



I cannot give you this code because it will not load into your version of flowcode.

You need to make a variable that will hold the retval of the INIT macro "FAT_InitOK" before you continue to the Init macro this variable needs to be greater then 0 thus 1

char Init_Fat ( void )

Initialises the card and starts up the FAT driver, points the directory to root.
Current directory is specified as Root.


Retval = 0 - Init OK
Retval > 0 - Init Not OK

next you enter a loop that runs the Init macro for one second for ever until this macro returns a 0 and Init is OK.

Try this hope it works for you,

Regards Jordy

I tried your set up, but it is still returning a 255. Very odd. Maybe the guys over at MM will have an idea why this is happening.

[Jordy101091]

what type of microcontroller are you using?
Have you tryed a different SD Card?

maybe that card wont work with Flowcode.

Regards Jordy

[rocket200]

what type of microcontroller are you using?
Have you tryed a different SD Card?

maybe that card wont work with Flowcode.

Regards Jordy

I am using an ATmega328p. And yes, I have tried multiple cards. Same result. I don't think it is the card because all SD cards I have tried worked with the Flowcode 4 FAT16 component. It is something about the Flowcode 5 FAT component that is causing the SD card to not work.

[rocket200]

Could somebody over at Matrix Multimedia possibly help me? I need to interface the SD card for a project that has a deadline coming up soon!

Thanks!

[Benj]

Hello,

Have you tried in software mode at all to see if that helps? I don't have that chip available here for testing but I can try with a mega324P.

[rocket200]

Hello,

Have you tried in software mode at all to see if that helps? I don't have that chip available here for testing but I can try with a mega324P.

Hi,

I have tried software mode. First it returns 255, then it returns 254 a second later. If you could test with the 324P, that would be awesome! I'm sure the results will be pretty similar between the two chips.

[rocket200]

Hello,

Have you tried in software mode at all to see if that helps? I don't have that chip available here for testing but I can try with a mega324P.

Is there more information that you need me to provide so we can get this fixed?

[Benj]

I'm going to have a dig in this weekend with the FAT component on PIC, AVR, ARM and dsPIC and see if I can get to the bottom of the issues.

I'll let you know how I get on. Hopefully with some good news.

[rocket200]

I'm going to have a dig in this weekend with the FAT component on PIC, AVR, ARM and dsPIC and see if I can get to the bottom of the issues.

I'll let you know how I get on. Hopefully with some good news.

Fantastic!! I have a quick question, has the speed of the SPI transactions for the Flowcode 5 FAT component increased since V4?

[Benj]

Hello.

In the move from v4 to v5 we added the CAL (code abstraction layer). Nothing else should have changed with the component but we have recently added some SDHC changes and these seem to be causing issues. I am still looking into this issue so hopefully I will be back shortly with some better news.

[rocket200]

Hello.

In the move from v4 to v5 we added the CAL (code abstraction layer). Nothing else should have changed with the component but we have recently added some SDHC changes and these seem to be causing issues. I am still looking into this issue so hopefully I will be back shortly with some better news.

Awesome! Do you have any plans to increase the speed in the future? I am making an audio sampler that involves DSP, and the FC 4 FAT component is too slow to use.

Thank you, Ben!

[Benj]

I've currently acheived quite a substantial speed increase on standard 8-bit PIC so i'm hoping dsPIC should really fly.

The only issue now is that the read / write functions now seem a bit unreliable. I have put some things in place, some of which have worked and hope to post up something a bit more reliable shortly.

SDHC fully functional 16GB card working well.

Project sounds great, one note would be to make sure your not using the append data to file function in your program to ensure it runs as fast as possible. The v5 examples files should show you slow and fast write methods if you've not already seen them.

[rocket200]

I've currently acheived quite a substantial speed increase on standard 8-bit PIC so i'm hoping dsPIC should really fly.

The only issue now is that the read / write functions now seem a bit unreliable. I have put some things in place, some of which have worked and hope to post up something a bit more reliable shortly.

SDHC fully functional 16GB card working well.

Project sounds great, one note would be to make sure your not using the append data to file function in your program to ensure it runs as fast as possible. The v5 examples files should show you slow and fast write methods if you've not already seen them.

Sounds exciting! I'm actually not using any write functions, just reading from the SD. It's polyphonic so I have to open 12 different WAV files, loop next_sector macro to get to the right sector of the audio file, then fill up a buffer. Even with a large buffer I only have about 20ms to get my audio data together to be sent to the DAC. I'm really hoping the FAT component gets faster someday so I can have less latency by using a smaller buffer! That would be awesome!

[Benj]

Hi Rocket,

I can see that opening several files and streaming from them would be a big strain for the current FAT component as it was designed to only really ever deal with 1 file. Multiple files are possible but as the files get bigger the runtime gets exponentially slower. I suppose I could create filename arrays and allw you to read / write from multiple files at once meaning you dont have to open and reopen files again and again. This would increase the base amount of memory for the component but I suppose I could make a "Max Files" property in the component properties window to allow for legacy single file support. I will have a play with this when I get a spare minute and see if it's possible.

Another potentially easier method in the meantime would be to use a VB or Python script to convert the 12 files into one file eg interleave each byte so it goes f0, f1, f2, ... , f11, f0, f1, ...
This way you can stream direct from the file without the need for any additional buffering or processing of the data making it significantly faster. If the data is not 1:1 across the 12 files then there might be some clever mechanism to drive the data through. Basically any processing you can do on the files to make it easier for the uC will significantly improve performance.

[rocket200]

Hi Rocket,

I can see that opening several files and streaming from them would be a big strain for the current FAT component as it was designed to only really ever deal with 1 file. Multiple files are possible but as the files get bigger the runtime gets exponentially slower. I suppose I could create filename arrays and allw you to read / write from multiple files at once meaning you dont have to open and reopen files again and again. This would increase the base amount of memory for the component but I suppose I could make a "Max Files" property in the component properties window to allow for legacy single file support. I will have a play with this when I get a spare minute and see if it's possible.

Another potentially easier method in the meantime would be to use a VB or Python script to convert the 12 files into one file eg interleave each byte so it goes f0, f1, f2, ... , f11, f0, f1, ...
This way you can stream direct from the file without the need for any additional buffering or processing of the data making it significantly faster. If the data is not 1:1 across the 12 files then there might be some clever mechanism to drive the data through. Basically any processing you can do on the files to make it easier for the uC will significantly improve performance.

Thank you for being so helpful! I have plenty of memory to spare.

I like the idea of combining the twelve audio files into one! Genius! Maybe when you first turn the device on, it could interleave the 12 audio files before it starts the other processes. There is one problem with this though, what if sample1, sample2, and sample3 are playing, then in the middle of reading the interleaved file, sample4 now needs to play. Sample4 wouldn't be able to be played from the beginning, instead it would play at a part of the audio near the end. This might not be so much of a problem for shorter samples, but it couldn't really work for longer samples.

Thanks again

[Benj]

I have managed to get multiple files to work quite easily so I will add it to the master code base and generate you the AVR version.

This will significantly improve the data speeds when handling multiple files and the new code shouldn't break any existing programs. (fingers crossed)

File Removed Updated Code available below.

[rocket200]

I have managed to get multiple files to work quite easily so I will add it to the master code base and generate you the AVR version.

This will significantly improve the data speeds when handling multiple files and the new code shouldn't break any existing programs. (fingers crossed)

Awesome!!! I can't wait!! Thank you, thank you, thank you, thank YOU!!!

[Benj]

Hello,

I haven't tested on AVR hardware yet but it seems to compile. Let me know how you get on. Also you might want to make a backup of your old files just incase you need to go back for any reason.

Files Removed - Newer files available further down

The maximum number of files is set by this definition in the defines section of the FAT component. You can edit this by editing the file directly or by using the defines section of the custom code interface. The default number of files is set to 1 to ensure that existing programs continue to work correctly without suddenly needing the additional RAM space required by additional files.

Code: Select all

//!!EDIT HERE TO CHANGE MAX NO OF FILES!!
#define %a_CONCURRENT_FILES		1		//%n

The new "set file index" function allows you to switch between active files, the default file selected is file 0 allowing existing programs to work in the same way without modification.

Here is a quick pseudo example of how the code works.

open_file ("file0.txt")
Print Sector 0 to LCD

set_file_index (1)
open_file ("file1.txt")
Print Sector 0 to LCD

set_file_index (0)
move_to_next_sector(0)
Print Sector 1 to LCD

set_file_index (1)
move_to_next_sector(0)
Print Sector 1 to LCD

set_file_index (0)
move_to_next_sector(0)
Print Sector 2 to LCD

set_file_index (1)
move_to_next_sector(0)
Print Sector 2 to LCD

All the file directories are initialised to root. However if you open a folder and navigate away from root then it will only apply for the file index you have selected. This allows you to work with concurrent files from multiple folder locations.

Another quick example for a file copy

create_file ("filecopy.txt")
open_file ("filecopy.txt")

set_file_index (1)
open_file ("file.txt")
filesize = read_file_length()

while (filesize == 512)
{
set_file_index (0)
write_file_sector()
move_to_next_sector(1)

set_file_index (1)
move_to_next_sector(0)
filesize = read_file_length()
}

set_file_index (0)
write_file_sector()

[rocket200]

Hello,

I haven't tested on AVR hardware yet but it seems to compile. Let me know how you get on. Also you might want to make a backup of your old files just incase you need to go back for any reason.

FC5_AVR_FAT16.c

AVR_CAL_SPI.c

The maximum number of files is set by this definition in the defines section of the FAT component. You can edit this by editing the file directly or by using the custom code interface.

Code: Select all

//!!EDIT HERE TO CHANGE MAX NO OF FILES!!
#define %a_CONCURRENT_FILES		1		//%n

The new "set file index" function allows you to switch between active files, the default file selected is file 0 allowing existing programs to work in the same way.

Here is a quick pseudo example of how the code works.

open_file ("file0")
Print Sector 0 to LCD

set_file_index (1)
open_file ("file1")
Print Sector 0 to LCD

set_file_index (0)
move_to_next_sector(0)
Print Sector 1 to LCD

set_file_index (1)
move_to_next_sector(0)
Print Sector 1 to LCD

set_file_index (0)
move_to_next_sector(0)
Print Sector 2 to LCD

set_file_index (1)
move_to_next_sector(0)
Print Sector 2 to LCD

All the file directories are initialised to root. However if you open a folder and navigate away from root then it will only apply for the file index you have selected. This allows you to work with concurrent files from multiple folder locations.

Hello Ben!

So I swapped out the files for the FAT and CAL. I tried connecting to the SD card, but when I init it, it returns 0xED (sector bytes error).

[rocket200]

Ben,

Do you need me to post anything that would help you debug the error?

[Benj]

Hi Rocket,

Hmm is the sect bytes error returning on all the cards your trying or are you only testing a single card? What about if you format the card using different cluster sizes. Finally was the card working previously?

Very odd as my PIC version is working for all cards and we have ported the code to dsPIC and this is also working very nicely