Modular in-vehicle controller bootloader

Abstract

The application discloses a modular vehicle-mounted controller Bootloader, comprising a microcontroller abstraction layer (MCAL), a communication and diagnosis module and an application layer; the MCAL adopts an MCAL driver of an AUTOSAR specification; the communication and diagnosis module is CAN communication and UDS diagnosis based on the AUTOSAR specification; the application layer comprises a BM module, an FBL module and a SecM module; the BM module is used for initializing an ECU, checking the download of the ECU after the initialization, managing the jump of BootLoader execution or the refreshing and execution of an APP program and initializing the MCAL driver; the FBL module provides a relevant download service processing interface for UDS for data processing of a download process; and the SecM module is used for executing a data check task. The modular vehicle-mounted controller Bootloader has the advantages of being capable of realizing the rapid transplantation of BootLoader, reducing the transplantation cost, facilitating and quickening parameter configuration and the like.

Description

Technical Field

[0001] This invention relates to a boot technology for embedded systems, and more particularly to a modular vehicle-mounted controller bootloader. Background Technology

[0002] With the increasing level of automotive electronics and the expansion of vehicle functions, modern automobiles are undergoing a technological revolution. In daily life, cars are no longer just traditional means of transportation, but have become mobile terminals with intelligent, connected, and electrified characteristics. Consumers have increasingly higher demands for automobiles' energy efficiency (economic and regulatory emission requirements), comfort, connectivity, and safety (functional and information security).

[0003] In recent years, the rise of new energy electric vehicles, vehicle networking, and autonomous driving technologies has greatly accelerated the development of automotive electronics technology. The functions integrated into automotive electronic ECUs (Electronic Control Units) are becoming increasingly complex. To ensure the safe and efficient startup and operation of the vehicle's electronic systems, the BootLoader, as the first component in the system startup process, plays a crucial role.

[0004] The bootloader is the first piece of code executed by an embedded system after power-on. After initializing the CPU and related hardware, it loads the operating system image or embedded application into memory and then jumps to the operating system's memory space to start the operating system. For embedded systems, the bootloader is implemented based on a specific hardware platform. Therefore, it is almost impossible to create a universal bootloader for all embedded systems; different processor architectures require different bootloaders. The bootloader depends not only on the CPU architecture but also on the configuration of the embedded system board (chip). For two different embedded system boards, even if they use the same processor architecture, to make the bootloader program running on one embedded system board run on another, it is generally necessary to modify the bootloader source code.

[0005] Traditional bootloaders exist in the form of SDKs (Software Development Kits), which suffer from high coupling, poor portability, and poor software reusability. SDK-based code lacks a layered structure, resulting in high coupling. For products that need to run on multiple hardware platforms (chips), each platform switch requires specific modifications to the bootloader. This not only reduces system stability and reliability but also significantly hinders rapid product iteration and feature upgrades. Summary of the Invention

[0006] To avoid the shortcomings of the existing technology, the present invention provides a modular vehicle controller Bootloader, which enables rapid porting of the BootLoader and makes the BootLoader parameters easier to configure.

[0007] The present invention adopts the following technical solution to solve the technical problem.

[0008] The present invention provides a modular vehicle controller bootloader, comprising a microcontroller abstraction layer (MCAL), a communication and diagnostic module, and an application layer; the microcontroller abstraction layer (MCAL) adopts the AUTOSAR specification MCAL driver; the communication and diagnostic module is based on AUTOSAR specification CAN communication and UDS diagnostics.

[0009] The application layer includes the BM module, the FBL module, and the SecM module;

[0010] The BM module is used to initialize the ECU and check the download of the ECU after initialization, manage the jump of the BootLoader execution or the refresh of the APP program, and execute the initialization of the microcontroller abstraction layer MCAL driver.

[0011] The FBL module is used to provide UDS with relevant download service processing interfaces for data processing to execute the download process;

[0012] The SecM module is used to perform data verification tasks.

[0013] The modular vehicle controller bootloader of the present invention is also characterized by:

[0014] Furthermore, the workflow of the BM module includes the following steps:

[0015] Step 1: The user sends the initialization command BM_InitEcu to the ECU through the BM module, and the BM module performs ECU initialization;

[0016] Step 2: After initialization, check the ECU download using the BM_CheckEcuDownload command; then determine whether a program jump is needed based on the response of the BM_CheckEcuDownload command.

[0017] Furthermore, the workflow of the FBL module includes the following steps:

[0018] Step 01: Step 34; First, set the steps to 34 during initialization. After receiving the 34 service from the host computer, save the starting address and length carried by the 34 service, and change the steps to 36.

[0019] Step 02: Step 36; After receiving the 36 service from the host computer, check the data range and record the transmitted data, and at the same time check whether the segment data has been downloaded completely; when the segment data has been downloaded completely, change the step to step 37;

[0020] Step 03: Step 37; After receiving the 37 service from the host computer, stop data transmission and change the step to step 34 or the verification step;

[0021] like Figure 4 The 34th step or the verification step are two different step states, indicating that the 34th service or the 31st verification routine can pass correctly when received;

[0022] Step 04: Verification Step; After the host computer sends the 31 verification routine, save the data verification value sent by the host computer and change the step to an erase step or a dependency check step.

[0023] Step 05: Erasure Step; After receiving the erase routine 31 sent by the host computer, record the starting address and length of the erase, verify whether the erase range is within the specified range, and after completing the preparations before erasure, change the step to step 34 to download the APP data;

[0024] Step 06: Dependency check step; At this time, the dependency check will be received from the host computer. After the dependency check is completed, the APP validity flag will be changed to valid and written to the memory space. The program will then wait for a reset.

[0025] Furthermore, in the FBL module, the Flash driver states are divided into waiting-to-download state, download state, verification state, waiting-to-initialize state, idle state, erase state, and programming state.

[0026] Furthermore, the SecM module performs data CRC verification.

[0027] Furthermore, the SecM module includes the SecM_CreatCrc verification interface and the SecM_SoftwareCheck verification interface.

[0028] Furthermore, the configuration parameters of the application layer are configured through a configurator, and the generated configuration file code after the parameter configuration is completed is imported into the project code of the vehicle controller Bootloader.

[0029] Furthermore, the configurator includes a configurator body with basic functions and module plugins with module functions; the configurator body includes an application service module and a database service module; the application service module includes a backend service module and a web page service module;

[0030] The module plugin includes a general plugin module; the general plugin module is used to generate a module parameter configuration page based on the user's module page description file, then perform constraint verification on the parameter configuration of the user in the module parameter configuration page, and finally generate a descriptive code file after the constraints are correct.

[0031] Furthermore, the general plugin module includes a module page plugin, a module constraint plugin, and a code template generation plugin, which communicate with the configurator main body through their respective access methods.

[0032] Furthermore, the module page plugin is implemented as follows:

[0033] Users define AUTOSAR-compliant module arxml files, convert them through corresponding plugin interfaces, and then interact with the configurator main body through a page access method to generate a module visual configuration interface. The visual configuration interface is connected to the configurator main body for data interaction using a micro-frontend approach.

[0034] Compared with existing technologies, the beneficial effects of this invention are reflected in:

[0035] This invention discloses a modular vehicle controller bootloader, comprising a microcontroller abstraction layer (MCAL), a communication and diagnostic module, and an application layer. The MCAL adopts an AUTOSAR-compliant MCAL driver. The communication and diagnostic module uses AUTOSAR-compliant CAN communication and UDS diagnostics. The application layer includes a BM module, an FBL module, and a SecM module. The BM module is used to initialize the ECU and check the download to the ECU after initialization, manage the jumps executed by the BootLoader or the refresh of the APP program, and execute the initialization of the MCAL driver. The FBL module provides relevant download service processing interfaces for the UDS to perform data processing during the download process. The SecM module is used to perform data verification tasks.

