MTK exception log

MTK exception log

 

Preface: This article aims to have a general understanding of abnormal logs. The abnormal log has a lot of information, but for different exceptions, the log to be viewed is different. When I first came into contact with the MTK platform, I also made the following mistake: What should I do if there are so many exception logs? You cannot turn your head off. After the end of this article, the younger brother selects some typical examples based on different exception situations to demonstrate how to view the exception log. I hope you can give me some advice.

When an exception occurs, as described in MTK exception process processing in the previous article, the exception information is written in a structure. The structure is defined:

Typedef struct ex_exception_log_t
{
Ex_header_t header; // record the exception type and time
Kal_char sw_version [ex_swver_len]; // version number
Ex_envinfo_t envinfo; // some important registers and memory information
Ex_diagnosisinfo_t diaginfo; // system status
EX_CONTENT_T content; // main content of the exception information
} EX_LOG_T;

 

1. EX_HEADER_T header;

Typedef struct ex_exception_record_header_t
{
Prediction_type ex_type;
Kal_uint8 ex_nvram;
Kal_uint16 ex_serial_num;
} EX_HEADER_T;

 

Exception_type ex_type; it is an exception type. There are eight types of exceptions in the MTK system. There is a message introduction in the section MTK Exception error type.

Kal_uint8 ex_nvram; you can see the nvram_write_exception function. There are 10 abnormal error messages in NVRAM. If the value of this variable is 0xff, it indicates that this item has not been written. You can record Exception error information for this variable.

Kal_uint16 ex_serial_num; each time an exception occurs, ex_serial_num is added with 1. Therefore, among the 10 NVRAM items, the value is later than the preceding value. As described in MTK exception handling process, 10 items in NVRAM are written cyclically. So how can we judge that a circle has been made? It is determined by the value of ex_serial_num. If the current item is smaller than the previous ex_serial_num, it indicates a loop. You can safely write this item out and write new exception information.

 

2. kal_char sw_version [EX_SWVER_LEN];

This is the version number we maintain.

 

3. EX_ENVINFO_T envinfo;

Typedef struct ex_environment_info_t
{
Boot_mode_type boot_mode;
Ex_rtc_struct rtc;
Kal_char execution_unit [EX_UNIT_NAME_LEN];
Kal_uint8 status;
Kal_uint8 pad [2];
Kal_uint32 stack_ptr;
Kal_uint32 stack_dump [EX_STACK_DUMP_LEN];
Kal_uint16 ext_queue_pending_cnt;
Kal_uint32 ext_queue_pending [EX_QUEUE_TRACK];
Kal_uint32 interrupt_mask [2];
Kal_uint32 processing_lisr;
Kal_uint32 lr;
} Ex_envinfo_t;

 

Boot_mode_type boot_mode: indicates the Boot Mode, whether to press power, RTC, USB, or charging, etc.

Ex_rtc_struct RTC; read the time from the RTC register

Kal_char execution_unit [ex_unit_name_len]; The current task

Kal_uint8 status; record the status of the current task when an exception occurs

Kal_uint8 pad [2]; it seems to be a reserved value

Kal_uint32 stack_ptr; sp value when an exception occurs

Kal_uint32 stack_dump [ex_stack_dump_len]; Use the stack_ptr above as the top of the stack and search for 10 function-like addresses. These addresses can be used to guess the call relationship of the function through the sym file in the build directory. However, these 10 addresses are not necessarily accurate and need to be determined by the human brain to determine whether they are correct function addresses.

Kal_uint16 ext_queue_pending_cnt; number of messages not processed in the external queue of the current task

Kal_uint32 ext_queue_pending [ex_queue_track]; no processed message ID is left in the external queue of the current task.

Kal_uint32 interrupt_mask [2]; Interrupt Mask register value
Kal_uint32 processing_lisr; If lisr is being executed, the address that lisr is running is recorded here.

Kal_uint32 LR; Value of the LR register when an exception occurs

4. ex_diagnosisinfo_t diaginfo;

