topic Re: Implementing Freescale FAT Lite on ColdFire in ColdFire/68K Microcontrollers and Processors

Implementing Freescale FAT Lite on ColdFire

PabloA — Wed, 10 Oct 2012 20:42:02 GMT

Hi there, I need some help about this issue:

I'm working in a data logger project like DEMOFLEXISJMSD_DataLogger_V2

http://www.freescale.com/webapp/sps/site/training_information.jsp?code=WBNR_SDCARDREADER_S08JM&fsrch=1#

This example use a SD card and Freescale FAT Lite to storage data.

I implemented the same FAT functions in the MCF51CN128RM ColdFire with the following results:

1. SD_Init() function returns:

Ok (0).

2. FAT_FileOpen (FILE_NAME, MODIFY) function returns:

FILE_NOT_FOUND (1) -> If the file was not created with the same function with CREATE (1) as parameter.

If I create a file using Windows XP, this function doesn't found it.

FILE_FOUND (0) -> Just if the file was created using FAT_FileOpen function.

3. FAT_FileOpen (FILE_NAME, CREATE) function returns:

FILE_CREATE_OK (2) -> But when I read the SD Card using Windows XP nothing appears.

I'm using FAT functions like this:

SD_Card_Status = SD_Init();

if (SD_Card_Status != OK)

{

return;

}

FAT_Read_Master_Block();

SD_Card_Status = FAT_FileOpen (FILE_NAME, MODIFY);

if (SD_Card_Status = FILE_NOT_FOUND)

{

SD_Card_Status = FAT_FileOpen (FILE_NAME, CREATE);

}

FAT_FileClose();

SD_Card_Status = FAT_FileOpen (FILE_NAME, MODIFY);

FAT_FileWrite (SD_String_Array, 20);

FAT_FileClose();

