Engine controller software architecture based on THA6206 chip

Abstract

The invention discloses an engine controller software architecture based on a THA6206 chip, which comprises a service layer, an ECU abstraction layer, an interface layer, a microcontroller and hardware layer, a complex driving layer and a boot program, and is characterized in that the service layer bears important responsibilities of comprehensive management and control of system resources and efficient scheduling of tasks, ensures that all software modules are coordinated and orderly to run, and is used for realizing the purpose of controlling the system resources; the method comprises the steps that a boot program is built in a domestic chip THA6206 and bears core service logic and function implementation of the engine controller, the boot program optimizes a jump logic and program architecture according to the chip THA6206 so as to reduce the complexity of software implementation, the software architecture of the engine controller is built through the domestic chip THA6206, meanwhile, a brand new method for jumping from the Boot program to an application program is designed based on the architecture, and the application program can be applied to the engine controller. And the coupling problem existing between the Boot program and the application program is solved. The engine controller software architecture based on the THA6206 chip, provided by the invention, has the effects of reducing complex programs for software implementation and effectively shortening the development period.

Description

Technical Field

[0001] The present invention relates to the field of automobile controller software, and in particular to an engine controller software architecture based on a THA6206 chip. Background Art

[0002] Traditional engine controller software architectures often rely on chips from renowned foreign chip companies such as Infineon, NXP, Renesas Electronics, and STMicroelectronics. The use of these chips presents numerous drawbacks for traditional domestic engine control software development. First, on a technical level, this prevents domestic development teams from deeply exploring advanced technological principles and innovative approaches, significantly limiting the scope and depth of technological innovation. Second, in terms of new technology pre-research, the reliance on foreign chips severely hinders the advancement of independent domestic pre-research. Furthermore, from a product cost perspective, foreign chips are generally expensive, which undoubtedly increases overall product costs and weakens product price competitiveness in the market. If the supply of these foreign chips is disrupted, companies will suffer significant financial losses, severely disrupting normal operations and bringing their development to a halt, or even leading to long-term stagnation and regression. This poses a significant challenge and threat to their sustainable development.

[0003] In the traditional boot process, the Boot program typically jumps into the App application using a sequential jump method. However, when applied to the domestically produced THA6206 chip, this traditional solution reveals obvious flaws. Specifically, the Boot program and the App program are prone to driver module coupling, forming a strong correlation between the two. This means that any modification or optimization of one program can have a ripple effect on the other, significantly increasing the complexity and difficulty of program development, debugging, and maintenance. This severely restricts the overall flexibility and scalability of software systems based on this chip, and is also detrimental to subsequent feature updates and the continuous optimization of system performance. Summary of the Invention

[0004] In response to the above problems, an engine controller software architecture based on the THA6206 chip is provided to solve the problems existing in the prior art.

[0005] The specific technical solutions are as follows:

[0006] An engine controller software architecture based on the THA6206 chip includes a service layer, an ECU abstraction layer, an interface layer, a microcontroller and hardware layer, a complex driver layer, and a boot program. The service layer assumes the important responsibilities of comprehensive system resource management and efficient task scheduling, ensuring the coordinated and orderly operation of various software modules, and carrying the core business logic and functional implementation of the engine controller. The boot program optimizes the jump logic and program architecture based on the THA6206 chip to reduce the complexity of software implementation.

[0007] The aforementioned engine controller software architecture based on the THA6206 chip also has the following characteristics: the service layer includes an OS operating system, an intermediate layer, and an application program;

[0008] The OS is responsible for comprehensive system resource management and efficient task scheduling, ensuring the coordinated and orderly operation of all software modules.

[0009] The middle layer is used to build a stable bridge between the upper layer and the underlying software to promote the efficient flow of data;

[0010] The application carries the core business logic and function implementation of the engine controller.

[0011] The above-mentioned engine controller software architecture based on the THA6206 chip also has the following characteristics: the ECU abstraction layer includes a communication module, a memory management module and an I / O module.

[0012] The above-mentioned engine controller software architecture based on the THA6206 chip also has the following characteristics: the interface layer includes a CAN communication interface, a LIN communication interface, a memory interface and a load device driver layer sequence.

[0013] The above-mentioned engine controller software architecture based on the THA6206 chip also has the following characteristics: the microcontroller hardware layer includes the THA6206 chip and the underlying driver.