Typedef struct ex_diagnosis_info_t
{
EX_DIAGNOSIS_T diagnosis;
Kal_char owner [EX_UNIT_NAME_LEN];
Kal_uint8 pad [3];
Kal_uint32 timing_check [EX_TIMING_CHECK_LEN];
} EX_DIAGNOSISINFO_T;

 

EX_DIAGNOSIS_T diagnosis; when an exception occurs, the system checks whether the problem exists. For example, whether the interrupted vector table is trampled or whether the stack is cracked. Therefore, if health is not displayed here, you must solve the system problems first.

Kal_char owner [EX_UNIT_NAME_LEN]; if a stack is cracked, the name of the task or hisr is displayed.

Kal_uint8 pad [3]; I don't know what to use, like retaining

Kal_uint32 timing_check [EX_TIMING_CHECK_LEN ];

 

5. EX_CONTENT_T content;

Typedef union
{
EX_FATALERR_T fatalerr;
EX_ASSERTFAIL_T assert;
} EX_CONTENT_T;

This is a consortium. If it is a fatal error, it will fill in the fatal error information. If it is assert, the information of assert is entered. (--! Sorry !)

 

6. EX_FATALERR_T fatalerr;

Typedef struct ex_fatalerror_t
{
EX_FATALERR_CODE_T error_code;
EX_DESCRIPTION_T description;
EX_ANALYSIS_T analysis;
EX_GUIDELINE_T guideline;
Union
{
EX_CTRLBUFF_T ctrl_buff;
EX_TASKINFO_T task_info [EX_MAX_TASK_DUMP];
EX_CPU_REG_T cpu_reg;
} Info;
} EX_FATALERR_T;

 

EX_FATALERR_CODE_T error_code; When a fatal error occurs, error code1 and error code2 are recorded. These two values are particularly important because we can know the possible cause of the fatal error. Select different analysis methods.

EX_DESCRIPTION_T description; I guess some additional information can be output when a fatal error occurs.

EX_ANALYSIS_T analysis; same as EX_DESCRIPTION_T description. I guess there is a fatal error and some additional information can be output.

EX_GUIDELINE_T guideline; the same as EX_DESCRIPTION_T description. I guess there is a fatal error and some additional information can be output.

 

EX_CTRLBUFF_T ctrl_buff; if the control buffer is faulty, some information about the control buffer is recorded.

Typedef struct
{
Kal_uint32 ex_ctrlbuf_size;
Kal_uint32 ex_ctrlbuf_num;

EX_CTRLBUFF_INFO_T ex_ctrlbuf_top;

EX_CTRLBUFF_INFO_T ex_ctrlbuf_second;

EX_CTRLBUFF_INFO_T ex_ctrlbuf_third;

EX_CTRLBUFF_OWNER_T ex_monitor [3];
Kal_uint32 ex_reserved [2];/* reserved */
} EX_CTRLBUFF_T;

Kal_uint32 ex_ctrlbuf_size; control buffer size

Kal_uint32 ex_ctrlbuf_num; number of control buffer

EX_CTRLBUFF_INFO_T ex_ctrlbuf_top;

EX_CTRLBUFF_INFO_T ex_ctrlbuf_second;

EX_CTRLBUFF_INFO_T ex_ctrlbuf_third;

When a control buffer error occurs, there are two errors. One is that the number of buffers is too small to be applied for, and the other is that the data in the buffer is broken. For two errors, the three variables have different meanings. For the first error, ex_ctrlbuf_top records the information of the module that ranks first and applies for the most buffer. ex_ctrlbuf_second records the second and ex_ctrlbuf_third records the third most ranked information:

Typedef struct
{
Kal_char ex_his_owner [8];

Kal_char ex_his_source [16];
Kal_uint32 ex_his_line;

Kal_uint32 ex_his_count;
} EX_CTRLBUFF_HISTORY_T;

Kal_char ex_his_owner [8]; apply for the control buffer module

Kal_char ex_his_source [16]; apply for the name of the control buffer File
Kal_uint32 ex_his_line; number of rows in the file where the control buffer is applied

Kal_uint32 ex_his_count; number of control buffer requests

For the second error, ex_ctrlbuf_second records the information of the buffer that has been written down. Ex_ctrlbuf_top is the information of the previous buffer that has been trampled on. Ex_ctrlbuf_third is the information of the last buffer after the buffer is trampled.

