MVME 162-262 VxWorks Ethernet Communication Problem

VxWorks

    Sponsored Links

    Next

  • 1. VxWorks 5.3.1 shared libraries
    Hi all, I'm porting an application from Linux to VxWorks 5.3.1 and I need to make the footprint fit into 25 MB. Are shared libraries supported by 5.3 ? If so, can somebody point me to some code & makefile that uses them ? Regards, Bob Beck XXXX@XXXXX.COM
  • 2. errno for task tJmain in tasklist says 110001 (S_memLib_NOT_ENOUGH_MEMORY)
    Hello, I'm using PJWorks 3.1/vxWorks 5.4.2 on a x86 target with a moderate memory usage application (heap ~500kB w/ 3MB allocated, stack ~128BK). Directly after startup of the task I encounter that the errno is 110001 (S_memLib_NOT_ENOUGH_MEMORY). However a printout of the free memory suggests to me that there is plenty of heap memory available (~2,5MB) and also stack should not be a problem. I have disabled stack checking in the Java VM config for performance reasons. Has anyone else seen this with his Java app ? Should I worry about the errno ? Otherwise the Java program runs just fine and eventually the GC frees unreferenced objects as expected. Thank you for your comments, Ingo. PS: "i"-info: NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY ---------- ------------ -------- --- ---------- -------- -------- ------- ----- tJmain 1b9f124 1afd008 80 PEND 124e78 1afcf88 110001 0
  • 3. A problem about using vxWorks's loader function loadModule?
    After Configuring vxWorks with #define INCLUDE_LOADER,I use the code segments to download a object module from host machine: int fd,result,err; netDevCreate("wrs:", "host", 1);/*1 means use ftp*/ fd = open("wrs:D:/Tornado/target/proj/Project6/I80486gnu/test.o",O_RDWR,0); result = loadModule(fd, LOAD_GLOBAL_SYMBOLS); err = errnoGet(); printErrno(err); Having used Tornado's debugger,I got the following result,result=0,err=0x3d0001,printErrno=""S_objLib_OBJ_ID_ERROR".can somebody explain me what the meaning of "S_objLib_OBJ_ID_ERROR",: loadAoutLib error: can't add 'test.o_text' to system symbol table - error = 0x3d 0001. loadAoutLib error: can't add 'test.o_data' to system symbol table - error = 0x3d 0001. loadAoutLib error: can't add 'test.o_bss' to system symbol table - error = 0x3d0 001. loadAoutLib error: can't add '_test' to system symbol table - error = 0x3d0001. undefined symbol: _printf S_objLib_OBJ_ID_ERROR
  • 4. POST_BUILD_RULE within
    I am using Tornado 2.2.1 I do not succeed to define the POST_BUILD_RULE macro (within BUILD properties) to run 2 successive commands. Is it possible ? If yes then how ? Thanks, Martin Roth Motorola Israel
  • 5. FIN_WAIT_1 problem.
    Hello seniors? I've got some problem with TCP Socket. I work with VxWorks 5.5 and goahead webserver 2.1.8. When I requset web page, pages are loading but now all. Page are loading but are now shown. So I tested inetstatShow command. And I found "FIN_WAIT_1" with some data in Send-Queue. I can't solve this problem. Plese give me some advice please. Regards, YongWook ps. tNetTask is priority 50 So, What priority should I put for user WebServer?

MVME 162-262 VxWorks Ethernet Communication Problem

Postby benjamin.arrow » Tue, 16 Sep 2008 12:40:58 GMT

Hi Guys

Last resort posting:

I have one MVME board that has come in from the field, the board will
boot and load the OS from our BootP server just perfectly.  I can ping
the ethernet interface of the MVME card with correct response however
whenever i try to communicate with the MVME card using our specific
software which tries to communicate over IP , the software will
timeout.

I have a second MVME card with exactly the same revision chips and
firmware, this card will communicate just fine.  I am beginning to get
stuck as I have never seen an MVME card until last week.

Is there any diagnostic functions or any help you may be able to
provide in regards to troubleshooting an MVME card using VxWorks and
running across Ethernet?

Cheers


Re: MVME 162-262 VxWorks Ethernet Communication Problem

Postby noisetube » Wed, 17 Sep 2008 03:34:40 GMT

n Sep 14, 8:40 pm, XXXX@XXXXX.COM wrote:

The very first thing you should have done is gone out and gotten
yourself a copy of Wireshark (www.wireshark.org) and captured the
traffic between the target board and whatever host it is that runs
your "specific software" so that you can analyze and diagnose the
actual communications failure. It sounds like this problem is
repeatable, so you should be able to capture several runs (the more
failure cases you can examine the better), and you can compare it to
successful runs from working boards.

There are certain key pieces of information which you have not
provided (or possibly considered):

- What kind of host is your BootP server running on? (Windows? UNIX?
What version?)
- What kind of host is your "specific software" running on? (Windows?
UNIX? What version?)
- How is the target connected to the BootP host and the "specific
software" host? (Are they all on the
same subnet? On different subnets? All plugged into the same switch?
All plugged into a hub?)

My money says that the MAC address on the bad board has been corrupted
somehow. This is something you would be able to detect by sniffing
packets from the target using Wireshark. There are some MAC addresses
which are invalid to use as station addresses, e.g.:

ff:ff:ff:ff:ff:ff
00:00:00:00:00:00
01:xx:xx:xx:xx:xx

or various combinations thereof. Check the first 3 bytes: if they
don't match the vendor OUI for the board, then the address is
definitely wrong. (You can check the OUI for a given manufacturer by
checking the IEEE database here: http://standards.ieee.org/regauth/oui/index.shtml)
Note however that not every OS, protocol or piece of networking
hardware fails in the face of an invalid MAC address in the same way.
Some may allow the bad frame through, while others may discard it. So
it is very possible that the bad address does not stop the target from
being able to download a VxWorks image, but does interfere with your
"specific software." I have seen this happen before, and it always
leads to confusion until someone finally decides to capture a packet
trace.

As to how the MAC address may have been corrupted, that depends on
where it's stored. According to the information I have, the MVME162
board uses an Intel 82596 ethernet chip, and the MAC address, along
with a few other pieces of board-specific information like the CPU
speed, is stored in an ST Microelectronics MK48T08 battery-backed RAM
chip (BBRAM). This chip also contains the time of day clock. I found a
copy of the datasheet here:

http://www.datasheetarchive.com/datasheets/Datasheet-019/DSA00326409.pdf

Depending on the age of the actual part that you have, it could be
that the built-in battery has reached the end of its useful life. (If
the device was manufactured in the early 90s, then it'd be maybe 15
years old now.) If this is the problem, then you'll need to replace
the whole chip since the battery isn't meant to be removable. I don't
think the original MK48T08 is still in production, but it looks like
the Dallas Semiconductor/Maxim DS1643 is a drop-in replacement. You
can order them here:

https://shop.maxim-ic.com/storefront/viewpriceavailable.do;jsessionid=c0a80b0130d8309aaf362d9e4ad881f6a14abadcdfdc.e38Kb34Ta34PbO0LbN8SaNuKchmPe6fznA5Pp7ftolbGmkTy#

(Note: Tornado 2.2.x/VxWorks 5.5.x was the last release to support the
m68k CPU (and the MVME 68k-based boards). If you are the one who
produced


Return to VxWorks

 

Who is online

Users browsing this forum: No registered users and 39 guest