[0014] The above-mentioned engine controller software architecture based on the THA6206 chip also has the following characteristics: the complex drive layer is an engine-related complex drive built based on the general timer module GTM, including crankshaft drive, camshaft drive, injection drive, ignition drive and knock control drive.

[0015] The aforementioned engine controller software architecture based on the THA6206 chip also has the following characteristics: the Boot program includes the following steps:

[0016] S1, Boot;

[0017] S2. Determine whether the jump-to-App flag is set. If not, proceed to S3. If so, proceed to S7.

[0018] S3, Boot initialization;

[0019] S4, determine whether it is possible to jump into the App program;

[0020] S5. Set the jump into App flag;

[0021] S6, soft reset, go to step S1;

[0022] S7, jump into the App startup address to run;

[0023] S8. App initialization.

[0024] In summary, the beneficial effects of this solution are:

[0025] The engine controller software architecture based on the THA6206 chip, provided by this invention, utilizes the domestically produced THA6206 chip to build the engine controller software architecture. This architecture also incorporates a novel method for jumping from the boot program to the application program, resolving the coupling problem between the boot program and the application program. This engine controller software architecture based on the THA6206 chip reduces the complexity of software implementation and effectively shortens the development cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a software architecture diagram of the engine controller based on THA6206 of the present invention;

[0027] Figure 2 This is a flowchart of the Boot program jumping to the App program of the present invention. DETAILED DESCRIPTION

[0028] The following will clearly and completely describe the technical solutions of the present invention in conjunction with the embodiments of the present invention. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of the present invention.

[0029] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0030] The present invention will be further described below with reference to specific examples, but they are not intended to limit the present invention.

[0031] Figure 1This is the software architecture diagram of the engine controller based on THA6206 of the present invention. Figure 2 This is a flowchart of the Boot program jumping to the App program of the present invention, as shown Figure 1 As shown, the engine controller software architecture based on the THA6206 chip provided in this embodiment includes: a service layer, an ECU abstraction layer, an interface layer, a microcontroller and hardware layer, a complex driver layer, and a boot program. The service layer assumes the important responsibilities of comprehensive control of system resources and efficient task scheduling, ensuring the coordinated and orderly operation of various software modules, and carrying the core business logic and function implementation of the engine controller. The boot program optimizes the jump logic and program architecture according to the THA6206 chip to reduce the complexity of software implementation.

[0032] In the above embodiment, the service layer includes the OS operating system, the middle layer and the application program;

[0033] The OS operating system is responsible for comprehensive management of system resources and efficient task scheduling, ensuring the coordinated and orderly operation of various software modules.

[0034] The middle layer is used to build a solid bridge between the upper layer and the underlying software to promote efficient data flow;

[0035] Application program that carries the core business logic and functional implementation of the engine controller.

[0036] In the above embodiment, the ECU abstraction layer includes a communication module, a memory management module, and an I / O module.

[0037] It should be noted that the communication module includes: CAN communication service, which provides comprehensive CAN communication function support; NM network management, which effectively manages network resources and topology; XCP calibration protocol, which realizes accurate calibration and optimization of system parameters; LIN communication service, which ensures the stability and reliability of LIN communication;

[0038] Memory management module, used for refined management and optimized allocation of system memory;

[0039] I / O modules are used to simplify hardware operation complexity and improve software portability.

[0040] In the above embodiment, the interface layer includes a CAN communication interface, a LIN communication interface, a memory interface, and a load device driver layer sequence.

[0041] It should be noted that CANIF (CAN Interface) CAN communication interface and LINIF (LIN Interface) LIN communication interface build stable and efficient internal and external communication links;

[0042] MemIF (Memory Interface) memory interface, convenient management of interactive access to memory resources;

[0043] Complex Device Drivers sit between the underlying driver and the RTE. Their primary task is to implement drivers for complex peripheral chips. Complex device drivers are closely tied to the underlying driver and hardware.

[0044] In the above embodiment, the microcontroller hardware layer includes the THA6206 chip and the underlying driver.

[0045] It should be noted that the underlying drivers include:

[0046] CAN bus communication driver, responsible for achieving stable communication with other devices on the CAN bus;

[0047] The LIN bus communication driver is mainly used to connect sensors and actuators with relatively low requirements for cost and data transmission rate. It implements functions such as LIN bus initialization, data frame assembly and parsing, while reducing system costs.

[0048] Flash driver, used for accurate reading and writing of Flash storage media;

[0049] ADC driver, effectively processing the conversion process from analog signals to digital signals;

[0050] SPI (Serial Peripheral Interface) serial peripheral interface driver, used to communicate with H-bridge driver chips, CAN transceiver peripheral chips, and wide-oxygen peripheral chips with SPI interfaces. The SPI driver can efficiently control the timing of data transmission and achieve high-speed data transmission;

[0051] WDG (Watchdog Timer) driver monitors the system operating status in real time to ensure system stability and reliability. When a system failure occurs or the program falls into an infinite loop, the watchdog timer will send a reset signal if it is not reset within the preset time, restarting the system and restoring normal operation to prevent the engine control system from losing control due to software failure.

[0052] INTC (Interrupt Controller) driver accurately handles various interrupt requests and optimizes system response performance. The INTC driver reasonably allocates CPU resources for interrupt processing based on the priority and type of the interrupt, ensuring real-time engine control.

[0053] BTM (Base Timer Module) basic timer module driver provides accurate timing services for the system;

[0054] The RCC (Reset and Clock Controller) driver controls the system's reset and clock signal management. During system startup, the RCC driver ensures that all hardware components are correctly reset and enter their initial state. It also distributes and adjusts the system's clock signals, providing clock signals of appropriate frequencies based on the needs of different hardware modules.

[0055] The SENT (Single Edge Nibble Transmission) communication protocol driver facilitates data transmission for specific communication protocols. When communicating with sensors that use the SENT protocol, the driver parses the SENT format data sent by the sensor and extracts valid data. Furthermore, when sending data to the sensor, the data is encapsulated and sent according to the SENT protocol, ensuring smooth communication with specific SENT protocol devices.

[0056] OVC (Data Access Overlay) data access mapping driver facilitates the implementation of real-vehicle calibration and debugging functions;

[0057] The MSC (Micro Second Channel) microsecond-level channel communication driver is the foundation for implementing complex SBC (System Basic Chip) drivers. In engine control scenarios requiring extremely high timing accuracy, such as high-speed fuel injection control or precise ignition timing control, the MSC driver can achieve microsecond-level communication delay and data transmission accuracy. This ensures data transmission and processing are completed in an extremely short time, meeting the requirements of high-performance engine control.

[0058] DMA (Direct Memory Access) direct memory access driver accelerates memory data transfer and reduces CPU burden. During the data transfer process, the DMA driver allows hardware devices to exchange data directly with the memory without excessive CPU intervention. For example, when collecting large amounts of data from the ADC and storing them in memory, the DMA driver can greatly improve data transfer efficiency, reduce the burden on the CPU, and allow the CPU to focus on other important control tasks, thereby improving the performance of the entire system.

[0059] The PORT driver configures and manages the chip's ports. This includes setting parameters such as the port's input and output modes, pull-up and pull-down resistors, and more. Correctly configuring port parameters ensures proper electrical connection and signal transmission between the device and the chip.

[0060] In the above embodiment, the complex drive layer is an engine-related complex drive built based on the general timer module GTM, including crankshaft drive, camshaft drive, injection drive, ignition drive and knock control drive.

[0061] It should be noted that Crank crankshaft drive accurately controls the crankshaft operating status and parameters;

[0062] CAM camshaft drive ensures precise drive and control of the camshaft;

[0063] Fuel injection drive to achieve precise control of fuel injection;

[0064] Spark ignition drive, controls ignition timing and intensity;

[0065] Knock control drive effectively monitors and suppresses engine knock.

[0066] like Figure 2 As shown, in the above embodiment, the Boot procedure includes the following steps:

[0067] S1, Boot;

[0068] S2. Determine whether the jump-to-App flag is set. If not, proceed to S3. If so, proceed to S7.

[0069] S3, Boot initialization;

[0070] S4, determine whether it is possible to jump into the App program;

[0071] S5. Set the jump into App flag;

[0072] S6, soft reset, go to step S1;

[0073] S7, jump into the App startup address to run;

[0074] S8. App initialization.