[0036] This invention provides a modular vehicle controller bootloader. Based on the AUTOSAR architecture, its MCAL underlying driver, BSW layer communication protocol stack, and UDS diagnostic protocol possess a standard AUTOSAR interface, enabling rapid adaptation and replacement of modules from different manufacturers. The three driver modules of the bootloader application layer are modularly encapsulated, reducing coupling with other modules. Application layer parameters are also encapsulated, allowing for visual configuration on the configurator side. During chip porting, the modular bootloader allows for replacement of the MCAL driver and configuration of application layer parameters according to actual needs, enabling rapid bootloader porting and reducing porting costs.

[0037] The modular vehicle controller Bootloader of the present invention has the advantages of enabling rapid porting of the BootLoader, reducing porting costs, and facilitating convenient and quick parameter configuration. Attached Figure Description

[0038] Figure 1 This is an architecture diagram of a modular vehicle controller bootloader according to the present invention.

[0039] Figure 2 This is a schematic diagram illustrating the invocation of the BM module of a modular vehicle controller Bootloader according to the present invention.

[0040] Figure 3 This is a schematic diagram illustrating the invocation of the FBL module of a modular vehicle controller Bootloader according to the present invention.

[0041] Figure 4 This is a step-by-step diagram showing the changes in each step when the FBL module of the modular vehicle controller Bootloader of the present invention is invoked.

[0042] Figure 5The state of the Flash driver of the FBL module of the modular vehicle controller bootloader of the present invention and Figure 4 A diagram showing the relationship between the various steps in the process.

[0043] Figure 6 This is a schematic diagram illustrating the invocation of the SecM module of a modular vehicle controller bootloader according to the present invention.

[0044] Figure 7 This is a schematic diagram illustrating the implementation principle of a modular vehicle controller Bootloader configurator according to the present invention.

[0045] Figure 8 This is a diagram showing the main components of a WEB configurator according to an embodiment of the present invention;

[0046] Figure 9 This paper illustrates a plug-in implementation method based on a web configurator according to an embodiment of the present invention.

[0047] Figure 10 This is a flowchart illustrating the usage of the WEB configurator according to an embodiment of the present invention.

[0048] The present invention will be further described below through specific embodiments and in conjunction with the accompanying drawings. Detailed Implementation

[0049] See Figures 1-10 The present invention provides a modular vehicle controller bootloader, comprising a microcontroller abstraction layer (MCAL), a communication and diagnostic module, and an application layer; the microcontroller abstraction layer (MCAL) adopts the AUTOSAR specification MCAL driver; the communication and diagnostic module is based on AUTOSAR specification CAN communication and UDS diagnostics.

[0050] The application layer includes the BM module, the FBL module, and the SecM module;

[0051] The BM module is used to initialize the ECU and check the download of the ECU after initialization, manage the jump of the BootLoader execution or the refresh of the APP program, and execute the initialization of the microcontroller abstraction layer MCAL driver.

[0052] The FBL module is used to provide UDS with relevant download service processing interfaces for data processing to execute the download process;

[0053] The SecM module is used to perform data verification tasks.

[0054] The present invention provides a modular vehicle-mounted controller bootloader, the specific architecture of which is as follows: Figure 1As shown, the modular vehicle controller Bootloader of this invention adopts the MCAL (Microcontroller Abstraction Layer) driver based on the AUTOSAR (AUTomotive Open System Architecture) specification at its underlying layer. The BootLoader's BSW (Basic Software) layer communication and diagnostic modules utilize CAN (Controller Area Network) communication and UDS (Unified Diagnostic Services) diagnostics based on the AUTOSAR specification. The AUTOSAR-based MCAL driver, communication, and diagnostics have standardized interfaces and functions, ensuring that the driver interface and related parameters are identical across different platforms (chips). This allows for rapid platform (chip) porting with minimal or no modification to the upper-layer code. The BootLoader's application layer employs modular BM (BootLoader Manager) modules, FBL (Flash BootLoader) modules, and SecM (Security Module) modules. This modularity enables rapid porting and adaptation of the BootLoader.

[0055] In specific implementation, the workflow of the BM module includes the following steps:

[0056] Step 1: The user sends the initialization command BM_InitEcu to the ECU through the BM module, and the BM module performs ECU initialization;

[0057] Step 2: After initialization, check the ECU download using the BM_CheckEcuDownload command; then determine whether a program jump is needed based on the response of the BM_CheckEcuDownload command.

[0058] The specific flowchart of the BM module is as follows: Figure 2 As shown, the ECU is initialized first. After initialization, the ECU download is checked. If the check does not require downloading (no programming request received and APP data verification is correct), the program jumps to run the APP (Application) application, thereby realizing the management of the BootLoader.

[0059] In practice, the workflow of the FBL module includes the following steps:

[0060] Step 01: Step 34; First, set the steps to 34 during initialization. After receiving the 34 service from the host computer, save the starting address and length carried by the 34 service, and change the steps to 36.

[0061] In step 34, UDS service 34 calls the FBL_Dcm0x34Call interface to process the data download request, and returns the processing result after processing is completed;

[0062] Step 02: Step 36; After receiving the 36 service from the host computer, check the data range and record the transmitted data, and at the same time check whether the segment data has been downloaded completely; when the segment data has been downloaded completely, change the step to step 37;

[0063] In step 36, UDS's service 36 calls the FBL_Dcm0x36Call interface to transmit data. In FBL_Dcm0x36Call, the data transmission can choose whether to perform verification calculations on the data.

[0064] Step 03: Step 37; After receiving the 37 service from the host computer, stop data transmission and change the step to step 34 or the verification step;

[0065] like Figure 4 The 34th step or the verification step are two different step states, indicating that the 34th service or the 31st verification routine can pass correctly when received;

[0066] Step 04: Verification Step; After the host computer sends the 31 verification routine, save the data verification value sent by the host computer and change the step to an erase step or a dependency check step.

[0067] The erase step is set when the 31 check routine is received after the Flash driver download is complete; the dependency check step is set when the 31 check routine is received after all APP data has been downloaded.

[0068] Step 05: Erasure Step; After receiving the erase routine 31 sent by the host computer, record the starting address and length of the erase, verify whether the erase range is within the specified range, and after completing the preparations before erasure, change the step to step 34 to download the APP data;

[0069] Once the APP data download in step 05 is complete and verified to be correct, the step changes to the dependency check step in step 06.

[0070] Step 06: Dependency check step; At this time, the dependency check will be received from the host computer. After the dependency check is completed, the APP validity flag will be changed to valid and written to the memory space. The program will then wait for a reset.

[0071] The dependency check in this invention is a fixed service in the download process, and the specific processing needs to be written according to the requirements of the car OEM.

[0072] The specific flowchart of the FBL module is as follows: Figure 3 As shown, the data processing flow in FBL consists of six steps: steps 34, 36, 37, erasure, verification, and dependency check. Upon receiving a service from the host computer, the service is compared with the current step. If the service matches the current step, the relevant data processing is executed; otherwise, the current download process is stopped.

[0073] As the data download processing module, FBL has a strict data processing and process control mechanism. During data processing, it checks the integrity of the data and the range of data download. It also checks the correctness of the current running steps based on the data download status and process. Parameters such as logical block addresses and lengths can be configured through the configurator. The FBL module provides diagnostic interfaces for UDS-related services for UDS to call. For example, UDS service 34 calls the FBL_Dcm0x34Call interface to process data download requests and returns the processing result after completion. UDS service 36 calls the FBL_Dcm0x36Call interface for data transmission. In FBL_Dcm0x36Call, data transmission can choose whether to perform verification calculations. UDS routine 31's integrity verification service calls the FBL_Dcm0x310202Call interface to verify the integrity of downloaded data.

[0074] In specific implementation, the state of the Flash driver in the FBL module is divided into the state of waiting to be downloaded, the state of downloading, the state of verification, the state of waiting to be initialized, the state of idle, the state of erasure, and the state of programming.

[0075] The process of various state changes in the Flash driver, such as Figure 5 The Flash driver performs relevant operations on the data based on the state, and the specific state changes include the following 11 states.

[0076] State 1: The program initializes the Flash memory to a pending download state;

