fopen(,"w") with grun

Hi!To build a simple diagnose tool to read contents out of our flash device and store it in a file in the host file system, we use fopen(FILENAME, “w”) to open the host file. We run the application using GRUN. Reading a file on the host using fopen(FILENAME, “r”) works fine, but opening a file for WRITE (on the host) doesn’t. fopen(FILENAME, “w”) returns NULL. I supply the piece of code including the two fopen() calls. My host system is a NT4.0 Workstation, the connection to our target is via a Raven. What could be wrong? Any hints would be greatly welcome.

Can’t seem to open the attachment.

Hi Martin, we encountered similar problems with our NET+OS-based systems here. Surprisingly all file operations did work fine as long as we used them in plain projects without all the NET+OS functionality. But even in the simplest “hello world” applications using the NET+OS framework the fopen(filename, “w”) wouldn’t work any more. Some tracing on assembler level in the fopen()-function revealed problems with a ftrylockfile()-call (returned -1 in r0) somewhere within the function’s code. While we were trying to comprehend the reason for this behaviour, we finally found a description of the library functions available (somewhere in the Green Hills directories) – and although there seemed to be no errno-variable defined, the perror()-function was. It displayed “: No such file or directory” after our failing fopen()-call. And even though it shouldn’t have been necessary, we pre-created a dummy target file with the name that was given as the first parameter of the fopen()-call: And suddenly the fopen()-error was gone and we could write to the opened file. It seems to be as if the fopen(,“w”)-function still expects the target file to exist, even with the “w”-Argument. It’s not such a nice work-around, but I hope it will be helpful. Perhaps Netsilicon could enlighten us on the reasons behind this behaviour? Best regards Stefan

Yep, that worked! Thanks a lot! Martin