Typedef struct
{
Kal_uint32 ex_buf_NU_header1;

Kal_uint32 ex_buf_NU_header2;
Kal_uint32 ex_buf_KAL_header1;

Kal_uint32 ex_buf_KAL_header2;
Kal_uint32 ex_buf_KAL_header3;

Kal_uint32 ex_buf_poolID;
Kal_uint32 ex_buf_KAL_footer1;
Kal_uint32 ex_buf_KAL_footer2;
} EX_CTRLBUFF_COMMON_T;

Kal_uint32 ex_buf_NU_header1; if the buffer is applied for, NULL is returned. If not allocated, record the next pointer to the unallocated buffer.

Kal_uint32 ex_buf_NU_header2; control buffer ID

Kal_uint32 ex_buf_KAL_header1; a mark in the control buffer header is "0xF1F1F1F1". If the buffer is trampled on, this mark is written as another value.

Kal_uint32 ex_buf_KAL_header2; which module applied for the control buffer?

Kal_uint32 ex_buf_KAL_header3; control buffer ID

Kal_uint32 ex_buf_poolID; ID of the control buffer pool

Kal_uint32 ex_buf_KAL_footer1; I think it is useless.

Kal_uint32 ex_buf_KAL_footer2; a mark at the bottom is "0xf2f2f2". If the buffer is trampled on or the buffer overflows, this mark is written as another value.

 

EX_TASKINFO_T task_info [EX_MAX_TASK_DUMP];

When an error occurs in a task, for example, if an external queue is burst, the task information is output:

Typedef struct
{
Kal_char ex_task_name [8];

Kal_char ex_task_stack_gp [8];

Kal_uint32 ex_task_cur_status;

Ex_queue_t ex_task_external_q;
Ex_queue_t ex_task_internal_q;
Kal_uint32 ex_reserved;

} Ex_taskinfo_t;

Kal_char ex_task_name [8]; Task Name

Kal_char ex_task_stack_gp [8]; each task has a "stackend" mark at the top of the stack ". If the stack crashes, the mark will be corrupted. So we can judge whether the stack is broken from this mark.

Kal_uint32 ex_task_cur_status; Current Status of the task

Ex_queue_t ex_task_external_q; message information of the task external queue

Typedef struct
{
Kal_uint8 ex_q_src_mod;
Kal_uint8 ex_q_count;

Kal_uint16 ex_q_msg_id;
Kal_uint16 ex_q_cur_mes_no;

Kal_uint16 ex_q_config_entry;
} Ex_queue_t;

Kal_uint8 ex_q_src_mod; if the same message exists in the queue, the module name for sending the message is recorded here.
Kal_uint8 ex_q_count; number of identical messages in the queue

Kal_uint16 ex_q_msg_id; if the same message exists in the queue, the ID of the message is displayed.

Kal_uint16 ex_q_cur_mes_no; total amount of information in the current external queue

Kal_uint16 ex_q_config_entry; Maximum number of messages that a queue can hold

 

Ex_cpu_reg_t cpu_reg; if a CPU-triggered exception occurs, the CPU register information is recorded in this structure.

 

7. ex_assertfail_t assert;

Typedef struct ex_assert_fail_t
{
Kal_char filename [ex_assertfail_filename_len];
Kal_uint32 linenumber;
Kal_uint32 parameters [3];
Kal_uint8 dump [ex_assertfail_dump_len];
Kal_uint8 Guard [ex_guard_len];
} Ex_assertfail_t;

Kal_char filename [ex_assertfail_filename_len]; file name when assert appears

Kal_uint32 linenumber; the number of lines in the file where assert appears

Kal_uint32 parameters [3]; ex_assert can output three variable information, which will be recorded here

Kal_uint8 dump [ex_assertfail_dump_len]; ex_assert_dump will output 10 buffer information, and the pointer will be recorded here
Kal_uint8 Guard [ex_guard_len]; I don't know what the function is.

This article is from: I love R & D network (52rd.com)-R & D Base Camp
Http://www.52rd.com/Blog/Detail_RD.Blog_mastervon_24767.html: