In my application I used the naftpsvr_fs example as a starting point to get a basic FTP server that could allow me to download files into the FLASH. BSP_INCLUDE_FILESYSTEM_FOR_CLIBRARY is enabled BTW. That all works fine, I can use FTP on my PC and send test files up to /FLASH0/test.txt for example.
Now I want to open those files in my DIGI ME program but I can’t get fopen(“FLASH0/test.txt”,“r”) to work - it always returns NULL. I tried various forms on the filename (no slash, backslash, etc.) to no avail. I couldn’t even get fopen to create a new file so something must be up. Is there some sort of initialzation needed to enable the CLIB interface to the file system?
Also - is fscanf supported through this interface?
What version of NET+OS are you working under? What platform are you using? If you are with one of our Connect modules, what is the serial number of the unit (e.g. MAC address)?
The only requirement for being able to use the C File I/O library functions, i.e. fopen, fread, fprintf, etc. is to set the #define, you mention above, to TRUE (or 1); and, of course one must rebuild the BSP.
By setting the aforementioned define to TRUE, the BSP will automatically create, for you, a RAM and FLASH file system (FLASH0 and RAM0). No special initialization is needed.
The development kit ships with the nafileio example, which makes use of the C library routines. What happens when you build and run this example?
I have just built and successfully ran the nafileio example on a Connect ME -C module, under NET+OS 6.3. I have devices currently up and running which are making use of these same routines under NET+OS 6.0f as well as our soon to released version 7.0.
NETOS 6.3 c/w patches, Connect ME -C dev board & GNU tools, MAC=00409D29D7D0.
The nafileio example works fine for me as well.
I discovered that I am able to create new FLASH files in my program using fopen I just can’t fopen the ones I FTP’ed to the unit. Funny thing is that while I could do an “FTP get” and read back the file I “FTP put” up in FLASH0 I couldn’t “FTP get” the file that my test code created with fopen - FTP hung. It’s almost like the two creation methods do not see one another.
I’m wondering if my FLASH0 directory is corrupted or something - how do I wipe the FLASH file system?
I also noticed that the naftpsvr_fs example I used as a basis used the NAFS function calls to do it’s file manipulations. Is this compatible with the CLIB stuff? I guess I could try the NAFS-style calls but I wanted to use fscanf (assuming it works with this).
Erasing the flash file system (FFS) is a matter of breaking into the debug session, preferably prior to the BSP trying to create the FFS. I like to set a breakpoint on customizeDialog; once the breakpoint is hit type the following command, at the GDB command prompt:
call NAFlashErase(0xXX, 0xYY)
Where 0xXX and 0xYY are the first and last sectors (zero-based) you wish to erase. What these values are depends entirely on the configuration of your BSP. By default a 256k (defined in customize.ldr) FFS is created. The FFS will be located in flash starting at the first secotor immediately following the application image. If for example your maximum boot loader size is 64k (defined in customize.ldr) and your maximum application size if 832k (defined in bootldr.dat) the FFS would be located starting at sector 17 (0x11) and end at sector 20 (0x14). This, as previously stated depends, entirely on your particular BSP configuration.
I would suspect, however, that FFS corruption is not, necessarily, your problem. From what example application, assuming you used one, did you base the FTP portion of this application? I ask this because some of the provided example application, naftpsvrapp for example, do not make use of the FFS. Instead they use a simluated file system, by way of a 2-dimensional character array; or in this particular application’s case simply a large RAM allocation, into which your uploaded file is stored.
I put a breakpoint on customizeDialog and typed
call NAFlashErase(0x11, 0x14) (I’m using defaults)and got back “$1 = 0” but it didn’t work - the FLASH files were still there.
I used naftpsvr_fs as my basis (see my previous post). I guess one could go back to that and add fopen tests to it and see if that works.
Alternately, one may wish to initially attempt to open the file using the “r” flag. If the returned file pointer is NULL, the file does not exist and one would have to attempt to reopen the file using the “w” flag, so that the file can be created. This is assuming that you want to do nothing if the file already exists.
My mistake, I should have confirmed the information regarding where the FFS is located, by default, in flash.
The FFS, by default, will be located at the end of flash, immediately preceeding the NVRAM sector (which is defaulted to the last sector. So, for example, on the Connect ME the FFS will be located starting at sector 0x1E and end with sector 0x21.
I have attached a modified version of the root.c file, provided with the naftpsvr_fs example. This version of the application works properly, per my understand of your desired behavior.
It attempts to fopen the file using the “r” flag. If the file exists nothing is done, otherwise fopen is called again, using the “w” flag and data is written to file. The file is closed and subsequently can be retrieved via FTP.
I think I figured out the problem - it was the group number. When I did a dir in FTP I noticed that the file I put to FLASH0 was group1 but the test file that fopen created was group2. When I switched the file I put up to group2 I could open it with fopen.
Question is why do the groups matter and how do I control what group a file is put in when I FTP or fopen it? I log in with the “allgroup” user setup as follows:
status = NAsetSysAccess (NASYSACC_ADD, ALLGROUP_USERNAME, ALLGROUP_PASSWORD, NASYSACC_FS_SUPER_USER | NASYSACC_LEVEL_RW, NULL);
Should I modify the BSP startfilesystem.c settings to use group1 for FLASH0 as well - is that OK to do?