[0077] State 2: When 36 service data is received, the state will be changed to download state;

[0078] State 3: After receiving the 31 verification routine, change the state to verification state, and at the same time perform data verification on the downloaded Flash driver and compare the calculated verification result with the verification value sent by the host computer.

[0079] Status 4: After verification is completed, the status is changed to pending initialization, and the Flash driver initialization is executed at this time;

[0080] State 5: After initialization is complete, the state changes to idle.

[0081] State 6: After receiving the 31 erase routine, the state is set to erase state, and the Flash executes the erase task. At this time, the erase is performed according to the erase address and length sent by the host computer.

[0082] State 7: The erasure is complete and the state changes to idle.

[0083] State 8: When receiving 36 service data transmission, the state changes to programming state and executes programming task. During programming, it checks whether the length of the temporarily stored data and the length of the data to be programmed meet the length of Flash write at one time. If not, the data is temporarily stored and waits for the next programming. If it meets the requirements, the data is written to the storage space according to the address.

[0084] State 9: After programming is completed, the state changes to idle state;

[0085] State 10: After receiving the 31 verification routine, the state is changed to verification state and the verification task is executed. At this time, the data is read from the storage space and the verification is calculated. The calculation result is compared with the verification value sent by the host computer to see if they are the same.

[0086] Status 11: After verification is completed, the status changes to idle.

[0087] In practice, the SecM module performs data CRC verification.

[0088] In specific implementation, the SecM module includes the SecM_CreatCrc verification interface and the SecM_SoftwareCheck verification interface.

[0089] The verification flowchart of the SecM module is as follows: Figure 6 As shown. The SecM module, as a security module, ensures the integrity and validity of data by performing CRC (Cyclic Resundancy Check) verification. SecM provides two verification interfaces for data verification: (1) SecM_CreatCrc is used for CRC verification of small amounts of data, and returns the verification value after completion; (2) SecM_SoftwareCheck is used for integrity verification of the APP application, and returns the verification result after completion.

[0090] In practice, the configuration parameters of the application layer are configured through a configurator, and the generated configuration file code after the parameter configuration is completed is imported into the project code of the vehicle controller Bootloader.

[0091] The relevant parameters of the application layer can be configured through the configurator according to the actual memory allocation. After configuration, the generated configuration file code is imported into the project, avoiding the problem of manually modifying code parameters. Specific parameter configurations are shown in Tables 1 and 2, and the specific configuration process includes the following steps:

[0092] Step S1: First, enter the configurator and select the BM module; in the BM module, fill in the programming flag data (32-bit hexadecimal) in the ProgramFlagData field according to the design scheme;

[0093] Step S2: Select whether to use the USPR register to store the programming flags based on the chip usage. If the USPR register is selected, click TRUE; otherwise, no changes are needed (the default is FLASE).

[0094] Step S3: If the USPR register is not used to store the programming flag, the starting address for writing the programming flag to RAM needs to be configured and the address is filled into FlagRAMAddrss.

[0095] Step S4: Select whether to immediately switch programs (from Boot to App) after verifying the App's validity, depending on your needs. If you do not want to switch immediately, set WaitMode to TRUE; otherwise, no changes are needed (the default is FLASE).

[0096] Step S5: If WaitMode is set to TRUE, the waiting time in milliseconds needs to be entered in WaitTime.

[0097] Step S6: At this point, the relevant parameters of the BM module are configured. Next, the relevant parameters of the FBL module will be configured. First, open the FBL module in the configurator and fill in the starting address of the Flash driver in RAM into FlashDriverStartAddress.

[0098] Step S7: Enter the Flash driver length into FlashDriverLength;

[0099] Step S8: According to the memory partitioning scheme, fill in the starting address of the APP application into APPStartAddress;

[0100] Step S9: According to the memory partitioning scheme, fill in the starting address of the memory storage information and APP valid flag data into EEPROMStartAddress;

[0101] Step S10: Write the erase length of the Flash driver into FlashEraseLength according to the size of the Flash sector;

[0102] Step S11: Based on the content of the downloaded APP file, set the maximum number of download segments and fill the data into ParagraphMaxNumber;

