We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello, I want to initialize the fat32 file system for usb host on at91sam9260.I am having problem in checking the boot signature.My application is to read/write the text file from the mass storage device.I am doing such task (implementing the file system)first time...So plz help me regarding this....Thank you.....
hello sir, Thanks again for quick reply. sorry but i am confused now and depressed too... memory media is not formatted,please tel me how to do?I will do accordingly.. Thank you....
Are your device needing the ability to format the memory media?
If the answer is no - then maybe insert the memory media in a PC/Mac and format it?
Hello sir, Still i am not able to read the boot sector after the disk formatted with PC.. what should i do now??? I am using usb hostlite code (of lpc 2468)to implement fat32 file system (for at91sam9260),is it okay???
Hello sir, after formatting the memory media in a PC,i checked it but it gives the same result,that is it gives the return value of "No fat volume is found"....Plz tel me what should i do now??? Thank you...
what is the boot sector hex bytes? have you formatted the drive with system file? but disable protection at beginning.
> I m using the usb hostlite code for the my usb host implementation(that is for at91sam9260) with respective changes because both are OHCI standered. Is it okay???
Fine. The code of NXP USBHostLite is well organized. You may easily replace the USB hardware layer (usbhost_lpc2468.c or usbhost_lpc17xx.c) into an other host engine. Also, the FAT support layer may be replaced to FatFs by Chan for FAT32 support.
> that is it gives the return value of "No fat volume is found"....Plz tel me what should i do now???
Sound like the sector read (READ10) fails. Confirm this error first. Just after the enumeration (Host_EnumDev()) in the main(), call MS_BulkRecv() to read the first sector (MBR: Master Boot Record) from the USB stick. Compare the contents of the sector buffer with the sector data read out by a PC. How do these data differ? - For example, the first 64 bytes matches, but latter part differ, etc.
To read out a sector on a PC,
Disk Probe - Included in Windows install CD/DVD, in \Support\Tools folder or - Windows XP Service Pack 2 Support Tools " href= "http://www.theabsolute.net/sware/dskinv.html">www.theabsolute.net/.../dskinv.html The structures of directory and its entries are described in MS FAT32 System spec msdn.microsoft.com/.../gg463080.aspx
There are easier explanations on the web, for example, www.easeus.com/.../root-directory-management-in-FAT32.htm
Also, I recommend you to try as many USB sticks as you have. The implementation of USB sticks often have anomaly from the standard. Some USB sticks require tweaks to get them run.
Tsuneo
Hello sir, Thanx for the reply.. I checked it with the sector data read out by the PC but it completely differ from that whatever sector received in buffer...so what should be the next step to check it???
How about debugging???
You have now come about as far as I suggested one week ago - to verify if there is a file system there, and if your read code is able to correctly read the existing contents.
Debugging is a major part of software development. And something you need to spend own time with. Trying to ask a web forum for every single step isn't a productive route. If you write the flash read code yourself, you have to compare your code with the requirements specified in datasheets. If you have copied the code from some other project, you have to figure out if that other project can correctly read the data. If yes - then you have to figure out why your copied code can't.
Hello, After checking with pen drive having fat32 file system(transend 8 GB pen-drive i am using),but sector buffer does not match with that checked it on PC...is there any problem in initialization process???
You always just write "does not match" or "completely different". That doesn't really tell much.
But exactly _what_ are you seeing? Hints that you read data but it is corrupted? Or always empty data? Or what? Debugging is about looking at whatever clues you have and try to deduce potential error sources. Or trying to figure out how a test can be changed to give better clues.
Hello sir, sector buffer always shows all the fields Zero...
It couldn't have hurt too much to have written that information in one of your first posts? Have you verified that the hardware actually makes an attempt to access the memory? Have you verified that the relevant hardware pins are reacting? That the memory chip is correctly connected? And powered?
Are you using your own hardware design or an existing evaluation board that have sample code to access this flash memory? Does there exist any sample code somewhere that _can_ access the flash memory, even if your specific project seems to fail?
It is obviously not meaningful to consider any FAT16 or FAT32 or other file system until your specific hardware together with your specific memory access code is able to read and write data correctly when accessing the flash. Then, and only then, will it be meaningful to look at the building blocks that depends on working flash access. So FAT32 or USB is irrelevant until read/write of flash sectors works.
Hello sir, I am using my own designed hardware and the hardware actually makes an attempt to access the memory as i checked it after the enumeration process...I think there is problem in passing the drive address on which file system is to be mounted, but i am not sure...by knowing the initialization procedure of fat, i want to check is the problem actually exists or is there any other problem?? Thank you...
Why bother about enumeration files etc before you have validated the code to access the memory?
Start by ignoring all of that and concentrating on what your microprocessor can do about accessing the memory. Do not try to debug a system before you have debugged the individual modules that forms the system. "passing the drive address" or "mounting of file system" should be irrelevant to the current question: Can your hardware correctly access the memory? Can your microcontroller write a pattern and then read it back correctly? If the answer is no, then you aren't likely to be able to send information over USB, and store in that flash and later read it back either.