March 16, 2001

Overview

Release 3.4.0 of the Empack software includes Version 3.4.0 of the host libraries and Version 3.4.0 of the Embedded Firmware and FPGA configurations.

The following changes are introduced in this release:

• Bug fixes for API functions that read TDM maps and parameters.

• New TDM operational API functions.

• Bug fixes for API functions that read codec levels and registers.

• Bug fix in embedded code for DSP32C data transfer.

• Modifications to handle different DSP32C external memory configurations.

• Modification to the EmEnumEmpack API function.

• Modifications to the eminit utility program.

• Modification and problem fixed for the emflash utility program.

• Fixed a problem with Solaris device references.

• Improved device access control for Solaris.

• Integrated support for Windows 2000.

• New and modified Empack diagnostic programs.

Notes:

This release includes additions to the Solaris device driver interface that are required by the new version of the API. Customers using the Solaris operating system on Sparc or Intel platforms should build and install the new version of the device driver.

This release includes new embedded code. Customers should run the emflash utility after installation in order to avoid version mismatch errors. Customers with DM12C549 modules types on EMPCI mezzanines must also run empciflash to update the configuration stored in the mezzanine's flash memory.

See the Empack Utility and Diagnostic Programs manual for complete information about utility and diagnostic programs mentioned here.

Bug Fixes for API Functions that Read TDM Maps and Parameters

The EmReadTdmMap function now correctly reads the TDM Map data stored on Empack modules. It is also enhanced to read the additional TDM control information from the Empack base module. This additional information includes the bus selects for E1 and T1 framers and SCSA and the special SCSA modes such as combining framer and TDM data. It is stored in the module handle so that subsequent TDM map writes will include the proper mode settings.

The EmSetTdmMode function now allows a value of 0 of the MFrame parameter to specify no multi-frame pulses. It is the same as specifying a value of 1 frame per multi-frame.

The EmGetTdmMode function now reads the actual TDM mode settings from the hardware. The values of the mode settings are stored in the Empack handle as well as returned to the application for the relevant parameter pointers are passed to the function.

New TDM Operational API Functions

The following new TDM functions are added to the API. They are primarily intended for debugging and other special purposes.

The EmTdmIsMapCur function determines if the TDM map data for the specified module is current with the Map data stored in the API.

    EM_STATUS EmIsTdmMapCur (
        MODULE_HANDLE Module,
        int *Status )

Module specifies the module and Status is a pointer into which the result is stored. Status will contain a 1 if the TDM map on the module is current or a 0 if changes made to the Map have not been updated on the hardware (by calling EmWriteTdmMap or EmStartTdm).

The EmGetTdmBank function determines current active TDM bank number for the specified module.

    EM_STATUS EmGetTdmBank (
        MODULE_HANDLE Module,
        int *Bank )

Module specifies the module and Bank is a pointer into which the result is stored. Bank will contain either a 0 or a 1, indication the current active bank on the module. This function is only valid for EM6X32, EMC12 or EMPCI modules types.

The EmSwitchTDMBank function forces the active TDM bank to be switched for the specified module.

    EM_STATUS EmSwitchTdmBank (
        MODULE_HANDLE Module )

Module specifies the module for which to switch the TDM bank. This function is only valid for EM6X32, EMC12 or EMPCI modules types.

Bug Fixes for API Functions that Read Codec Levels and Registers

The EmGetCodecLevels function is fixed to return the proper values to the application.

The EmReadReg function is fixed for reading indirect registers from the CS4231 codec chips on EMC12 modules.

Bug Fix in Embedded Code for DSP32C Data Transfer

A bug was fixed in the Empack embedded code that could, under some circumstances, corrupt data or register settings on another module when DSP32C memory is accessed after an access to the affected module.

The only known occurrence of this problem was when memory for a DSP32C on a 6X32C module was read following a read of the TDM map on an EMC12 module.

Handling Different DSP32C External Memory Configurations

Previous releases of the Empack software based on the VME9U12 and VME6U6 software did not account for the additional memory available for the DSP32C chips on the Empack platform.

One of the issues is the memory map used for linking DSP32C programs. The memory map file distributed with the Empack software (found in $CAC/empack/mod_support/dsp32c/mem32em.map) provides a linker map for 512 Kbytes of external memory. It includes comments describing restrictions on modifying the memory map for using the additional memory available on the 1 Mbyte and 2 Mbyte memory configurations.

The other issue is the memory address used for the LEDs. Previous releases used the address, 0x87fffc. This address aliases to the last word of physical memory for a 512 Kbyte configuration and would force a gap in the usable memory beyond 512 Kbytes.

To remove this restriction, the memory address for the LEDs is changed to 0x9ffffc. This address aliases to the last word of physical memory on 512 Kbyte, 1 Mbyte and 2 Mbyte configurations.

The new definition of the LED address is used in the EmSetLED API function and appears in the API header file, $CAC/include/emapi.h. It is also defined and used in the DSP32C start-up code distributed in the file, $CAC/empack/mod_support/dsp32c/crt0_32em.s.

Customers using their own versions of the DSP32C start-up code should incorporate this change to insure that both the DSP and API use the same address for the LEDs if it is necessary for the host and DSP to share information stored and the LED address.

