MTK exception handling process

MTK exception handling process

 

In the exception handling process, you need to generate the exception information and output it to the screen or catcher, and save it to NVRAM. At last, according to the project mode, the machine will freeze the screen (select the frozen screen to capture memory dump) or restart.

 

1. CPU-triggered Exception Handling

When the CPU triggers an Exception, it will trigger the Exception interrupt and then jump to the interrupt subroutine. The interrupt subroutine calls the System Stack Error function and then calls the Fatal Error Handler for processing.

 

Undef Exception -- |

SWI Exception ---- | --- Exception ISR --- System Stack Error --- Fatal Error Handler

Data Abort ------- |

Prefetch Abort --- |

 

2. Assert Error exception handling

ASSERT is a macro. It actually calls the kal_assert_error function and then calls Assert_Common for processing.

 

ASSERT --- kal_assert_error --- Assert_Common

 

3. Fatal Error exception handling

Fatal Error is generally equivalent to the Assert statement embedded in the KAL layer, but the called functions are different. The KAL layer calls kal_fatal_error and then calls Fatal Error Handler.

 

Kal_fatal_error --- Fatal Error Handler

 

Assert_common and fatal_error_handler

Assert_common and fatal_error_handler are both exception handling functions. In fact, these two functions are very similar. The difference is that the parameters of assert_common are different from those of fatal_error_handler. The programmer can call three macros, ASSERT, EXT_ASSERT, and EXT_ASSERT_DUMP. Different information can be printed when an exception occurs.

When an exception occurs, it will jump to the two functions for execution. Therefore, if you have online debug tools such as Trace32, you can set breakpoints in these two functions. Then, let's look at the system information for debugging.

 

Fatal_error_handler Process
 

Mask all interrupts

Bytes

Restart watchdog

Bytes

Increment exception entrance count

Bytes

First entrace? ------------------- → No

Optional |

Release system protection |

And raise task priority level |

Optional |

Initialze exception log |

Optional |

Output exception certificate --------------- |

Message to catcher

Bytes

Display exception

Message to LCM

Bytes

Output log to Catcher

Bytes

First entrance? -------- → No

Optional |

Save exception log |

To flash disk |

Certificate certificate --------------

Memory Dump Flag = ON? -------- → No -------- → Hung up

Bytes

System reboot silently

 

Mask all interrupts

Because the exception processing process does not want to be interrupted by other programs, it is necessary to block all the interruptions.

 

Restart watchdog

The exception handling process exclusive CPU resources. Other tasks and isr cannot run, and do not regularly feed the dog. Therefore, the dog will be fed during the exception handling process.

 

Increment exception entrance count

There is a flag in the exception handling process, which indicates that this function has entered several times. For example, if the fatal_error_handler function encounters an exception during running, the function enters again. However, only 1st times of entering this function is recorded, which makes the most sense. Because if we solve the first exception, there will be no subsequent exception.

Therefore, the exception information is recorded only 1st times after you enter this function.

 

Release system protection and raise task priority level

To prevent the exception handler from being blocked during running, release system protection. Set the priority of the current task to the highest level to enable the exception handling program to exclusively run the CPU. Otherwise, it will not be recorded in the event of an exception.

 

Initialze exception log

Write exception information in a structure.

 

Output exception message to catcher

Output the exception information to the catcher Based on the structure above.

 

Display exception message to LCM

Output the brief exception information to LCM, for example, Fatal Error (1): 305-MMI

 

Output exception to Catcher

When an exception occurs, the exception information is first output to the catcher. Some logs are not flushed out in the tst buffer. Therefore, it is output to the catcher.

 

Save exception log to flash disk

NVRAM stores the last 10 mobile phone exceptions. If exceptions occur, no catcher is connected. You can then use the advanced --> retrive exception menu in catcher to read the exception information.

If the phone is sent for 11th times, the system will throw 1st abnormal messages, and so on.

 

Memory Dump Flag

In the Misc menu of the worker model, the memory dump option is available. If it is enabled, the screen will not be restarted when an exception occurs, and the screen will be frozen. At this time, you can use the memory dump function of the catcher to capture the memory dump and provide it to MTK for analysis.