[0103] Step S12: Based on the startup requirements, select whether to use the enhanced check mode (when the APP flag is valid, all blocks are CRC checked to verify the validity of the APP data again). If enhanced check is used, set EnhancesCheckMode to TRUE; otherwise, no changes are needed (the default is FLASE).

[0104] Step S13: Write the logical block length into BlockLength according to the memory partitioning scheme;

[0105] Step S14: Write the starting address of the logical block to BlockAddress according to the memory partitioning scheme;

[0106] Step S15: After configuring the relevant parameters, click the verification button. After verification, click generate code. At this time, the configurator generates the configuration files (.c file and .h file) of the BM module according to the relevant configuration. Import the files into the Boot project code.

[0107] Table 1: BM Module Configuration Parameters

[0108]

[0109]

[0110] Table 2: FBL Module Configuration Parameters

[0111]

[0112]

[0113] In specific implementation, the configurator includes a configurator body with basic functions and module plugins with module functions; the configurator body includes an application service module and a database service module; the application service module includes a backend service module and a web page service module;

[0114] The module plugin includes a general plugin module; the general plugin module is used to generate a module parameter configuration page based on the user's module page description file, then perform constraint verification on the parameter configuration of the user in the module parameter configuration page, and finally generate a descriptive code file after the constraints are correct.

[0115] In practice, the general plugin module includes a module page plugin, a module constraint plugin, and a code template generation plugin, which communicate with the configurator main body through their respective access methods.

[0116] In practice, the module page plugin is implemented as follows:

[0117] Users define AUTOSAR-compliant module arxml files, convert them through corresponding plugin interfaces, and then interact with the configurator main body through a page access method to generate a module visual configuration interface. The visual configuration interface is connected to the configurator main body for data interaction using a micro-frontend approach.

[0118] The implementation principle of the configurator is as follows: Figure 7 As shown. The configurator is a pluggable AUTOSAR configuration tool based on a web architecture, employing a B / S (browser / server) model. It centralizes the load balancer, application services, and database services on a server, sending requests to the server via a web browser. The server integrates a load balancer, and users access the AUTOSAR configuration tool interface through a hidden link address provided by the load balancer. During operation, the interface initiates HTTP requests, which are then evenly forwarded to the application services by the load balancer.

[0119] Users access the configurator interface through a hidden link address provided by the load balancer. During the operation of the interface, HTTP requests are initiated. The load balancer forwards the requests evenly to the application service. After parsing the requests, the application service processes them logically and interacts with the database service to exchange data. Finally, the page data is returned to the web browser, thus completing the entire interaction process.

[0120] In existing technologies, the modules managed by the configurator are fixed, and users cannot customize the module structure type within the configuration tool. To meet the diverse needs of more users, this invention, based on the aforementioned web configuration tool implementation, implements a plug-in approach for module configuration. The application service is functionally decomposed, with the basic functions of the configuration tool as the core and module functions as extensible plug-ins. The web configurator itself remains a complete web service system.

[0121] The main components of the web configurator still include application services and database storage services. The application services further include backend services and web page services. The backend services interact directly with the database to store and retrieve configuration data, while the web page calls functions from the backend service interfaces. The relationship between the three is as follows: Figure 8 As shown.

[0122] The AUTOSAR module structure adheres to the AUTOSAR standard, laying a solid foundation for modularization. According to the standard, a set of standard plug-in interfaces is defined in the configurator body. These interfaces define the communication methods between the plug-in and the configurator body, including data input / output and function calls. The configurator body and module plug-ins communicate through the plug-in interfaces defined in the AUTOSAR standard to achieve data input / output and function calls.

[0123] The module plugin consists of three parts: the module page, module constraints, and generated code templates. These components communicate with the configurator body through their respective access methods, enabling successful interaction between the module plugin and the configurator body to perform parameter configuration, constraint validation, and code generation functions. The implementation method for integrating the module plugin with the configuration tool is as follows: Figure 9 As shown.