In this forum I found a discussion about Freescale FAT (https://community.freescale.com/message/86766#86766) but i can't solve the problem.

Even I tried changing some part of the code suggested in the forum, but it doesn't work.

Cuestions:

Why FAT_FileOpen function returns FILE_CREATE_OK and Windows can't read it?

Why FAT FileOpen function can't recognize a file created with Windows?

Is this FAT library able to manage up to 2Gbs?

If some body test Freescale FAT Lite at ColdFire, please give me some tips.

Best regards!

Pablo Suárez

Re: Implementing Freescale FAT Lite on ColdFire

jaroslavnecesan — Tue, 11 Dec 2012 15:05:26 GMT

Hi Pablo.

I have the same problem now and I don't know how to solve it. Have you found how to solve it meanwhile? Thank you

Jaro

Re: Implementing Freescale FAT Lite on ColdFire

TomE — Wed, 12 Dec 2012 05:25:38 GMT

In that previously referenced discussion it looks like they were working from a modified version of FAT Lite. So whatever version you found may need previous modifications before finally those endian-related modifications will work.

Where did you get the library from? What download link?

This library was originally for 8-bit processors, and if it wasn't written to have the right structure sizes on 32-bit native CPUs, all of the "ints" might be the wrong length. These absolutely have to match Microsoft's definition of which bit and byte goes where in the FAT and Directory entries.

If Freescale don't support a working FAT file system on these chips and you can't afford to buy one, this may turn into a big waste of your time.

Tom

Re: Implementing Freescale FAT Lite on ColdFire

scifi — Wed, 12 Dec 2012 06:23:47 GMT

I seem to remember that the Codewarrior Coldfire compiler has configurable size of int and minimum alignment. So it might be possible to compile the code with the right settings to make it work.

Re: Implementing Freescale FAT Lite on ColdFire

sebasira — Wed, 12 Dec 2012 18:48:39 GMT

Hi Pablo!

I was having lots of problem with DEMOFLEXISJMSD_DataLogger_V2 software, even I've read that it's got lots of bugs... Also, I was using it and sometimes it just hangs... It's been working fine and then suddenly it crashes for no reason so it was not reliable.

After lots of headaches I've found this: https://github.com/suan/Freescale-SD-FAT-Library and it works like a charm!!!

About FILE_CREATE_OK and can't see it on Windows (XP or 7), I can tell you 2 things:

1- In CodeWarrior Project Settings, you MUST set Struct Aligment to byte under ColdFire Processor panel.

2- With suan's Library I needed to use SD Formatter: https://www.sdcard.org/downloads/formatter_3/ to format the SD card because when I formatted with windows it wouldn't have the format as the Library espect it to be (I didn't go deeper with this but I think is about FAT standards. This is the structure that suan's Library uses: http://home.teleport.com/~brainy/fat16.htm)

I strongly recommend you to use this Library instead of the one from DRM104. So far I haven't got a single error regarding SD Card writes (I don't perform readings). And as you can see in older post I did have a lot of problems before.

Re: Implementing Freescale FAT Lite on ColdFire

sebasira — Wed, 12 Dec 2012 18:54:43 GMT

One thing I forgot to mentioned, is that not all the SD Cards can be handled via SPI... SunDisk's ones does. And if I recall correctly 2GB is the maximum for DRM104 FAT and also suan's library.

Saludos!

Re: Implementing Freescale FAT Lite on ColdFire

TomE — Wed, 12 Dec 2012 23:30:22 GMT

More interesting information on the various FAT formats and their history here:

http://en.wikipedia.org/wiki/Fat16

A bit of perspective from Wikipedia. FAT16 (actually FAT16B) dates from 1987, 25 years ago. FAT32 was introduced with Windows 95 OSR2 in 1996, 16 years ago. FAT32 supports 32 bit cluster numbers, increasing the disk size from the 2G FAT16 limit to 16T. FAT32 usually implies "VFAT Long File names" (LFN) too, otherwise you have to use "8.3 file names".

FAT16 is fine for embedded storage, but if you want to be able to swap SD cards or USB Keys between the embedded system and other computers you'll have less problems if you get a stack that supports FAT32 and LFNs. That one doesn't support directories either (only files in the root directory).

> I needed to use SD Formatter:

Under Windows (at least XP) with small enough memory sticks you have the choice of formatting "FAT32", "FAT" or "exFAT". That library might work with "FAT" formatting.

If you are swapping cards between the embedded device and a PC, be careful, and expect to lose data when the computers somehow disagree. I've even had the linux-based OS in a Tektronix oscilloscope format a USB Key in a way that Windows accepted, but which put a commercial embedded FAT32 stack into an infinite loop.

Tom

Re: Implementing Freescale FAT Lite on ColdFire

guille — Thu, 03 Jan 2013 00:32:21 GMT

Hi there, I just published a revised version of FAT Lite. Some improvements were taken from this thread (Re: Problems porting SD FAT to MCF51 JM Badge Board - Datalogger application), the others were the result of the efforts of me and my team.

http://code.google.com/p/sdfatlite/

Cheers!

Re: Implementing Freescale FAT Lite on ColdFire

sebasira — Fri, 04 Jan 2013 11:59:10 GMT

Thank you Guille!!

I'll give it a try and let you know about my experience

Cheers!

SebaS

Re: Implementing Freescale FAT Lite on ColdFire

carlospalma — Fri, 04 Jan 2013 19:58:47 GMT

This might seem a noob's question, but why on earth are there three main modules on the example you provided?, that is mainFAT, mainSD and mainSPI all have an infinite loop. I had never seen that before.

Re: Implementing Freescale FAT Lite on ColdFire

guille — Fri, 04 Jan 2013 21:03:18 GMT

Oh I Will correct that and upload it again. Those are the main functions were I tested the different modules independently. mainFat.c is the main that you need, thx for your comment.

Re: Implementing Freescale FAT Lite on ColdFire

guille — Fri, 04 Jan 2013 21:05:00 GMT

Thx, good luck!

Re: Implementing Freescale FAT Lite on ColdFire

carlospalma — Sat, 05 Jan 2013 17:05:52 GMT

I have been working with the modified library you provided, but for some reason when I try to read the file LOG1.txt using my computer it shows nothing...that is even after I confirmed the routine to create a file was accessed by setting an LED on. Could you point me in the right direction? Is the format I'm using for my card the right one, because I have formatted it using windows seven and choosing FAT(default) .

Re: Implementing Freescale FAT Lite on ColdFire

guille — Sat, 05 Jan 2013 18:59:32 GMT

You should use some tool that gives you raw access to the file system, like WinHex, to verify the data is correctly write into the FS on the SD card, before trying with Windows. I read the structures described here (http://www.maverick-os.dk/FileSystemFormats/FAT16_FileSystem.html) to understand and improve the Fat Lite library provided by Freescale.

There are many posible cases and i don't probe them all. The idea is to keep the library as simple as posible.

FAT (Default) is correct, it's FAT16 (you can see this with WinHex). It is posible that, for some reason, the library is not correctly writing the new file entry in the Root Directory section of the FS.

Please let me know about your progress after using WinHex and reading the FAT structures!

Guille

Re: Implementing Freescale FAT Lite on ColdFire

carlospalma — Tue, 08 Jan 2013 20:45:02 GMT

Hi Guille. Listen, so far I got it to work modifying an already created file, I have to warn you and the community that even if winhex shows the boot information on block 0, it is not there, I used the method proposed by the original guy who uploaded the library (a loop to find boot information), and when reading main_offset using Freemaster (great tool by the way), it showed 226 as the block in which the boot information is stored. I don't know if it's because of the SD card I'm using, but changing that and this line of code :

while(ag8FATReadBuffer[0]!= 0xEB || ag8FATReadBuffer[1]!=0x3C || ag8FATReadBuffer[2]!=0x90)

did the trick for me.

Cheers!

the line of code used to read like this:

while(ag8FATReadBuffer[0]!=0xEB && ag8FATReadBuffer[0]!=0x3C && ag8FATReadBuffer[0]!=0x90)

I did this because negating an AND sentence gives an OR sentence (boolean logic)

Re: Implementing Freescale FAT Lite on ColdFire

guille — Wed, 09 Jan 2013 17:56:59 GMT

Hi Carlos, you are right about replacing && with ||, i will correct it and update the repo soon. That line was commented on the library, so it shouldn't do any harm. However, regarding the method to obtain the location of the MBR (of the first partition), to further obtain the location of the Root Directory, to further access the file you want, you have two options:

1. The method that the library originally use, commented in our version of the library:

while(ag8FATReadBuffer[0]!=0xEB && ag8FATReadBuffer[0]!=0x3C && ag8FATReadBuffer[0]!=0x90)

GetPhysicalBlock(u16Main_Offset++,&ag8FATReadBuffer[0]);

__RESET_WATCHDOG();

}

u16Main_Offset--; //Offset correction

2. Our method:

GetPhysicalBlock(0,&ag8FATReadBuffer[0]); //Get physical block zero from the SD

PartitionTable=(PartitionTable_Entries*)ag8FATReadBuffer; //Load the content of the buffer into the apropiate structure

if(PartitionTable->MBRSignature!=0x55AA) return; // Verify MBR Signature

u16Main_Offset=(UINT16)LWordSwap(PartitionTable->Partition[0].LBAStart); //Compute address of first partition

GetPhysicalBlock(u16Main_Offset,&ag8FATReadBuffer[0]); //Get physical block where the first partition is

if(ag8FATReadBuffer[0]!= 0xEB || ag8FATReadBuffer[1]!=0x3C || ag8FATReadBuffer[2]!=0x90) return; // Verify the first partition start pattern

As you can see, our method doesn't need to iterate in order to obtain the location of the first partition. It just get it from the values loaded in the MBR (not the MBR of the first partition -offset=226-, but the MBR of the physical volume, always located in zero address). As you said, i asume that the boot info of the physical volume is in block zero. I read this from the FAT specs. The boot info of the first partition is not in block zero. In your case, is in block 226. It's a little messy, in my case, the first partition began at 239.

I follow this picture to write the _PartitionTable_Entries structure

Tabla de particiones - Wikipedia, la enciclopedia libre

Same here

Maverick - The Operating System

PD: Sorry for my english!

Re: Implementing Freescale FAT Lite on ColdFire

sebasira — Wed, 06 Mar 2013 20:43:26 GMT

Hi guille!

I didn't have time to test your library before, and I started yesterday. Luckly for me, when I visit the site to download it, I found out that you already have a newer version.

I must tell you, I've got a custom hardware which has and SD socket, and it's attached to a MCF51QE128. It's working pretty good with suan's library I've posted before, but I've notice a problem whenever file size exceeded 3.5MB (don't know why yet). This problem encourage me to test yours and maybe replace the firmware with it.

But I think I've found some strange things that I want to point out: (please correct me if I'm wrong, what I'm telling is based on my experience)

1) First I thought that the way to handle SD cards via SPI was to initialize it at a slow speed (375kHz or 400kHz), and then must boost to a higher one, above 4MHz. But I've notice that in SD.c the call HighSpeedSPI() was commented. Is that ok?

2) Assuming that we must work at a higher speed, then the BaudRate divider inside SPI_High_rate is not correct, if your bus clock is 24MHz. Also, if you actually are running at 24MHz (I'm also at that speed) then the low speed is wrong, because if you want 375kHz you need to divide 24MHz by 64, wich means SCI2BR = 0x05 (0b00000101) instead of 0x06. (I need to change the value 0x06 for 0x05 otherwise SD card wouldn't be initilized at least for me)

