When running DebugAngel on a system with either HMP or DM3 boards, firmware warning and error messages are often capture in the log. Because of the logging syntax, it is not possible to determine which particular device an error occurred on with the DebugAngel log alone.
By capturing a devmapdump, it is possible to correlate the DebugAngel error with the Dialogic device it happened on. The following use case shows us that failure happened on the voice resource
dxxxB4C4, and we can then filter the application/RTF log for this device, and study what its behavior was prior to the failure:
Use case #1
First, we need to find the “source” line in the DebugAngel message header after the error occurs:
11:50:20.046| 000:CP1:***************************
11:50:20.093| 000:CP1:QERROR_WARNING(2) qkernerr.h 31024 qkernerr.h 31005
11:50:20.093| 000:CP1: Error Level : WARNING
11:50:20.093| 000:CP1: Location Tag: 31024, Location File: qkernerr.h
11:50:20.093| 000:CP1: Cause-Tag : 31005, Error File :qkernerr.h
11:50:20.093| 000:CP1: TaskName is Player
11:50:20.093| 000:CP1:ERROR- Mso Manager, Message Undeliverable!
11:50:20.093| 000:CP1:Warning: above information may indicate more than one event.
11:50:20.093| 000:CP1:***************************
11:50:20.093| 000:CP1:Message Header, printed by a task Player
11:50:20.093| 000:CP1:encoding 0x2
11:50:20.093| 000:CP1:priority 0x43
11:50:20.093| 000:CP1:version 0x65
11:50:20.093| 000:CP1:transaction 0x108
11:50:20.093| 000:CP1:source 0:0:1:11:16, task name Player
11:50:20.093| 000:CP1:destination 0:0:3:7:1, task name unavailable
11:50:20.093| 000:CP1:type 0x8
11:50:20.093| 000:CP1:size 8
11:50:20.093| 000:CP1:***************************
The address in this line has the following format:
<node> : <logical ID of board> : <processor> : <component> : <instance>
So, in the above example of 0:0:1:11:16,
node = 0
logical ID = 0
processor = 1
component = 11
instance = 16
We then need to retrieve a device map dump from the problematic machine. To output this to a text file, make sure the Dialogic services are started, and then go to the command line and type
devmapdump > [path]\[filename].txt where [path] is the desired drive and path of the output location, and [filename] is the desired filename. For example:
devmapdump > C:\temp\devmap1.txt
The device map dump has somewhat of a complex address display format. The values are in hex, and are listed as follows:
<instance> <board> <pad1> <processor> <component> <node> <pad 2>
All of the values are 8 bits, except for the <instance> value. This is 16 bits, but it is displayed with the least significant
BYTE first. So for example a value of 0F 00 would correspond to a decimal value of 15.
From our DebugAngel log, we know that we are looking for a Player address, with a decimal <instance> value of 16. Converting this to hex, and putting in a least significant byte first format, we know that this will show up in the device map dump as
10 00. Searching through the device map dump, we find this information here:
\-- <
dxxxB4C4> -- <50149>
| | CALLANALYSISADDR = 10 00 00 01 01 11 00 77
| | CALLERIDADDR = 10 00 00 00 01 10 00 77
| | CLUSTERADDR = 9B 00 00 00 01 03 00 00
| | CTBUSADDR = 88 00 00 00 01 04 00 77
| | CTBus_RcvTimeslot = FF FF FF FF
| | CTBus_TxTimeslot = 87 00 00 00
| | CTBus_TxTimeslot_Port2 = FF 00 00 00
| | CTPLATFORM = DM3
| | EncodingType = 01 00 00 00
| | FEPADDR = 10 00 00 00 01 0F 00 77
| | FrontEndType = 02 00 00 00
| | JACK_NUMBER = 00 00 00 00
| | NAME = dxxxB4C4
| | OpenCount = 00 00 00 00
| | PLAYERADDR =
10 00 00 00 01 0B 00 77
| | R4_VISIBLE = 01 00 00 00
| | RECORDERADDR = 10 00 00 00 01 0C 00 77
| | SIGBUFADDR = 10 00 00 01 01 09 00 77
| | SIGDETADDR = 10 00 00 70 01 05 00 00
| | SerialNumber = GG007175
| | TDMBusType = 06
| | TONEGENADDR = 10 00 00 00 01 12 00 77
| | TYPE = F6 01 00 00
| | VoiceFeatureE2P = 00 03
| | VoiceFeatureFrontend = 0C 00
Showing us that the failure occurred on the voice resource
dxxxB4C4DebugAngel: Diagnostic tool which logs firmware messages from DM3 boards and HMP software
Devmapdump: "Device Map Dump", command line diagnostic tool which outputs all of the Dialogic device names currently in use. DCM services must be started prior to running this.