[0124] Module page implementation: User-defined AUTOSAR-compliant module arxml files are converted via corresponding plugin interfaces. The converted files then interact with the configurator main body through a page access method, generating a visual configuration interface for the module. The parameter configuration interface uses a micro-frontend approach to connect to the configurator main body for data interaction. The interface includes descriptions of each parameter and unit controls for different parameter types, providing a convenient parameter configuration method.

[0125] Module constraint implementation method: The script is coded according to the constraint code specification and communicates with the main body of the configurator through the constraint access method. The main body of the configurator contains a script parsing method to verify the parameter configuration of the user in the configuration interface and to prompt for incorrect parameters.

[0126] Code generation implementation method: Write templates according to the code generation template specifications, communicate with the configurator main body through the template access channel, process the parameter values ​​that have been verified to be correct, and generate corresponding descriptive code files.

[0127] Once the module plugin is integrated into the main configurator, it will become part of a complete web configuration tool, allowing the module to be configured and used within that tool. The usage process is as follows: Figure 10 As shown.

[0128] Web-based configuration tools are accessible directly through a browser. By transforming the traditional configuration tool format and utilizing web technologies, they perfectly address the shortcomings of desktop-based tools. The link-based access reduces the tool's dependence on the user's device. Users can easily access the tool via a browser on their mobile phones or computers. Server-wide updates and centralized data storage eliminate the need for additional user intervention, making it more suitable for enterprise users.

[0129] The plugin module also includes user plugin modules developed according to interface standards. The plugin-based design of the configuration tool allows users to customize development according to project needs, and communication between plugins and the core entity uses the interface standards provided by the developers. Users can use either the unified module plugins provided by the developers or develop custom template plugins according to the interface standards. General plugin development does not require modification of the application's core code, resulting in significantly lower costs compared to developing the overall architecture of the configuration tool. Its high flexibility can meet the needs of most customers in the market.

[0130] By breaking down functionality into independent plugins, developers can more easily locate and resolve issues. Furthermore, the independence and modularity of plugins make the code easier to understand and maintain. Plugin-based design can restrict plugins' access to the application's core code, thereby improving application security and protecting developers' intellectual property.

[0131] This invention presents a modular vehicle controller bootloader. The proposed bootloader solution is based on the advanced concept of modular programming and cleverly employs the mature and reliable AUTOSAR architecture, achieving decoupling of hardware and software. Through standardized interfaces and parameter configuration sets, it not only enables easy portability of the bootloader software across different chips but also allows engineers to quickly adjust software settings according to specific chip characteristics and functional requirements. This solution significantly improves the portability and ease of use of the bootloader software.

[0132] To improve the portability of BootLoader software and address issues such as significant modifications to the BootLoader program when hardware platforms change, and manual modification of code parameters during debugging, this invention, based on the modular programming concept, constructs a modular vehicle controller Bootloader that can be quickly ported and has configurable parameters. This invention designs various functions, such as communication, diagnostics, and low-level drivers, as modules, and uses a configurator to generate corresponding configuration sets, thereby adapting to different chips and significantly improving the portability and ease of use of the BootLoader software. In the BootLoader application layer, the configurator configures key parameters in the BootLoader, generating relevant configuration code files that are imported into the BootLoader project, thus enabling configurable parameters in the BootLoader application layer.