Modification to the EmEnumEmpack API Function

The operation of the EmEnumEmpack function has been modified in order to work properly with the changes made to solve the problems described under "Solaris device references".

The funtion now maintains a local index into the device array and only returns Empack names for devices that are installed. The index parameter to the function is only significant when it's value is 0.

The index parameter now serves as an enumeration initializer. When EmEnumEmpack is passed an index value of 0 it resets it's local index value to begin enumerating Empack device names from the first installed Empack. Subsequent calls to EmEnumEmpack with an index value greater than 0, continue the enumeration from the index of the previously found EmPack.

The only significance this has for existing application programs, which are written to increment their value of the index parameter, is that the application's value of the index parameter may not correspond to the actual index in the device table for the Empack name returned by EmEnumEmpack.

Modifications to the Eminit Utility Program

Three changes are made to the eminit program.
1. Empacks are left in the SCSA slave state to avoid contention on the SCSA clock and sync signals when multiple Empacks are connected via SCSA expansion.
2. A new -v option is added which has the program report the name of each Empack as they are initialized to provide feedback about the Empack units that are successfully initialized.
3. More than one Empack name may be specified on the command line to be initialized. Specifying no Emapcks on the command initializes all Empacks found, as in previous releases.

Modification and Problem Fixed for the Emflash Utility Program

The emflash program exhibited a problem under Solaris 2.6, with some Sbus SCSI interfaces, which would cause it to hang. This release includes a fix for the problem that works with the configuration we were able to test.

Emflash will now prompt the user before replacing a beta version of code loaded in flash if it is newer than the most recent released file version.

Fixed a Problem with Solaris Device References

This release includes a fix for a problem under Solaris which would cause some SCSI commands to be sent with incorrect device references. This problem would occur if the installed Empack IDs were not sequential and was reproducible in the emroundmem diagnostic.

To solve the problem, the API's internal table of Empack devices is created with entries for the uninstalled device IDs that are marked as non-existant devices. This is done to maintain a one-to-one correlation between the indices into the table and the device ID numbers. This modification requires a change to the EmEnumEmpack API function.

Improved Device Access Control for Solaris

The Empack API maintains access control of the logical Empack devices (emp00, emp002, etc) used by applications. Since the API is not informed when a process exits, Empack devices could be left in a busy and inaccessible state if an application terminates without closing all of the resources, modules and Empack units it opened. Although such "stuck" resources would be released after the last program using Empack devices terminated, it might not always be possible or desirable to terminate all Empack applications.

This release addresses this issue with additions to the device driver and the API functions involved with device access, the EmOpen... and EmClose... functions for Empack, Module and Resource. Process reference handles are maintained by the device driver for application that has opened an Empack device. When a request is made to open a device that the API has marked as "in use", the API will ask the device driver to test if the process using the device is still active. If it is not active the API will allow the new process to access the device.

It is still recommended that applications close any Empack devices they are no longer using with the EmClose... functions but these changes provide a fail-safe.

Integrated Support for Windows 2000

Windows 2000 is now supported along with Windows NT and Windows 95 in the single "win32" distribution package.

New and Modified Empack Diagnostic Programs

Please review the updated Utility and Diagnostic manual for more information about the diagnostic programs.

empiomem

Modified to continue testing after the first error is found and report the total number of errors. Details of errors are reported for a configurable number of errors per resource. The default number of error details is one and may be changed using the new -e option.

The new -i option has the program skip testing internal DSP32C memory. The new -s option has the program run the self-address test only. The new -p option has the program pause and wait for the user to hit enter at certain points during the tests.

emroundmem

The maximum number of Empacks that may be tested at one time (connected via SCSA) is increased from 6 to 8.

The initialization sequence for a test involving multiple Empacks is modified to to ensure that no two Empacks are SCSA master at the same time. However, it is recommended that the eminit program be used before testing a single Empack that is connected via SCSA to other Empacks.

emscp

The ability to use two different EMC12s on two different Empacks has been added. The command line arguments have been simplified for specifying two EMC12 modules.

emfft

This new diagnostic program performs comprehensive tests on the codecs of an EMC12 module. DSP32Cs are used to send a series of tones to the codecs, which loop the analog signals back to themselves (or codecs on another EMC12) and return the data to the DSPs. The DSPs then use FFT to check the frequency components, magnitudes and noise in the returned data.

Tests are run at various sample rates, digital data formats and combinations of input and output levels.

emburn

The emfft diagnostic is added to the tests performed. A -L option is added to have emfft exclude tests involving the line inputs avoiding error reports for modules that have not been upgraded with the correct resistor values.

The embasediag program is run with arguments to exclude the external SCSA loop-back test if SCSA testing is disabled with the -S argument to emburn.

The program is fixed to exit after all Empacks have completed a specified number of passes and to skip E1 or T1 framer tests for Empacks populated as back-end-only units, with no framers.

emled

Added the -n command line argument to specify the number of iterations to run. The default behavior is to run continuously.

emchip and emscsaloop

These programs are modified to call the EmAttachAPI function after command line arguments are processed so that usage errors can be reported without having to attach to the API.