QXDM-Messages View

HOW DO I OBTAIN THE DEFINITIONS OF EACH DEBUG OR EVENT MESSAGE?
The Messages view displays debug and event messages received by the mobile. (it can also be configured to display log packets and strings). These messages are not specific to QXDM, are used primarily by QUALCOMM for developing ASIC software, change frequently, and are not documented.

Debug Messages (labeled as Message Packets in QXDM) are software-specific printf strings created by the AMSS developer to help debug the AMSS itself. They are not documented beyond the source code itself. There are no QXDM user guides or addendums that define frequently used debug messages.

Event Reports are a debugging mechanism that summarizes activity by the software. The events are not implementation-specific or internal strings like debug messages, but are typically indicators of common, industry standard terms that are easier to understand and follow when compared to debug messages.

QXDM does not generate the messages that are displayed on the Messages view, which is why they are not documented in the QXDM user guide. QXDM only logs or displays the messages as they are provided by the mobile. The software in the test handset provides debug messages to QXDM as part of the MESSAGE RESPONSE MESSAGE (A Diagnostic command response), CMD_CODE(31), and Event Reports as part of the EVENT REPORT MESSAGE (CMD_CODE 96). QXDM does not need to be enhanced or changed to support debug messages for technologies in development. All such devices provide the debug text across the same transport described above, without the need to QXDM at all. Event Reports need a database update, as the Event ID and payload needs to be parsed for the Event Report to have meaning. Event Reports are not ASCII text strings like Debug Messages.

The debug messages consist of fixed text that is determined at compile time by the handset manufacturer. Most of the debug messages are inherited from the ASIC code that QUALCOMM provides to the handset manufactuer, while others are introduced by the handset manufacturer as they develop their product. The messages are used as a diagnostic aid to provide handset software developers with some insight into the behavior of the handset software program. The list of potential debug messages is very extensive, and are constantly changing from build to build. They are used for development purposes only, and will never be documented beyond the source code.

To find the definitions of any particular debug message that is generated from a commercial phone that uses the QUALCOMM chips, we have to refer to the handset manufacturer who modifies the debug messages according to their development needs. In most cases, this information is proprietary and of no real use to anyone else but the handset manufacturer's development teams. Our group does not have access to the manufacturer's source code files, so we cannot offer any additional information. ASIC licensees that have questions about the debug message definitions used in the distributed code can send their requests to "support.cdmatech@qualcomm.com". For debug messages from QCTest and Deployment Products, we can investigate each request for definitions (or, to solve the problem reported) on a case-by-case basis with a binary log sample and problem description provided.

To find the definitions of any particular Event Report, use the QXDM Database Editor, which is included with QXDM and shown in the "QXDM Professional" Windows program group. Select the ITEM/CATEGORY TABLES tab, then select the EVENTS sub-tab. Select or double-click on the Event ID you need a definition for, and the DESCRIPTION FIELD will display. To see enumerated list of variables, select the PARSE/DISPLAY TABLES tab and locate the same Event ID and double-click and press the [VIEW...] button. Then, press [VIEW ENUM...] to see the possible enum entries for that Event ID. This will tell you the possible values for the Event ID's payload.


HOW TO COLLECT A DEBUG MESSAGE AND EVENT REPORT LOG

• Select FILTERED VIEW (F12)
• Right click and choose CONFIG
• Select MESSAGES PACKETS
• Enable FILTERED/REGISTER ON TARGET FOR ITEMS
• Select KNOWN MESSAGES
• Select EVENT REPORTS
• Enable FILTERED/REGISTER ON TARGET FOR ITEMS
• Select KNOWN EVENTS
• Use the FILE->NEW ITEMS to restart logging
• Use the FILE->SAVE ITEMS to save the logging session

How QXDM Configures the Target for Debug Message Logging
The debug message mechanism in DIAG is extremely broad and covers many systems and subsystems. There are many generations of debug messages that have different filtering capabilities on target. This filtering allows the target to only send the debug messages at a particular level (LOW, MEDIUM, HIGH, ERROR or FATAL, which is coded in the software for each message) and in later versions of debug messages (Extended Debug Messages) have not only levels but subsystem IDs (SSIDs) that allow you to filter messages both level, subsystem or combinations of both). QXDM can control the target to send debug messages based on matching criteria. This configuration is sent by QXDM and obeyed by the target in real time as the debug messages are sent to QXDM for display. Filtering on the QXDM side is essentially the same thing as configuring the target to send according to the level\SSID settings you choose on the MESSAGES VIEW in QXDM.


ONLY ERROR MESSAGES ARE SEEN OR LOGGED
It is entirely possible that the handset manufacturer has only implemented debug messages of ERROR level. The other possibility is that you have filtered out everything lower than the ERROR level in QXDM's Mobile Messages screen. Do this:

• Select FILTERED VIEW (F12)
• Right click and choose CONFIG
• Select MESSAGES PACKETS
• Enable FILTERED/REGISTER ON TARGET FOR ITEMS
• Select KNOWN MESSAGES
• Use the FILE->NEW ITEMS to restart logging
• Use the FILE->SAVE ITEMS to save the logging session

If you still get only ERROR level messages, then this is a phone software issue. The handset manufaturer has implemented only ERROR level debug messages.


MSG_LEVEL
Legacy Debug Messages have message levels that are set in the source code of the D\AMSS and are used as a maximum level the mobile must provide during a logging session. QXDM allows you to pick and choose for display pleasure only on the Mobile Messages screen, but the logging mechanism still takes the level into account, and the D\AMSS provides everything at the lowest level and above.

Think of them as a filtering mechanism.

The message levels are as follows...

• NONE (This level disables debug messages entirely)
• FATAL (This logs FATAL level messages only)
• ERROR (This logs FATAL and ERROR level messages only)
• HIGH (This logs FATAL, ERROR and HIGH level messages only)
• MED (This logs FATAL, ERROR, HIGH and MED level messages only)
• LOW (This logs FATAL, ERROR, HIGH, MED and LOW level messages)

If you set the message level to HIGH, then you have instructed the phone to only send debug messages that are tagged at compile-time as HIGH, ERROR or FATAL. If you change the message level to LOW, then this tells the phone to send *ALL* debug messages across the serial link (LOW, MED, HIGH, ERROR and FATAL). Again, QXDM can filter out the levels you only want to see on the Messages view, but that is not exactly how the logging mechanism works.

For example, say you have all levels visible on the Messages view, and your phone is constantly providing MED and HIGH level messages. You configure QXDM to display just MED messages. Then, you begin logging. Although you only saw MED level messages in QXDM, the mobile provided MED and above messages across the DIAG link, and all of those were logged. BUT, your configuration of QXDM only displayed the MED ones.

Legacy Debug Messages have been made obsolete by the Extended Debug Messages, which are filterable further by specific subsystem, which makes post-processing and real-time filtering even more powerful and further defined by category.


DROPPED MESSAGES
There is a field in the Message Response Message (which holds the debug messages from the mobile that are displayed on the Mobile Messages screen) called DROP_CNT. The DMSS\AMSS can keep track of how many Debug Messages are dropped between the current message and the previous one. You can see this number on the Mobile Messages screen's status bar. This value is also logged by QXDM in the binary log file. It is a 4-byte value, starting at the 5th byte of the payload.

If the DMSS\AMSS generates the debug messages to fast for the DIAG tool to log, the DMSS\AMSS uses this field to track how many newly arrived messages are dropped.

This counter has nothing to do with other log packets or diagnostic commands.

QXDM only displays the most recently received dropped messages count in the status bar of the Mobile Messages window. There is no flag or indicator on the Mobile Messages screen that indicates when the counter suddenly changes to a non-zero value for a particular message. Furthermore, the contents of the Mobile Messages displays does not have a column for the dropped messages counter, so you cannot pause and scroll back to see what the count was at any particular message's time stamp. However, this can be easily done with a post-processor.


What Does LEGACY Contain?
Legacy category contains all subsystems prior to the creation of SSIDs (Extended Message). It is kept in QXDM for backwards compatibility.


WHAT DOES "KEY PRESSED = (number)" MEAN?
The "Key pressed = 81" appears to be a message generated by the user interface key handler. The number 81 is the decimal ASCII code that represents the key that was pressed. For example, [1] = 49, [2] = 50, [3] = 51, etc. All keys are mapped to specific characters. The Message Response Message also provides the source code filename and line number for each Debug Message.


WHAT DOES "EMPTY PAGE" MEAN?
Empty pages are normal. In slotted paging mode, the mobile wakes up to inspect General Page Messages. Sometimes by reading a GPM, the mobile will know that there are going to be no pages for itself in this slot. That is when this message get printed out to the debug screen. The MORE_PAGES bit tells the mobile if there are more page messages in the same slot. The phone cannot go back to sleep unless it sees the MORE_PAGES = 0, or the slot ends. The empty page message should not be causing the mobile to lose CDMA.



Mobile Station Maintained List
The mobile software's internally maintained lists are typically exposed through the DIAG interface by way of Mobile Debug Messages on the MESSAGES view within QXDM. If the DMSS does not already support debug messages that display this information, or if the handset manufacturer has not implemented them, then it is not possible.
(Example, showing which PN's the mobile has put in it's ACCESS_HO_LIST)