 |
 |
| View previous topic :: View next topic |
| Author |
Message |
wallink
Joined: 05 Dec 2007
Posts: 1
|
| ex_fat.c problem |
 Posted: Wed Dec 05, 2007 2:18 pm |
 |
|
Hello,
I am working with the ex_fat.c sample program from CCS and have encountered some problems getting it to work. I am using the 3,3V Ethernet Controller board (PIC18F67J60) to run this program. I am wondering if anyone has gotten this program to work?
I am using a ScanDisk 1 GB card formatted using the command format [drive:] /FS:FAT32 /A:512. When I run the program it is unable to make a directory or a file. If I format it using the ex_fat.c program it then allows directories and files to be created, but niether are accessable (I am unable to append a file or change to a directory) and neither are visible on a PC. Which I would not expect them to be visible on the PC due to the raw formatting perfomed by the PIC.When I create directories and files on a PC and then try to access them with the PIC they are not visible and unaccessable.
I am able to use the ex_mmcsd.c program and read and write data to the SD card.
Thanks for any help |
|
 |
Chawee
Guest
|
|
| Posted: Thu Dec 06, 2007 9:25 am |
|
|
Hi,
i try this driver before too. I´m also not successful to get the FAT Code running. I also can´t find someone who makes this driver works. Now i already port another FAT Code to the PIC and it looks like it works.
Chawee |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
| Re: ex_fat.c problem |
| Posted: Mon Feb 28, 2011 2:47 pm |
|
|
| wallink wrote: | Hello,
I am working with the ex_fat.c sample program from CCS and have encountered some problems getting it to work. I am using the 3,3V Ethernet Controller board (PIC18F67J60) to run this program. I am wondering if anyone has gotten this program to work?
I am using a ScanDisk 1 GB card formatted using the command format [drive:] /FS:FAT32 /A:512. When I run the program it is unable to make a directory or a file. If I format it using the ex_fat.c program it then allows directories and files to be created, but niether are accessable (I am unable to append a file or change to a directory) and neither are visible on a PC. Which I would not expect them to be visible on the PC due to the raw formatting perfomed by the PIC.When I create directories and files on a PC and then try to access them with the PIC they are not visible and unaccessable.
I am able to use the ex_mmcsd.c program and read and write data to the SD card.
Thanks for any help |
Did you have any luck figuring this out? I can't believe nobody has a solution to this. I have a support request in to CCS to see if maybe they know of a work-around. As soon as I hear of a resolution, I'll be posting it to the forum for anyone in the future that has it.
By the way, I have a FAT driver from a company that sells it, but when I recently changed to microSD instead of miniSD, the driver almost always fails (I've spent a lot of time trying to debug it, but the problems are never consistently the same). If I read and write files with the CCS example files, I don't have any problems. This should validate that it's not a hardware issue. I would just switch to the CCS drivers, but not being able to read the files on a PC makes it completely useless. It's hard to believe CCS would release an example like that. |
|
|
andrewg
Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia
|
|
| Posted: Tue Mar 01, 2011 7:40 am |
|
|
There are bugs in the CCS driver. I've fixed those I'm aware of. See below:
CCS FAT driver bugfix!
Note that I still haven't tested writing capability. Sadly my SD projects are on indefinite hold...
_________________
Andrew |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
| Re: ex_fat.c problem |
| Posted: Tue Mar 01, 2011 7:21 pm |
|
|
| Quote: | | ... I recently changed to microSD instead of miniSD, the driver almost always fails (I've spent a lot of time trying to debug it, but the problems are never consistently the same).. |
Ignoring "add-ons" like card detect and write protect switches, from a driver's perspective, there is no real difference between microSD, miniSD and standard SD form factors. There is a difference between SD and SDHC media types however this is unrelated to the form factor. This means a SDHC capable driver will work with both SD and SDHC cards across the form factors but an SD only driver will not work on SDHC cards irrespective of the form factor.
One thing to take into consideration is the CCS drivers operate the SPI bus at a low SPI clock rate and are therefore, as you would expect, slower than other drivers. SD cards irrespective of form factor, consume a lot of current for a very short time during an actual write to the media. In a continuous writing sequence, a slow driver performs less writes per second and therefore the average write current per second is lower that the average write current for a high speed driver. The bottom line is that if the low speed driver appears to be more reliable than the high speed driver when all you have changed is the form factor then most likely there is a hardware related issue. Examples include: voltage regulators no capable of delivering the required current, insufficient power supply filtering capacitors, insufficient power supply decoupling capacitors. You also need to consider the chip select logic and any level translation logic - rise times become an issue with some implementation with high SPI clock rates. One way to test this is to slow down the SPI clock rate of the high speed driver.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Darren Rook
Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI
|
|
| Posted: Thu Mar 03, 2011 8:27 am |
|
|
Contact CCS tech support. They have newer beta code based on Microchip's MDD library.
_________________
I came, I saw, I compiled. |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Thu Mar 03, 2011 11:05 am |
|
|
| Darren Rook wrote: | | Contact CCS tech support. They have newer beta code based on Microchip's MDD library. |
Yeah, that's made my investigation more interesting.
I'd like to discuss some of my findings, however, I want to point out that they are still inconclusive. Andrew with Brush Electronics has been very helpful in supporting his FAT library. I don't want the following explanation to reflect poorly on his library - again, I still don't know all the reasons for what's going on, and it could very likely be something with my hardware configuration.
So here's the scoop:
I've been using Andrew's library all along. I was using a miniSD card configuration, and it was working great. I also have a real time clock on the SPI bus. They've worked together fine.
Recently, I decided to switch to the microSD form factor because the card slot I was using with the miniSD became obsolete, and the miniSD cards are becoming harder to find. I also changed to surface mount pull-up resistors and the 3V regulator. The 3V regulator I was using before was LD1117V33C and now I'm using p/n LD1117D33CTR. Of course, the card slot also changed.
After firing it up the first time, I was only getting data to write intermittently. It was failing very frequently. I did quite a bit of digging, and found that the cause of failure almost always varied. On one particular card, sometimes it would work fine, and then on another write sequence (create file, write data), it would fail.
I checked the things Andrew suggested (same things he suggested in the previous post above). I decided to try the CCS FAT example code, ex_fat.c to see if it was absolutely a hardware problem. Oddly enough, it worked just fine. I started considering using this code. However, I was frustrated by the issue with this code of not being able to read the data on a PC. That just wasn't acceptable. Then I found out about the new FAT code by CCS based on Microchip's MDD library. It indeed does work correctly - data can be written and read by the PIC, and also seen on a PC just fine.
One thing that Andrew suggested is that it might be a speed issue, and that the CCS code was simply running slower. So I dumbed down Andrew's code to run at a snail pace of about 25kHz SPI clock. I had to get down to that range to get it to work perfectly every time. So I start thinking that maybe speed really is the issue. I didn't think that the CCS code was running *that* slow though, so I slapped a scope on the line to see what it was running at. Definitely not slow at all! It was running at 2.5M! I was running the code together with my real time clock - everything was working just as I needed it to.
So now I'm completely stumped. I would still prefer to use Andrew's code, as it is lighter weight and is already integrated into my code. I would probably live with the 25kHz speed, but that's pretty painfully slow. There definitely is a correlation with speed and that code working. At 50kHz, it stops working reliably.
Again, I want to point out that I have my serious doubts about a flaw in Andrew's code - as he pointed out, it is working in a large number of applications. But with the CCS code working as it should, I'm not sure what to think. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Thu Mar 03, 2011 11:33 am |
|
|
I obviously don't know all the details of your changeover but I have to state that I've been using the Brush Electronics CCS SD card driver for quite a few years and on two different products now. I also have to state that I've never had any issues with the driver, even though the latest product uses a micro SD card.
I know it doesn't make a lot of sense because both the Brush driver and the CCS driver run at high SPI speeds, but just for the hell of it, can you add a ~47uF or higher Vdd to gnd electrolytic and a 0.1uF ceramic on Vdd, physically close to the SD card slot? Add these additional caps even if you already have decoupling and electrolytics already. If this does make a difference, I'd suspect that the two drivers having significant timing differences in the way they configure/init the card. This, coupled with power supply ripple, may be why one works and the other doesn't.
Just a stab in the dark, but it's been my general experience that the power supply, although often overlooked, is unfortunately the cause of a lot of headaches. |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Thu Mar 03, 2011 11:59 am |
|
|
| newguy wrote: | I obviously don't know all the details of your changeover but I have to state that I've been using the Brush Electronics CCS SD card driver for quite a few years and on two different products now. I also have to state that I've never had any issues with the driver, even though the latest product uses a micro SD card.
|
I know, and that's why I hesitate to bring anything up on a public forum. I don't want to discredit the Brush Electronics driver in *any* way. But I do want to figure out what's going on, and hope to get some ideas from people here.
| newguy wrote: |
I know it doesn't make a lot of sense because both the Brush driver and the CCS driver run at high SPI speeds, but just for the hell of it, can you add a ~47uF or higher Vdd to gnd electrolytic and a 0.1uF ceramic on Vdd, physically close to the SD card slot? Add these additional caps even if you already have decoupling and electrolytics already.
|
Well, this is actually exactly what I do have, a 47uF electrolytic, and 0.1uF ceramic. They are close, but not as close as they could be. I added a 22uF tantalum as physically close to the card slot 3V and GND connections as possible, but no change.
| newguy wrote: |
Just a stab in the dark, but it's been my general experience that the power supply, although often overlooked, is unfortunately the cause of a lot of headaches. |
I tried soldering in the old regulator, and didn't notice any change - at least not any appreciable change - still failed intermittently. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Thu Mar 03, 2011 12:46 pm |
|
|
| Can you start to mix & match code from the CCS driver (just concentrate on the powerup/init code now) to the Brush driver? If you start replacing Brush code, eventually (hopefully), you should arrive at a working final implementation that's a mix of the two. Then you can examine the minute differences between what works and what didn't in an effort to discover why you're seeing what you're seeing... |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Fri Mar 04, 2011 6:38 pm |
|
|
| evsource wrote: |
So now I'm completely stumped. I would still prefer to use Andrew's code, as it is lighter weight and is already integrated into my code. I would probably live with the 25kHz speed, but that's pretty painfully slow. There definitely is a correlation with speed and that code working. At 50kHz, it stops working reliably.
Again, I want to point out that I have my serious doubts about a flaw in Andrew's code - as he pointed out, it is working in a large number of applications. But with the CCS code working as it should, I'm not sure what to think. |
Okay, *finally* figured it out!!
On my projects, I use fast_io, and set the set_tris_x for all ports, with appropriate initial output for anything that is an output. In this project though, I never did that. I'm not sure what was different with the microSD arrangement from the miniSD (the miniSD configuration had over 50 units in service without problem). However, not having the ports set up properly was causing the intermittent failures I was experiencing with Andrew's code.
Now about Andrew's (Brush Electronic's) code. I don't think I would have figured out the problem without Andrew's help! He spent a lot of time e-mailing back and forth suggestions. It was his idea to set up the port direction. I highly recommend anyone trying to get FAT support for SD cards use the Brush Electronics library. It's worth the money. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Sat Mar 05, 2011 9:07 pm |
|
|
| evsource wrote: | | I highly recommend anyone trying to get FAT support for SD cards use the Brush Electronics library. It's worth the money. |
Amen!!! 
[At the moment, it's less than a tank of gas. Bargain!  ] |
|
|
pumazzz
Joined: 19 Oct 2011
Posts: 12
|
|
| Posted: Thu Jan 19, 2012 4:13 pm |
|
|
| evsource wrote: | Then I found out about the new FAT code by CCS based on Microchip's MDD library. It indeed does work correctly - data can be written and read by the PIC, and also seen on a PC just fine.
|
Can you tell me where did you find this new version, as I have already tried many versions, none of them worked. Thank you very much. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Jan 20, 2012 5:07 am |
|
|
| pumazzz wrote: | | evsource wrote: | Then I found out about the new FAT code by CCS based on Microchip's MDD library. It indeed does work correctly - data can be written and read by the PIC, and also seen on a PC just fine.
|
Can you tell me where did you find this new version, |
It is all in this same thread! There is a post from Darren Rook (a CCS employee) mentioning you can get this code from CCS Tech Support. I don't have the most recent CCS version, but have you checked it being in the Program Files/Drivers folder?
| Quote: | | I have already tried many versions, none of them worked. |
The CCS driver has several flaws, but with the three fixes posted by Andrewg it should be usable for standard SD cards (not SDHC). For a link to the fixes see his post higher in this thread.
Or use one of the other free SD libraries posted in the Code Library section of this forum.
For proven technology spent a small amount of money and get the fully supported SD and SDHC library from Asmallri.
Note 1: most SD libraries only support 8.3 filenames. Longer file names are covered by a Microsoft patent.
Note 2: it is advised to never format your SD card with the PIC but use your PC instead. All libraries that I know of have only a minimum implementation of the format function. Because of patents or memory requirements parts were left out causing compatibility issues. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