3) in the SPI_Receive_byte shouldn't you wait for SPI2S_SPTEF before sending a dummy byte? And shouldn't you read STATUS register instead of DATA register before sending, in order to clear flags? I mean, replace taht routine with this one:

UINT8 SPI_Receive_byte(void){

while(!SPI2S_SPTEF) ;

(void)SPI2S;

SPI2DL=0xFF;

while(!SPI2S_SPRF) ;

return(SPI2DL);

}

I'd like to add that I've used the original freescale subroutines for a while (before suan's library) with this same hardware but sometimes it just get stuck on a SPI loop (if I recall correctly maybe the ReadMasterBlock loop) wich makes it impossible to use. Now with your new method maybe it's solved. I've manage to run this library with the changes above,but it still hangs here:

for(u16Counter=0;u16Counter<BLOCK_SIZE;u16Counter++)

*pu8DataPointer++=SPI_Receive_byte();

inside SD_Read_Block

I'm also guessing that if we combine suan's library (wich IMHO is great) with your new method we can finally get a real working FAT for ColdFire

One last thing I just remember when writting "ColdFire".... For the original library, the struct alignment of the project MUST be changed to byte instead of coldfire(long). In your's that is also needed or not? I tried it both ways but I cannot go futher because of the problem above.

Thanks !!

Saludos (I'm also from Argentina, jeje)

SebaS

Re: Implementing Freescale FAT Lite on ColdFire

JimDon — Thu, 07 Mar 2013 04:06:02 GMT

Has anyone tried Chan's code lately? I used it several years ago and it worked well.

FatFs - Generic FAT File System Module

Re: Implementing Freescale FAT Lite on ColdFire

sebasira — Thu, 07 Mar 2013 12:13:53 GMT

I've seen both (FatFs and PetitFat) years ago but never test them. I'm guessing I should use PetitFat because I don't believe I've got enough space for the full project.

But it was written for 8bit MCU and I'm using a 32bit one (MCF51QE). Since the project was done 3years ago I also guess it wouldn't have "support" in case of errors/problems

The advantage is the support of FAT32.

Jim: In which MCU did you test it? Would you recomend me to try it on a 32bit MCU? I'm asking you that because the original Freescale library was also ment for 8bit MCUs and when I ported to 32btis, I couldn't make it work until someon (I believe it was Carlos Cuevas) point me that I should change struct alignment to be byte instead of long. Until that moment I didn't know about struct alignment. I don't know if a problem like this one can arise with this project too; and without support, it would be difficult to port.

EDIT: I just re-check ELM's library... and I notice it only provides FAT routines, not low-leve disk IO. Now I remember that was the final reason why I didn't use it.

Re: Implementing Freescale FAT Lite on ColdFire

JimDon — Thu, 07 Mar 2013 14:39:00 GMT

The latest version was posted January 24 2013 so I would say it is still getting great support. Combined with the fact that the first release was 2006, it's age is a huge advantage, rather than a disadvantage.

The bit size of the processor should not at all be an issue - endianness and structure packing (a compiler issue) are bigger deals but IIRC he had solutions for that (of course structure packing must be by compiler, but we all know about that one).

He says it supports FAT12/16/32 long file names.

I ported it to a Dragon12 board (HCS12 - a 16 bit processor). Once I got my issue ironed out (Proper SPI operation etc), it was fine. You probably have the device specific issues already working.

I don't have an SD card slot right now, so I can't try it at this time, but I think it might be worth looking at.