Read and Write files from the target

Miki Zilbershtein

unread,

Apr 10, 2003, 2:52:26 AM4/10/03

to

Hi,

I know it is possible but somehow I can't make it work. I am trying to
read and write files between my target and my harddisk (for debugging
purpose)

-> devs
drv name
0 /null
1 /tyCo/0
5 host:
6 /pty/rlogin.S
7 /pty/rlogin.M
8 /vio
value = 25 = 0x19
-> fp = fopen ("test.txt", "w")
new symbol "fp" added to symbol table.
fp = 0x6ffef30: value = 117436912 = 0x6fff1f0 = fp + 0x2c0
-> fprintf (fp, "hello world")
value = 11 = 0xb
-> fclose(fp)

Now my target stuck

Thanks,
Miki Zilbershtein

Joe Durusau

unread,

Apr 10, 2003, 7:42:09 AM4/10/03

to

You can do that in a program, but not in the shell. The shell
only handles integer returns, and fopen does not return an
integer. The shell is quite limited in the things that it can
do. You could (probably) use get around this somehow, but if you
compile and execute a program, you will, I think, have much better
results.

Speaking only for myself,

Joe Durusau

Miki Zilbershtein

unread,

Apr 10, 2003, 9:37:53 AM4/10/03

to

Joe Durusau <dur...@bellsouth.net> wrote in message news:<3E955891...@bellsouth.net>...

I already tried it in a program and it behave exactly the same. This
code does not work as well.

#include "vxWorks.h"
#include "ioLib.h"
#include "errno.h"
#include "stdio.h"

int hello()
{
FILE *fp;
fp = fopen("hello", "w");
fprintf (fp, "hello world\n");
fclose(fp);
}

Michael Lawnick

unread,

Apr 10, 2003, 10:20:07 AM4/10/03

to

Hi Miki,

are you aware that the connection is made via FTP? Have you checked pwd /
@pwd and ls / @ls ?
Is your target allowed to write to destination?
Try a fully qualified path like "host:test.txt"

Regards,
Michael

"Miki Zilbershtein" <mikr...@hotmail.com> schrieb im Newsbeitrag
news:b52e0856.03041...@posting.google.com...

Joe Durusau

unread,

Apr 10, 2003, 11:47:14 AM4/10/03

to

Maybe this is too obvious, but did the O.P. check the
return values from fopen and fprintf??

Speaking only for myself,

Joe Durusau

John

unread,

Apr 10, 2003, 12:38:36 PM4/10/03

to

Hello,

> You can do that in a program, but not in the shell. The shell
> only handles integer returns, and fopen does not return an
> integer.

No, that should be OK - the fopen() function returns a 'FILE *' which
will happily fit into an integer since it is only a pointer.

> The shell is quite limited in the things that it can
> do. You could (probably) use get around this somehow, but if you
> compile and execute a program, you will, I think, have much better
> results.

What the original poster didn't say was:

1) Which shell they are using (target shell or host based shell). It
looks like the target shell since there are rlogin tasks running, but
it makes a big difference to how the file system handling works.

2) What was the current working directory set to? Check this using pwd
from the shell.

3) Assuming it is set to the "host:" device that was shown in the
device list, is that using ftp or rsh. Does the user that is being
used (the one specified on the bootline) have write access to the file
system? Have you tried opening a file for read access to see if that
works?

4) If none of that makes sense, try spawning the fclose operation:

-> sp fclose, fp

Then, if it doesn't finish, you can stack trace the task to see where
it might be stuck.

One final thought, you might want to use the serial connection to the
console instead of the rlogin one. I have seen cases where problems
with the system can hang the rlogin connection (in my case it was a
printf in a network driver causing a deadlock - the driver writer
forgot that standard out might be on the network).

HTH,
John...

=====
Contribute to the VxWorks Cookbook
athttp://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/WebHome

Miki Zilbershtein

unread,

Apr 14, 2003, 3:22:05 AM4/14/03

to

Hello John,

john_...@yahoo.com (John) wrote in message news:<488e459a.03041...@posting.google.com>...

> Hello,
>
> > You can do that in a program, but not in the shell. The shell
> > only handles integer returns, and fopen does not return an
> > integer.
>
> No, that should be OK - the fopen() function returns a 'FILE *' which
> will happily fit into an integer since it is only a pointer.

I also tried it inside C program I just posted the windsh output since
I wanted to show the sequence

>
> > The shell is quite limited in the things that it can
> > do. You could (probably) use get around this somehow, but if you
> > compile and execute a program, you will, I think, have much better
> > results.
>
> What the original poster didn't say was:
>
> 1) Which shell they are using (target shell or host based shell). It
> looks like the target shell since there are rlogin tasks running, but
> it makes a big difference to how the file system handling works.
>

I am using windsh

> 2) What was the current working directory set to? Check this using pwd
> from the shell.
>

The 'pwd' in windshell shows my hard disk drive
-> pwd
D:/PresteraSw
value = 0 = 0x0
->
However the 'pwd' in the console shows bootHost:
->pwd
bootHost:
value = 10 = 0xa
shell command executed

The new devs

->devs
drv name
0 /null
1 /tyCo/0

5 bootHost:

6 /pty/rlogin.S
7 /pty/rlogin.M
8 /vio

1 /tyCo/serial0

value = 25 = 0x19

shell command executed

> 3) Assuming it is set to the "host:" device that was shown in the
> device list, is that using ftp or rsh. Does the user that is being
> used (the one specified on the bootline) have write access to the file
> system? Have you tried opening a file for read access to see if that
> works?
>

I do have read and write premissions for my ftp server

> 4) If none of that makes sense, try spawning the fclose operation:
>
> -> sp fclose, fp
>
> Then, if it doesn't finish, you can stack trace the task to see where
> it might be stuck.
>
> One final thought, you might want to use the serial connection to the
> console instead of the rlogin one. I have seen cases where problems
> with the system can hang the rlogin connection (in my case it was a
> printf in a network driver causing a deadlock - the driver writer
> forgot that standard out might be on the network).
>
> HTH,
> John...

I moved to another office and used different board and surprisingly it
start working
-> fp = fopen ("hello.txt", "w")
fp = 0xa68550: value = 117426016 = 0x6ffc760
-> fclose(fp)
value = 0 = 0x0

Now I still don't know what was the problem, but I guess that now that
I have working environment it will be easier for me to find.

Thanks for you help.

Ray Lentz

unread,

Apr 14, 2003, 6:28:40 AM4/14/03

to

Include the host name in the filename you're trying to open:
"fp=fopen("host:/test.txt","w")". You must include the host name in the name
of the path. VxWorks uses the host name to find the best match with a
device. Also, make sure your target can log onto the host as an ftp client
with write privileges, VxWorks uses ftp to write the file out.

I have found this works better:

fp=open("host:/test.txt",2)
pStr="This is a test string\r\n"
write(fp,pStr,strlen(pStr)+2)
close fp

Ray

"Miki Zilbershtein" <mikr...@hotmail.com> wrote in message
news:b52e0856.03040...@posting.google.com...