User`s guide

Dialogic
®
System Release 6.0 PCI for Windows
®
Release Update, Rev 62 — January 30, 2008 179
Dialogic Corporation
Changing a board’s characteristics (e.g., increasing/decreasing the number of devices) is
not allowed when performing a single board start/stop operation. No loads or any
parameter changes that could impact the density are allowed, otherwise download will fail.
If this has to be done, then the entire system has to be stopped and restarted.
Addressable unit identifiers (AUIDs) may change for virtual boards (e.g., dxxxB4) and
virtual devices (e.g., dtiB2C3) after a single board stop/start. After each single board
stop/start, the board name (e.g., brdBx) and AUID should be retrieved in order to perform
any board operations (brd_SendAlive( ), brd_Open( ), etc.). For information about
AUIDs, see the Dialogic
®
System Software for PCI Products on Windows
®
Administration
Guide. For information about brd_SendAlive( ) and other brd_ operations, see the
Dialogic
®
Board Management API Library Reference.
Notes:1. To use the single board start/stop feature, each board in the system must have a unique
Board ID. For information about setting Board IDs, see the Dialogic
®
Quick Install Card
that comes with the board.
2. Single board start/stop does not work if Start Selective (Good Devices Only) has
been specified from the DCM Settings menu.
3. Single board start/stop is supported only in H.100 (CT Bus) mode. The bus mode is
specified by the TDM Bus Type (User Defined) parameter in DCM.
Recommended and Mandatory Operations
This section describes mandatory and recommended procedures that must/should be
followed when performing a single board stop/start operation.
• Before stopping any board, all active devices (i.e., devices that have been opened and
have a valid handle opened retuned from the open request) must be closed prior to
issuing the stop request. It is the responsibility of the calling application to ensure that
each device associated with the target board is closed via a device_close API call
(e.g., dx_close ( )).
• It is recommended that a stop also be invoked on any active device prior to issuing a
stop board request. In the case of a firmware assert, this is not required, as there is no
guarantee that a response will be sent from the firmware. Nevertheless, it is good
practice to issue both a stop, and then a close prior to issuing a stop board request.
The recommended sequence is as follows:
a. Perform a stop on all active devices (e.g., dx_stop( )).
b. Perform a close on all active devices (e.g., dx_close( )).
• It is mandatory that the application perform a device close on all active devices.
Note: Performing a single board stop/start could potentially result in unrecoverable memory
(approximately 5K per active device) if active devices are not closed prior to the single
board stop/start. This could eventually lead to degraded system performance over
extended periods of time.