[0133] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0134] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A modular vehicle-mounted controller bootloader, characterized in that, It includes a microcontroller abstraction layer (MCAL), a communication and diagnostic module, and an application layer; the microcontroller abstraction layer (MCAL) adopts the MCAL driver of the AUTOSAR specification; the communication and diagnostic module is based on AUTOSAR specification for CAN communication and UDS diagnostics. The application layer includes the BM module, the FBL module, and the SecM module; The BM module is used to initialize the ECU and check the download to the ECU after initialization, manage the jump of the BootLoader execution or the refresh of the APP program, and execute the initialization of the Microcontroller Abstraction Layer (MCAL) driver. The workflow of the BM module includes the following steps: Step 1: The user sends the initialization command BM_InitEcu to the ECU through the BM module, and the BM module performs ECU initialization; Step 2: After initialization, the ECU download is checked through the BM_CheckEcuDownload command; then the response of the BM_CheckEcuDownload command determines whether a program jump is needed; if no programming request is received and the APP data is verified to be correct, the program jump is performed and the APP is run; Based on startup requirements, select whether to use enhanced verification mode: when the APP flag is valid, perform CRC check on all blocks to verify the validity of the APP data again; Choose whether to immediately redirect the app after verifying its validity, depending on your needs; use the wait mode if you do not want to immediately redirect the app. The FBL module is used to provide the UDS with relevant download service processing interfaces for data processing in the download process; the data processing process of the FBL module includes steps 34, 36, 37, erasure step, verification step, and dependency check step; when a service is received from the host computer, the service is compared with the current step; if the service matches the current step, the relevant data processing is performed; otherwise, the current download process is stopped. The SecM module is used to perform data verification tasks; ensuring the integrity and validity of data and performing CRC checks; the SecM module includes the SecM_CreatCrc verification interface and the SecM_SoftwareCheck verification interface, wherein the SecM_CreatCrc verification interface is used for CRC checks of a small amount of data and returns the verification value after completion; the SecM_SoftwareCheck verification interface is used for integrity checks of the APP application and returns the verification result after verification.

2. The modular vehicle controller bootloader according to claim 1, characterized in that, The workflow of the FBL module includes the following steps: Step 01: Step 34; First, set the steps to 34 during initialization. After receiving the 34 service from the host computer, save the starting address and length carried by the 34 service, and change the steps to 36. Step 02: Step 36; After receiving the 36 service from the host computer, check the data range and record the transmitted data, and at the same time check whether the segment data has been downloaded completely; when the segment data has been downloaded completely, change the step to step 37; Step 03: Step 37; After receiving the 37 service from the host computer, stop data transmission and change the step to step 34 or the verification step; Step 04: Verification Step; After the host computer sends the 31 verification routine, save the data verification value sent by the host computer and change the step to an erase step or a dependency check step. Step 05: Erasure Step; After receiving the erase routine 31 sent by the host computer, record the starting address and length of the erase, verify whether the erase range is within the specified range, and after completing the preparations before erasure, change the step to step 34 to download the APP data; Step 06: Dependency check step; At this time, the dependency check will be received from the host computer. After the dependency check is completed, the APP validity flag will be changed to valid and written to the memory space. The program will then wait for a reset.

3. The modular vehicle-mounted controller bootloader according to claim 1, characterized in that, In the FBL module, the Flash driver states are divided into four states: waiting to be downloaded, downloading, verification, waiting to be initialized, idle, erasing, and programming.

4. A modular vehicle-mounted controller bootloader according to claim 1, characterized in that, The SecM module performs CRC verification on the data.

5. A modular vehicle-mounted controller bootloader according to claim 1, characterized in that, The configuration parameters of the application layer are configured through a configurator, and the generated configuration file code after parameter configuration is imported into the project code of the vehicle controller Bootloader.

6. A modular vehicle controller bootloader according to claim 5, characterized in that, The configurator includes a main configurator body with basic functions and module plugins with modular functions; the main configurator body includes an application service module and a database service module; the application service module includes a backend service module and a web page service module; The module plugin includes a general plugin module; the general plugin module is used to generate a module parameter configuration page based on the user's module page description file, then perform constraint verification on the parameter configuration of the user in the module parameter configuration page, and finally generate a descriptive code file after the constraints are correct.

7. A modular vehicle-mounted controller bootloader according to claim 6, characterized in that, The general plugin module includes a module page plugin, a module constraint plugin, and a code template generation plugin, which communicate with the configurator main body through their respective access methods.

8. A modular vehicle-mounted controller bootloader according to claim 7, characterized in that, The module page plugin is implemented as follows: Users define AUTOSAR-compliant module arxml files, convert them through corresponding plugin interfaces, and then interact with the configurator main body through a page access method to generate a module visual configuration interface. The visual configuration interface is connected to the configurator main body for data interaction using a micro-frontend approach.

Images