Shared-Memory Objects

Problems with shared-memory objects can be due to a number of causes. This section discusses the most common problems and a number of troubleshooting tools. Often, you can locate the problem by rechecking your hardware and software configurations.

Refer to the following list to confirm that your system is properly configured:

Be sure to verify that the constant INCLUDE_SM_OBJ is selected for inclusion in the project facility VxWorks view for each processor using VxMP.

Be sure the anchor address specified is the address seen by the CPU. This can be defined with the constant SM_ANCHOR_ADRS in the Params tab of the properties window or at boot time (sm=) if the target is booted with the shared-memory network.

If there is heavy bus traffic relating to shared-memory objects, bus errors can occur. Avoid this problem by changing the bus arbitration mode or by changing relative CPU priorities on the bus.

If memAddToPool( ), memPartSmCreate( ), or smMemAddToPool( ) fail, check that any address you are passing to these routines is in fact a global address.

Use the following techniques to troubleshoot any problems you encounter:

The routine smObjTimeoutLogEnable( ) enables or disables the printing of an error message indicating that the maximum number of attempts to take a spin-lock has been reached. By default, message printing is enabled.

The routine smObjShow( ) displays the status of the shared-memory objects facility on the standard output device. It displays the maximum number of tries a task took to get a spin-lock on a particular CPU. A high value can indicate that an application might run into problems due to contention for shared-memory resources.

The shared-memory heartbeat can be checked to verify that the master CPU has initialized shared-memory objects. The shared-memory heartbeat is in the first 4-byte word of the shared-memory object header. The offset to the header is in the sixth 4-byte word in the shared-memory anchor. (See VxWorks Network Programmer's Guide: Data Link Layer Network Components.)

Thus, if the shared-memory anchor were located at 0x800000:

[VxWorks Boot]: d 0x800000 
800000: 8765 4321 0000 0001 0000 0000 0000 002c *.eC!...........,* 
800010: 0000 0000 0000 0170 0000 0000 0000 0000 *...p............* 
800020: 0000 0000 0000 0000 0000 0000 0000 0000 *................*

The offset to the shared-memory object header is 0x170. To view the shared-memory object header display 0x800170:

[VxWorks Boot]: d 0x800170 
800170: 0000 0050 0000 0000 0000 0bfc 0000 0350 *...P...........P*

In the preceding example, the value of the shared-memory heartbeat is 0x50. Display this location again to ensure that the heartbeat is alive; if its value has changed, shared-memory objects are initialized.

The global variable smIfVerbose, when set to 1 (TRUE), causes shared-memory interface error messages to print to the console, along with additional details of shared-memory operations. This variable enables you to get run-time information from the device driver level that would be unavailable at the debugger level. The default setting for smIfVerbose is 0 (FALSE). That can be reset programmatically or from the shell.

6.5 Troubleshooting

6.5.1 Configuration Problems

6.5.2 Troubleshooting Techniques