Hi!
I just received a RCM5750 today from Rabbit. I know I'm probably one of
the first to receive it but I was hoping my problem is similar to other devices
with built in serial flash.
I'm trying to use the Rabbit FAT file system on it but I can't get
the samples to run.
I tried to run Fmt_Device and get:
fat_AutoMount() error (-304) Partition or volume not formatted
When I select: Erase device and create one large partition? (y/n)y I get:
fat_AutoMount() error (-303) Partition bad or unrecognized
Operation
failed (-303) Partition bad or unrecognized
I tried to clear pages 0,1,2,3 and then run FAT_WRITE_MBR.C but that
didn't work either. It did correctly tell me I have a 2MB flash and I told
it to write the MBR for the entire size. Is there a limit to the FAT size on
SFlash? (or Fat16 in general?)
Thanks!
Jeff Shapiro
P.S. Using Dynamic C 10.60
RCM5750 - Format FAT Filesystem on 2MB Serial Flash
Started by ●January 5, 2010
Reply by ●January 5, 20102010-01-05
On 1/5/2010 2:41 PM, Jeffrey wrote:
> Hi!
>
> I just received a RCM5750 today from Rabbit. I know I'm probably one of the first to receive it but I was hoping my problem is similar to other devices with built in serial flash.
>
> I'm trying to use the Rabbit FAT file system on it but I can't get the samples to run.
>
> I tried to run Fmt_Device and get:
>
> fat_AutoMount() error (-304) Partition or volume not formatted
>
> When I select: Erase device and create one large partition? (y/n)y I get:
>
> fat_AutoMount() error (-303) Partition bad or unrecognized
> Operation failed (-303) Partition bad or unrecognized
>
> I tried to clear pages 0,1,2,3 and then run FAT_WRITE_MBR.C but that didn't work either. It did correctly tell me I have a 2MB flash and I told it to write the MBR for the entire size. Is there a limit to the FAT size on SFlash? (or Fat16 in general?)
>
>
The ZW FAT is limited to 2 gig.
There is a long-standing bug that if the drvice is corrupted or has an
incompatible partition type, it will not allow you to repartition/format
as it fails the checks.
If you zero out the first few sectors, be sure to clear the RAM as this
is cached outside the low-level driver. Easiest is to remove the module
or backup battery.
Also check the bios files that buffers are defined.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
today's fortune
Saens demonstrates no less than 3 tcp/ip bugs in 2.2.3
> Hi!
>
> I just received a RCM5750 today from Rabbit. I know I'm probably one of the first to receive it but I was hoping my problem is similar to other devices with built in serial flash.
>
> I'm trying to use the Rabbit FAT file system on it but I can't get the samples to run.
>
> I tried to run Fmt_Device and get:
>
> fat_AutoMount() error (-304) Partition or volume not formatted
>
> When I select: Erase device and create one large partition? (y/n)y I get:
>
> fat_AutoMount() error (-303) Partition bad or unrecognized
> Operation failed (-303) Partition bad or unrecognized
>
> I tried to clear pages 0,1,2,3 and then run FAT_WRITE_MBR.C but that didn't work either. It did correctly tell me I have a 2MB flash and I told it to write the MBR for the entire size. Is there a limit to the FAT size on SFlash? (or Fat16 in general?)
>
>
The ZW FAT is limited to 2 gig.
There is a long-standing bug that if the drvice is corrupted or has an
incompatible partition type, it will not allow you to repartition/format
as it fails the checks.
If you zero out the first few sectors, be sure to clear the RAM as this
is cached outside the low-level driver. Easiest is to remove the module
or backup battery.
Also check the bios files that buffers are defined.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
today's fortune
Saens demonstrates no less than 3 tcp/ip bugs in 2.2.3
Reply by ●January 5, 20102010-01-05
Hi,
Just wanted to thank Scott for his quick reply and to post a follow-up / solution to the problem (in case someone finds this in the future).
I realized that the sflash_inspect.c program that I was using was INSIDE a samples\RCM5700 folder and not with the regular samples in samples\Filesystem\FAT. So that implied that something was special to the RCM5700.
Long story short, I needed to add:
#use RCM57xx.lib
and brdInit(); to the main() routine of FAT_SHELL.C and that sample now works so I can format and read/write files in the serial flash.
For my own code I'm going to see exactly what's going on in RCM57xx.lib and brdInit and probably just copy/modify what I need to my own project but that's what was necessary to get the samples working. I'm sure it has to do with mapping the right serial port to the serial flash, setting the IO pins, etc.
-- Jeff
P.S. I also had to modify FAT_CONFIG.LIB to add RCM5750 to the end of line 134 rather than deal with defining a custom driver.
#elif (RCM4200_SERIES || RCM4400W_SERIES || RCM5400W_SERIES || BL4S100_SERIES || RCM5750)
Just wanted to thank Scott for his quick reply and to post a follow-up / solution to the problem (in case someone finds this in the future).
I realized that the sflash_inspect.c program that I was using was INSIDE a samples\RCM5700 folder and not with the regular samples in samples\Filesystem\FAT. So that implied that something was special to the RCM5700.
Long story short, I needed to add:
#use RCM57xx.lib
and brdInit(); to the main() routine of FAT_SHELL.C and that sample now works so I can format and read/write files in the serial flash.
For my own code I'm going to see exactly what's going on in RCM57xx.lib and brdInit and probably just copy/modify what I need to my own project but that's what was necessary to get the samples working. I'm sure it has to do with mapping the right serial port to the serial flash, setting the IO pins, etc.
-- Jeff
P.S. I also had to modify FAT_CONFIG.LIB to add RCM5750 to the end of line 134 rather than deal with defining a custom driver.
#elif (RCM4200_SERIES || RCM4400W_SERIES || RCM5400W_SERIES || BL4S100_SERIES || RCM5750)
Reply by ●January 9, 20102010-01-09
A quick note for others who decide to go this route. Digi/Rabbit isn't
supporting FAT on the RCM5750 because it doesn't have battery-backed RAM (a
requirement of the FAT cache used to prevent filesystem corruption).
You may need to add the RCM5750 to a list of boards in BOARDTYPES.LIB in order to allocate buffer space for the cache anyway. I'm not sure whether that's a requirement or not, but it's something to look into.
-Tom
On Jan 5, 2010, at 2:47 PM, Jeffrey wrote:
>
> Hi,
>
> Just wanted to thank Scott for his quick reply and to post a follow-up / solution to the problem (in case someone finds this in the future).
>
> I realized that the sflash_inspect.c program that I was using was INSIDE a samples\RCM5700 folder and not with the regular samples in samples\Filesystem\FAT. So that implied that something was special to the RCM5700.
>
> Long story short, I needed to add:
>
> #use RCM57xx.lib
>
> and brdInit(); to the main() routine of FAT_SHELL.C and that sample now works so I can format and read/write files in the serial flash.
>
> For my own code I'm going to see exactly what's going on in RCM57xx.lib and brdInit and probably just copy/modify what I need to my own project but that's what was necessary to get the samples working. I'm sure it has to do with mapping the right serial port to the serial flash, setting the IO pins, etc.
>
> -- Jeff
>
> P.S. I also had to modify FAT_CONFIG.LIB to add RCM5750 to the end of line 134 rather than deal with defining a custom driver.
>
> #elif (RCM4200_SERIES || RCM4400W_SERIES || RCM5400W_SERIES || BL4S100_SERIES || RCM5750)
>
>
You may need to add the RCM5750 to a list of boards in BOARDTYPES.LIB in order to allocate buffer space for the cache anyway. I'm not sure whether that's a requirement or not, but it's something to look into.
-Tom
On Jan 5, 2010, at 2:47 PM, Jeffrey wrote:
>
> Hi,
>
> Just wanted to thank Scott for his quick reply and to post a follow-up / solution to the problem (in case someone finds this in the future).
>
> I realized that the sflash_inspect.c program that I was using was INSIDE a samples\RCM5700 folder and not with the regular samples in samples\Filesystem\FAT. So that implied that something was special to the RCM5700.
>
> Long story short, I needed to add:
>
> #use RCM57xx.lib
>
> and brdInit(); to the main() routine of FAT_SHELL.C and that sample now works so I can format and read/write files in the serial flash.
>
> For my own code I'm going to see exactly what's going on in RCM57xx.lib and brdInit and probably just copy/modify what I need to my own project but that's what was necessary to get the samples working. I'm sure it has to do with mapping the right serial port to the serial flash, setting the IO pins, etc.
>
> -- Jeff
>
> P.S. I also had to modify FAT_CONFIG.LIB to add RCM5750 to the end of line 134 rather than deal with defining a custom driver.
>
> #elif (RCM4200_SERIES || RCM4400W_SERIES || RCM5400W_SERIES || BL4S100_SERIES || RCM5750)
>
>
Reply by ●January 10, 20102010-01-10
Where did you find out about the battery-backed FAT cache? I discovered this on
my own with RCM3700 modules using Rabbit's FAT. The filesystem corruption
was happening fairly often, always after powering up the system. On a whim, I
put the battery back in the dev board (I had removed it since I wasn't
using the RTC). That fixed the problem. I even reported this to Rabbit's
tech support and they sounded surprised and made no mention of any cache! Is
the battery requirement mentioned in their documentation?
--- In r..., Tom Collins wrote:
>
> A quick note for others who decide to go this route. Digi/Rabbit isn't supporting FAT on the RCM5750 because it doesn't have battery-backed RAM (a requirement of the FAT cache used to prevent filesystem corruption).
>
> You may need to add the RCM5750 to a list of boards in BOARDTYPES.LIB in order to allocate buffer space for the cache anyway. I'm not sure whether that's a requirement or not, but it's something to look into.
>
> -Tom
> On Jan 5, 2010, at 2:47 PM, Jeffrey wrote:
> >
> > Hi,
> >
> > Just wanted to thank Scott for his quick reply and to post a follow-up / solution to the problem (in case someone finds this in the future).
> >
> > I realized that the sflash_inspect.c program that I was using was INSIDE a samples\RCM5700 folder and not with the regular samples in samples\Filesystem\FAT. So that implied that something was special to the RCM5700.
> >
> > Long story short, I needed to add:
> >
> > #use RCM57xx.lib
> >
> > and brdInit(); to the main() routine of FAT_SHELL.C and that sample now works so I can format and read/write files in the serial flash.
> >
> > For my own code I'm going to see exactly what's going on in RCM57xx.lib and brdInit and probably just copy/modify what I need to my own project but that's what was necessary to get the samples working. I'm sure it has to do with mapping the right serial port to the serial flash, setting the IO pins, etc.
> >
> > -- Jeff
> >
> > P.S. I also had to modify FAT_CONFIG.LIB to add RCM5750 to the end of line 134 rather than deal with defining a custom driver.
> >
> > #elif (RCM4200_SERIES || RCM4400W_SERIES || RCM5400W_SERIES || BL4S100_SERIES || RCM5750)
> >
> >
> >
>
--- In r..., Tom Collins wrote:
>
> A quick note for others who decide to go this route. Digi/Rabbit isn't supporting FAT on the RCM5750 because it doesn't have battery-backed RAM (a requirement of the FAT cache used to prevent filesystem corruption).
>
> You may need to add the RCM5750 to a list of boards in BOARDTYPES.LIB in order to allocate buffer space for the cache anyway. I'm not sure whether that's a requirement or not, but it's something to look into.
>
> -Tom
> On Jan 5, 2010, at 2:47 PM, Jeffrey wrote:
> >
> > Hi,
> >
> > Just wanted to thank Scott for his quick reply and to post a follow-up / solution to the problem (in case someone finds this in the future).
> >
> > I realized that the sflash_inspect.c program that I was using was INSIDE a samples\RCM5700 folder and not with the regular samples in samples\Filesystem\FAT. So that implied that something was special to the RCM5700.
> >
> > Long story short, I needed to add:
> >
> > #use RCM57xx.lib
> >
> > and brdInit(); to the main() routine of FAT_SHELL.C and that sample now works so I can format and read/write files in the serial flash.
> >
> > For my own code I'm going to see exactly what's going on in RCM57xx.lib and brdInit and probably just copy/modify what I need to my own project but that's what was necessary to get the samples working. I'm sure it has to do with mapping the right serial port to the serial flash, setting the IO pins, etc.
> >
> > -- Jeff
> >
> > P.S. I also had to modify FAT_CONFIG.LIB to add RCM5750 to the end of line 134 rather than deal with defining a custom driver.
> >
> > #elif (RCM4200_SERIES || RCM4400W_SERIES || RCM5400W_SERIES || BL4S100_SERIES || RCM5750)
> >
> >
> >
>
Reply by ●January 10, 20102010-01-10
On 1/10/2010 9:36 AM, ebrains2003 wrote:
> Where did you find out about the battery-backed FAT cache? I discovered this on my own with RCM3700 modules using Rabbit's FAT. The filesystem corruption was happening fairly often, always after powering up the system. On a whim, I put the battery back in the dev board (I had removed it since I wasn't using the RTC). That fixed the problem. I even reported this to Rabbit's tech support and they sounded surprised and made no mention of any cache! Is the battery requirement mentioned in their documentation?
>
Funny, there is an option to not use the cache:
#define FAT_NOCACHE // disables caching if this is defined
however, a search shows it is never used.
The docs are poor and the lib is complex. Corruption seems to be a
common problem. Almost half the users of my SD/MMC lib have written
their own file system rather than use it.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
today's fortune
Got Mole problems? Call Avogadro at 6.02 x 10^23.
> Where did you find out about the battery-backed FAT cache? I discovered this on my own with RCM3700 modules using Rabbit's FAT. The filesystem corruption was happening fairly often, always after powering up the system. On a whim, I put the battery back in the dev board (I had removed it since I wasn't using the RTC). That fixed the problem. I even reported this to Rabbit's tech support and they sounded surprised and made no mention of any cache! Is the battery requirement mentioned in their documentation?
>
Funny, there is an option to not use the cache:
#define FAT_NOCACHE // disables caching if this is defined
however, a search shows it is never used.
The docs are poor and the lib is complex. Corruption seems to be a
common problem. Almost half the users of my SD/MMC lib have written
their own file system rather than use it.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
today's fortune
Got Mole problems? Call Avogadro at 6.02 x 10^23.
