I am using DigiESP and create a New Project, enabling HTTPS and FTP servers. I make sure the FLASH_FILESYSTEM_ENABLED and BSP_INCLUDE_FILESYSTEM_FOR_CLIBRARY are both TRUE so that I can have a Flash file system.
When the HTTPS initialization code runs, it checks to see if there is an SSL certificate present. Since on first run, there isn’t one, it creates one. Then it calls a function to save that certificate, which in turn calls the function below.
static int writeFile(int file_length, char *file_data, char *file_name)
{
size_t bytes_written = 0;
FILE *file = NULL;
// Open the file
file = fopen(file_name, "wb");
if (file == NULL) return -1;
…
The problem is, the fopen call is returning 0, which indicates that the file is not being created.
From the debugger it is trying to save “FLASH0/.cfg/ssl.cert”.
The folder should exist, because this is called:
int FileSystem_InitVolume(void)
{
// We require the CLib support for the file system
if (NABspFilesystemForCLib == 0)
{
printf("CLib file system not enabled!
");
return NAFS_VOLUME_NOT_INITIALIZED;
}
// Create the directory that will hold configuration files.
//TODO: how do we set authorities to this directory.
mkdir(FS_FLASH_VOLUME_CONFIG_DIR, O_RDWR);
return NAFS_SUCCESS;
}
But, adding an error check to the mkdir shows it is returning -1.
What am I missing?
Please step through the code in mkdir() which calls nat_fs_mkdir() in nafs_intf.c and find out where the code is failing. Make sure you turn optimization off for the BSP to step through code.
The nafs_intf.c file has had several corrections since 7.0; did you try this in 7.1? I attached a newer 7.0 version of the file. Do a diff on your version.
Can you use the FTP server to verify if the file creation really failed? There has been a bug some time ago, that made fopen() report failure when it created a new file - but it only reported failure, the file was actually created. It did require a reboot of the device before the file would become accessible for anything useful.
Check if you have Net+OS 7.1 and all of these fixes (you can check under another device type, but I think the fix list will remain the same): http://www.digi.com/support/productdetl.jsp?pid=2795&osvid=135&tp=6&s=103
I don’t have 7.1. When I asked about it, I was told it wasn’t released. If it has been released, I wasn’t informed (apparently Digi doesn’t go out of its way to let anyone know anything is new).
However, I believe I had found the problem already, and it was in the auto-generated initialization code. I had to turn on some things in, if I remember correctly, the appconf.h that were supposed to be set by the DigiESP but weren’t. It has been too long, and I don’t remember what wasn’t set correctly. Sorry, I’d post it here if I remembered.
7.1 was released more than a month ago.
I ordered an additional jumpstart kit some time ago, it arrived around mid-April with 7.1 in the box. I already had an upgrade from 7.0 to 7.1 for my other kit before that.
It’s a bit strange that on their website, the ‘current’ version still seems to be 6.3.
http://www.digi.com/products/embeddedsolutions/networks.jsp
The fopen issue was corrected in 6.3 in a patch: http://ftp1.digi.com/support/patches/BSPFixes_63.htm as well as 7.0: http://ftp1.digi.com/support/patches/BSPFixes_70.htm
As far as I’m aware it should be included in 7.1 as well.