[0075] It's important to note that the Boot program's primary function is to flash App applications. When the system requires a software upgrade or update, the Boot program is responsible for establishing a secure and reliable connection with external devices, accurately receiving the new software program code data, and writing it to the designated storage area in a highly rigorous and orderly manner. During the App flashing process, the Boot program strictly adheres to the pre-set data verification mechanism, meticulously verifying the accuracy of each data block to ensure that the written data is complete, correct, and free of any damage or tampering, effectively ensuring that the new software program can run stably and efficiently within the system.

[0076] Working Principle: In the traditional jump scheme, after the system boots up, the first step is the Boot startup step. This step is the starting point of the entire startup process. The Boot program begins loading and preparing to execute subsequent operations. Next, the Boot initialization step begins. During this stage, the Boot program initializes and configures some basic system settings, key hardware modules, and related operating environment parameters, laying the necessary foundation for subsequent jump judgment and application startup. After the initialization is completed, it is determined whether to jump into the App program. This judgment process is based on a series of pre-set conditions. Only when all conditions are met does it mean that the system has the prerequisites for jumping into the App program. If the conditions for jumping into the App program are met, it will jump to the App startup address and execute, transferring from the Boot program's execution space to the App application's specific startup address, thus starting the App program loading and execution process. Finally, the App initialization step is carried out. In this step, the App application initializes various resources, internal modules, data structures, and operating status required by it. At this point, the entire process of jumping from the Boot program to the App application is completed, achieving an orderly transition from system startup to application execution.

[0077] However, the aforementioned jump solution has numerous drawbacks that severely impact the system's flexibility, maintainability, and scalability. First, under the traditional solution, the startup code of both the boot program and the app must be adjusted. This process is not only tedious and complex but also prone to human error. Each code adjustment requires a thorough and detailed review and testing of the entire startup process, consuming significant manpower and time. Second, when multi-core applications are enabled, the boot program must retain some multi-core initialization content in its startup code, just as the app does. This not only increases the boot program's code complexity and resource usage, but also overextends its responsibilities, deviating from its original focus on system boot. Furthermore, to ensure the proper operation of multiple cores, meticulous multi-core jump synchronization is required. Multi-core jump synchronization involves complex timing coordination and data exchange between multiple cores. If handled improperly, it can easily lead to conflicts and errors between cores, causing system instability or even crashes. Crucially, the boot program and the app must not repeatedly initialize peripheral functions such as the flash frequency, system PLL, peripheral PLL, CPU clock, and STM clock. This limitation means that if the app's peripheral initialization is constrained by the boot program's configuration, the app and boot program's functions will become closely linked. Consequently, upgrading the app's functionality will likely require modifications to the boot program. This highly coupled relationship runs counter to our desired application scenarios. In practice, we urgently need the app to be able to independently upgrade and optimize its functionality without frequent boot program modifications, reducing the complexity of system development and maintenance and improving overall development efficiency and system stability.

[0078] Compared with the traditional sequential jump scheme, the innovative jump scheme has significant optimization and improvement in the operation process. In the scheme of this application, a new Boot jump into App flag is introduced as the key control node of the entire jump logic. When the system is successfully started, the Boot program startup step is first started. However, the significant difference from the traditional scheme is that it does not directly execute Boot initialization, but enters step S2 to judge the Boot jump into App flag. This judgment link is like a key diversion level, and the subsequent execution path is determined according to the status of the flag.

[0079] If it is determined in step S2 that the jump into App flag is not set, the process will proceed to step S3 to formally carry out the Boot initialization work. After completing the Boot initialization, step S4 is executed immediately, that is, to determine whether it is possible to jump into the App program. Only when all conditions are met does it mean that the system has the necessary prerequisites for entering the App program. If it is determined in step S4 that the conditions for jumping into the App program are met, then step S5 will be executed, that is, the jump App flag will be set. This operation is equivalent to setting a clear "pass" for the subsequent jump process. Immediately afterwards, the S6 soft reset is executed, and the soft reset operation is used to make the system return to step S31 to start execution. This cyclical process seems complicated, but it actually cleverly realizes the secondary confirmation of the jump conditions and the re-sorting of the system status, ensuring the accuracy and stability of the jump process;

[0080] Conversely, if the jump-to-app flag is set in step S2, step S7 is executed directly, precisely jumping to the app's startup address. This process involves seamless and efficient program execution, quickly and accurately transferring the boot program's runtime space to the app's specific startup address, thus smoothly starting the app's loading and execution process. Next, step S8 is executed to initialize the app.

