Time for some new problem solving.
(basic: the application is running on a connectcore 9c using Net+Os 6.3)
I don’t get any response from the NAFS after calling NAFSwrite_file() and using the NAFSinit_io_request_cb() when running the application without debugger. I don’t have any trouble calling the same routines when using the debugger, but the application hangs every time I try to call NAFSwrite_file() without the debugger.
I have a similar problem trying to use the ftp-server when running the application without the debugger (again everything works perfectly using the debugger - a Majic running gdbtk). Connecting to the ftp isn’t any trouble, nor is reading from the server. But when I try to write to a file on the server my ftp program usually times out. Perhaps the ftp server doesn’t get any run time from the OS, because the other 4 tasks take too long… It would be understandable for the ftp, but why would the file system be dependent on which tasks are running?
I have been suspecting that my application was running from rom since that would be a hugh difference from running using the debugger, but I can’t seem to find anything in the makefiles or bootloader files that confirms the theory.
If my application is in flash I can’t run the debugger (i.e. I need to shortcut the board and download the ftp example to be able to run the application through the debugger again), which again hints at some kind of mistake when downloading the application. If you believe that my problems might occur because of a missed step in compile/download I’ll post the procedure I’m using.
Hoping for some kind of ideas…
“overwrite doesn’t work”… Is that true? That would certainly explain why I can’t write to the file - as all I wanted to do was to edit a line… Wierd that it works when I’m using the debugger though…
I’ll check if the mods work… I hope so…
I still seem to have exactly the same error…
Deleting and creating works fine, just like the following open() command… But when I try to write I don’t get any callback… Annoying to say the least…
From what I can make out of the documentation I need to call open() before I call write(), as I need to have a valid file descriptor.
I’m more and more falling back to my old ideas that there’s something wrong with the bootloader/rom-image/ram-image I’m using… I read through the “porting” guide yesterday and found the “boothdr” utility, but when I try to use the image that has been modified using the boothdr I don’t get any application running at all. Do I need to change the bootloader is any way to run a valid application (created using the boothdr) from ram? The images I’m able to run are the pure image.bin I’ve created along with the image.elf (but with the bsp set up for non-debug).
From what I can make out of the documentaion these images are set up for running from rom. That’s why you’re supposed to run the boothdr utility, isn’t it? Then what do I need to do to get the boodloader to understand that it’s supposed to make my boothdr modified image run from ram? I’m using the standard bootloader image.rom from bsp/platforms/connectcore9c_a.
In NetOS 5 and 6.0 there were several issues with the filesystem. I don’t know if they are fixed with 6.3.
The Filesystem blocks of memory need to be specifically ERASED before being used as a filesystem. The code on the end of this note does that. Call it once on initial use of the module. (I have it as the “format” command from my command shell.)
I noticed in 6.3 that NetOS does not like to overwrite files. I had to modify my code to delete the file then write it out again new. (The overwrite worked in 6.0??!!??)
Remember to call the NAFSinit_io_request_cb() BEFORE calling NAFSwrite_file(), and use the NAFSio_request_cb_status() afterwards.
Maybe you should use the compatibility C functions that take care of all that for you - open(), write(), etc.
int numberSectors = NAFlashSectors();
WORD32 *sectorSize = (WORD32 *)malloc(sizeof(WORD32)*numberSectors);
long nStartAddress = NABspFileSystemStartOffset();
long nEndAddress = nStartAddress + (NABspFileSystemSize-1);
int nStartSector = nStartAddress/0x4000;
int nEndSector = nEndAddress/0x4000;
long nAddress = 0;
int s = 0;
for(; s < numberSectors; ++s)
if( nAddress >= nStartAddress && nAddress < nStartAddress+sectorSize[s] )
nStartSector = s;
nAddress += sectorSize[s];
for(; s < numberSectors; ++s)
if( nAddress >= nEndAddress && nAddress < nEndAddress+sectorSize[s] )
nEndSector = s;
nAddress += sectorSize[s];
if( nEndSector == numberSectors-1 )
if( nEndSector < nStartSector )
nEndSector = nStartSector;
// Reassure the user
printf(id, "Erasing FLASH sectors %d to %d…
", nStartSector, nEndSector);
// Zap the old image
int result = NAFlashErase(nStartSector, nEndSector);
// Did it work?
if (result != NAFLASH_SUCCESS )
printf(id, "FLASH Erase Error %d. - ", result);
case NAFLASH_UNKNOWN_FLASH: printf(id, "Invalid FLASH Hardware
case NAFLASH_SECTORNUMBER_INVALID: printf(id, "FLASH Sector number invalid
case NAFLASH_ERASE_FAILED: printf(id, "FLASH Erase failed
default: printf(id, "
“I had to modify my code to delete the file then write it out again new.”
Do you create the file before writing it, or do you simply write directly after deleting it (and thus the file is created when it is written to)?
I am using the ME but it should be the same.
The default BSP works just fine. It defines the RAM0 and the FLASH0 devices.
Yes, you need to open a file to write it. The issue I had was that if I opened an existing file, it wouldn’t write (it returned success but didn’t write). Only when I opened a completely new file. So what I was doing was reading in the old data, modifying it, deleting the file, then opening a new copy then writing it back out.
So you’re not creating the new file between deleting and opening it? Hmmm… I didn’t believe that would work, but it’s worth a try!
I open it with O_RDWR and O_CREAT.