[0081] The innovative jump solution has many significant advantages:

[0082] First, coupling is reduced. This solution effectively isolates the initialization processes of Boot and App by introducing a Boot-to-App flag and unique jump logic. Once the App program starts normally, subsequent functional upgrades or modifications will have little impact on the Boot program, and vice versa. This makes the two more functionally independent, greatly reducing the coupling between the programs, facilitating their respective development, maintenance, and upgrades, reducing the risk of chain reactions caused by a single modification, and improving the stability and scalability of the entire software system.

[0083] Secondly, it simplifies multi-core initialization. When enabling multi-core application scenarios, the traditional solution requires Boot to retain some multi-core initialization content in the startup code like App and to perform multi-core jump synchronization. The innovative solution focuses on multi-core initialization in the specific process of the App program. The Boot program only needs to focus on its own basic initialization and jump logic control, without having to involve too much in the complex operations of multi-core initialization. This not only simplifies the code structure of the Boot program and reduces its development and maintenance difficulty, but also makes the multi-core initialization process more centralized and orderly, reduces errors and instability caused by improper multi-core synchronization, and improves the overall performance and reliability of multi-core applications;

[0084] Finally, it also improves startup efficiency and flexibility. The startup process of traditional solutions is relatively fixed and linear. If a problem or adjustment occurs in a certain link, it may affect the entire startup process. The innovative solution is based on flag bit judgment and a loop jump mechanism, which gives the system more opportunities for self-testing and adjustment during the startup process. For example, when re-executing the startup process after a soft reset, it can be reconfirmed that the jump conditions are still met, ensuring that each jump is performed when the system is in the optimal state. This flexible startup logic can effectively avoid startup failures caused by changes in the hardware environment or temporary anomalies during the initialization process, improve the success rate and efficiency of system startup, and enhance the system's adaptability to complex operating environments.

[0085] The above are only preferred embodiments of the present invention and do not limit the implementation mode and protection scope of the present invention. For those skilled in the art, it should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the contents of the present invention specification should be included in the protection scope of the present invention.

Claims

1. An engine controller software architecture based on the THA6206 chip, characterized by: It includes a service layer, an ECU abstraction layer, an interface layer, a microcontroller and hardware layer, a complex driver layer, and a boot program. The service layer assumes the important responsibilities of comprehensive control of system resources and efficient task scheduling, ensuring the coordinated and orderly operation of various software modules, and carrying the core business logic and function implementation of the engine controller. The boot program optimizes the jump logic and program architecture based on the THA6206 chip to reduce the complexity of software implementation.

2. The engine controller software architecture based on the THA6206 chip according to claim 1, characterized in that: The service layer includes an OS operating system, an intermediate layer, and application programs; The OS is responsible for comprehensive system resource management and efficient task scheduling, ensuring the coordinated and orderly operation of all software modules. The middle layer is used to build a stable bridge between the upper layer and the underlying software to promote the efficient flow of data; The application carries the core business logic and function implementation of the engine controller.

3. The engine controller software architecture based on the THA6206 chip according to claim 2, characterized in that: The ECU abstraction layer includes a communication module, a memory management module and an I / O module.

4. The engine controller software architecture based on the THA6206 chip according to claim 3, characterized in that: The interface layer includes a CAN communication interface, a LIN communication interface, a memory interface, and a load device driver layer sequence.

5. The engine controller software architecture based on the THA6206 chip according to claim 4 is characterized in that: The microcontroller hardware layer includes the THA6206 chip and the underlying driver.

6. The engine controller software architecture based on the THA6206 chip according to claim 5, characterized in that: The complex drive layer is an engine-related complex drive built based on the general timer module GTM, including crankshaft drive, camshaft drive, injection drive, ignition drive and knock control drive.

7. The engine controller software architecture based on the THA6206 chip according to any one of claims 1 to 6, characterized in that: The Boot procedure includes the following steps: S1, Boot; S2. Determine whether the jump-to-App flag is set. If not, proceed to S3. If so, proceed to S7. S3, Boot initialization; S4, determine whether it is possible to jump into the App program; S5. Set the jump into App flag; S6, soft reset, go to step S1; S7, jump into the App startup address to run; S8. App initialization.

Images