Method and device for checking communication bus in micro-control unit, and electronic equipment

Abstract

The invention discloses a verification method and device for a communication bus in a micro-control unit and electronic equipment. Wherein the micro-control unit comprises a plurality of cores and a communication bus, the cores are used for communicating through the communication bus, and the method comprises the following steps: responding to a communication task sent to the communication bus by the cores, and obtaining authority information of the communication bus; in response to the condition that the permission information indicates that the core has the calling permission, obtaining various kinds of state information of the communication bus, and in response to the condition that the corresponding state information of the core indicates that the communication bus is in an idle state relative to the core, verifying the communication bus to obtain a first verification result; and in response to the permission information that the core does not have the call permission, or in response to the permission information that the core has the call permission, obtaining various state information of the communication bus, and in response to the state information that the communication bus is in an occupied state for the core, verifying the communication bus to obtain a second verification result. The technical problem that the verification effect of the communication bus in the micro-control unit is poor is solved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a verification method, device and electronic equipment for a communication bus in a micro control unit. Background Art

[0002] At present, in current automotive electronic control units, with the improvement of intelligence and functional integration, microcontroller units (MCUs) are rapidly evolving towards multi-core heterogeneous architectures to meet the growing demand for computing power and functional safety requirements. Especially in the face of application scenarios such as intelligent driving and smart cockpits that have extremely high requirements for real-time and data processing capabilities, multi-core MCUs can provide more powerful parallel processing capabilities and resource allocation flexibility, thus becoming a trend in industry development. However, the parallel computing advantages brought by the multi-core architecture also bring challenges of resource access conflicts and data consistency issues. Among them, the Serial Peripheral Interface (SPI) bus is a high-speed synchronous serial communication interface widely used in automotive electronic control units, and its driver has encountered significant bottlenecks in multi-core deployment.

[0003] In related technologies, SPI drivers employ mechanisms such as spin locks or status flags to avoid bus deadlocks, specifically to prevent multiple cores from accessing SPI hardware simultaneously, leading to communication interruptions or data loss. However, these mechanisms suffer from flaws in managing the critical state machine for multi-core concurrent operations and fail to fully address data consistency issues. For example, when two or more cores simultaneously attempt to modify the usage flags of SPI hardware, concurrent operations may lead to data inconsistencies, potentially causing misjudgments of status. In some cases, both cores may mistakenly believe that a data transfer has been successfully completed, when in fact only one core has actually performed the transfer. This can lead to subsequent misjudgments of status, impacting communication reliability and system performance. Consequently, the technical issue of poor verification of the communication bus in microcontrollers persists.

[0004] Currently, no effective solutions have been proposed for the above technical problems. Summary of the Invention

[0005] Embodiments of the present invention provide a method, device, and electronic device for verifying a communication bus in a micro control unit, so as to at least solve the technical problem of poor verification effect of the communication bus in the micro control unit.

[0006] According to one aspect of an embodiment of the present invention, a method for verifying a communication bus in a microcontroller unit is provided. The microcontroller unit includes multiple cores and a communication bus, wherein different cores are used to run different functional domains, and the cores are used to communicate via the communication bus. The method may include: in response to a core sending a communication task to the communication bus, obtaining permission information of the communication bus, wherein the permission information is used to indicate whether the core has call permission to the communication bus; in response to the permission information indicating that the core has call permission, obtaining multiple status information of the communication bus, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, verifying the communication bus to obtain a first verification result, wherein the multiple status information corresponds one-to-one to the multiple cores, and the first verification result is used to indicate that the core is allowed to call the communication bus to perform the communication task; in response to the permission information indicating that the core does not have call permission, or in response to the permission information indicating that the core has call permission, obtaining multiple status information of the communication bus, and in response to the status information indicating that the communication bus is in an occupied state for the core, verifying the communication bus to obtain a second verification result, wherein the second verification result is used to indicate that the core is prohibited from calling the communication bus to perform the communication task.

[0007] Optionally, in response to the permission information indicating that the core has the calling permission, multiple status information of the communication bus is obtained, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, the communication bus is verified to obtain a first verification result, including: in response to the permission information indicating that the core has the calling permission, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state, obtaining the driver coding information of the communication bus; using the driver coding information, driving the communication bus to perform a communication task; and determining the first verification result in response to driving the communication bus to complete the communication task.

[0008] Optionally, the core is used to communicate with an external device through a communication bus. The core includes at least one communication bus hardware interface. The communication bus hardware interface is used to connect to at least one external device through the communication bus. The driver coding information is used to drive the communication bus to perform a communication task, including: detecting the communication bus hardware interface to be driven to obtain a first detection result; in response to the first detection result that the communication bus hardware interface to be driven has not been called by a core other than the current core among multiple cores, the driver coding information is used to drive the communication bus hardware interface to perform a communication task through the communication bus, so that the core communicates with the external device.

[0009] Optionally, the method also includes at least one of the following: responding to a macro definition instruction, based on the permission information, adding first macro definition information and second macro definition information in the driver coding information, wherein the first macro definition information is used to indicate that the core has the calling permission, and the second macro definition information is used to indicate that the core does not have the calling permission; responding to a constant setting instruction, based on the permission information, adding first constant information and second constant information in the driver coding information, wherein the first constant information is used to indicate that the core has the calling permission, and the second constant information is used to indicate that the core does not have the calling permission.

[0010] Optionally, the driver coding information includes a communication function, and different communication functions perform different communication tasks. The method also includes: in the process of using the driver coding information to drive the communication bus to perform the communication task, detecting the core that calls the communication function to obtain a second detection result; in response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, determining a second verification result.

[0011] Optionally, the method includes at least one of the following: in response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, generating a prompt message based on the identification information of the communication function, and storing the prompt information in the storage medium of the microcontroller unit, wherein the prompt information is used to prompt that the communication function executes the communication task incorrectly; in response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, sending identification information to the core that initiates the communication task; in response to the core that initiates the communication task receiving the identification information and the communication bus being in an idle state, calling the communication function corresponding to the identification information to execute the communication task.

[0012] Optionally, before responding to the core sending a communication task to the communication bus and obtaining permission information of the communication bus, the method also includes: obtaining a target number of cores in the microcontroller unit; based on the target number, determining the array length of the state array, wherein the state array includes multiple state information, and the array length is used to represent the number of state information in the state array.

[0013] According to another aspect of an embodiment of the present invention, a device for verifying a communication bus in a microcontroller unit is provided. The microcontroller unit includes multiple cores and a communication bus, wherein different cores are used to run different functional domains, and the multiple cores are used to communicate via the communication bus. The device may include: an acquisition unit, configured to, in response to a core sending a communication task to the communication bus, obtain permission information of the communication bus, wherein the permission information indicates whether the core has the right to call the communication bus; a first verification unit, configured to, in response to the permission information indicating that the core has the right to call, obtain multiple status information of the communication bus, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, verify the communication bus to obtain a first verification result, wherein the multiple status information corresponds one-to-one to the multiple cores, and the first verification result indicates that the core is allowed to call the communication bus to perform the communication task; a second verification unit, configured to, in response to the permission information indicating that the core does not have the right to call, or in response to the permission information indicating that the core has the right to call, obtain multiple status information of the communication bus, and in response to the status information indicating that the communication bus is in an occupied state for the core, verify the communication bus to obtain a second verification result, wherein the second verification result indicates that the core is prohibited from calling the communication bus to perform the communication task.

[0014] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the above method of the embodiment of the present invention.

[0015] According to another aspect of an embodiment of the present invention, a processor is provided, which is configured to run a program, wherein the program executes the above method of the embodiment of the present invention when it is run.

[0016] According to another aspect of an embodiment of the present invention, an electronic device is provided, which includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the above method of the embodiment of the present invention.

[0017] According to another aspect of an embodiment of the present invention, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, it implements the above method of the embodiment of the present invention.

[0018] According to another aspect of an embodiment of the present invention, a vehicle is further provided, which is used to execute the above method of the embodiment of the present invention.

[0019] The core of this embodiment of the present invention is the implementation of dynamic permission and status verification. Specifically, for each core sending a communication task request to the communication bus, the permission information of the communication bus is obtained in real time to determine whether the core has the legal permission to call the specific communication bus. This mechanism solves the problem of static binding in related technologies that lacks dynamic verification capabilities, ensuring that only authorized cores can access the corresponding communication bus and avoiding unexpected resource access conflicts. For cores with call permission, the corresponding status information can be further checked to determine whether the communication bus is currently idle. Only when the communication bus is idle and the core has permission is the communication bus verified, resulting in a first verification result indicating that the core can safely call the bus to perform the communication task. This method ensures the rational utilization of communication bus resources, avoids data consistency issues and logical errors caused by concurrent operations, and improves the execution efficiency of communication tasks and system performance. For cores that do not have call permission, or even if they have permission but the communication bus is currently occupied, a second verification result can be obtained, indicating that the core is prohibited from calling the communication bus to perform the communication task.

[0020] In summary, dynamic verification of permission and status information enables precise management and control of the communication bus, effectively resolving communication bus resource access conflicts and data consistency issues in a multi-core architecture. This significantly improves the verification effectiveness of the communication bus within the microcontroller unit and the overall reliability of communication task execution. This achieves the technical effect of improving verification effectiveness of the communication bus within the microcontroller unit and resolves the technical issue of poor verification effectiveness of the communication bus within the microcontroller unit. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0022] Figure 1 is a flow chart of a method for verifying a communication bus in a micro control unit according to an embodiment of the present invention;

[0023] Figure 2 2 is a schematic diagram of a communication bus verification device in a micro control unit according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0025] It should be noted that the terms "first," "second," and the like in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the numbers used in this way are interchangeable where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or apparatus.

[0026] According to an embodiment of the present invention, an embodiment of a method for verifying a communication bus in a microcontroller unit is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0027] Figure 1 FIG. 1 is a flow chart of a method for verifying a communication bus in a microcontroller unit according to an embodiment of the present invention. Figure 1 As shown, the microcontroller unit includes multiple cores and a communication bus, different cores are used to run different functional domains, and the cores are used to communicate through the communication bus. The method may include the following steps:

[0028] Step S102 : in response to the core sending a communication task to the communication bus, obtaining permission information of the communication bus.

[0029] In the technical solution provided in the above step S102 of the present invention, the permission information is used to indicate whether the core has the right to call the communication bus. The permission information can be included in the configuration information of the communication bus, for example, in the configuration SPI. The permission information can be included in the configuration information of the communication bus. Taking SPI as an example, the configuration information defines which core (or a group of cores) is authorized to access and use the SPI bus. The above configuration can be carried out in a variety of ways, including but not limited to: hardware configuration. During the system design phase, the access rights of the SPI bus may have been fixed through hardware settings, such as through jumpers, configuration registers or other dedicated hardware logic. Software configuration. At the software level, the permission information may be stored in a configuration file or database, which is read and updated by the operating system or middleware management system at runtime to ensure that the access rights of the core and the bus remain up to date and accurate. Dynamic allocation. In some advanced systems, permission information may be dynamically allocated based on the real-time system status and load, which can achieve more flexible task scheduling and resource management.

[0030] Optionally, communication tasks can be of various types in a multi-core MCU, including SPI transfer tasks, which enable high-speed, synchronous data exchange between the microcontroller and peripherals. An SPI transfer task can include the following: a data packet containing the data to be transmitted over the SPI bus; a device identifier specifying the address or identifier of the SPI peripheral with which to communicate; and transmission parameters such as data length, transmission direction (read or write), clock speed, clock polarity, and phase, which define the specific mode and conditions of SPI communication. A communication task can be an SPI transfer task.

[0031] In this embodiment, if it is detected that the core has sent a communication task to the communication bus, permission information of the communication bus may be obtained.

[0032] Optionally, obtaining permission information of the communication bus in response to a core sending a communication task to the communication bus is a key control step in a multi-core MCU system, which aims to ensure that each core has both secure and efficient access to the communication bus.

[0033] Alternatively, in a multi-core MCU architecture, different cores can simultaneously run within their respective functional domains, handling different tasks. When a core needs to exchange data with another peripheral (external device) or core via a communication bus, it sends a communication request (communication task) to the bus. Because the communication bus is a shared resource, a mechanism must be in place to coordinate who can use it and when, to avoid conflicts and data confusion.

[0034] Optionally, access permissions for the communication bus can be pre-configured during MCU startup or system initialization, for example, based on the system's security requirements, performance goals, and peripheral device characteristics. This permission information can be stored in system memory, non-volatile memory, or dedicated configuration registers to ensure that it remains accessible throughout the entire operating cycle.

[0035] Optionally, when a core is about to send a communication task, it queries the communication bus's permission information to confirm whether it is authorized to use the bus. This query process may involve reading a permission table in memory, querying specific bits in a configuration register, or calling an application programming interface (API) provided by the operating system. After obtaining the permission information, the core parses and verifies the permission information to determine whether it has permission to access the target communication bus. If the permission verification fails, the core will not continue to send the communication task and may take other measures, such as reporting an error, switching to an alternative bus, or waiting for permission to be assigned.

[0036] Step S104 , in response to the permission information indicating that the core has the calling permission, obtaining various status information of the communication bus, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, verifying the communication bus to obtain a first verification result.

[0037] In the technical solution provided in the above step S104 of the present invention, the multiple state information corresponds one-to-one to the multiple cores, and the first verification result is used to indicate that the core is allowed to call the communication bus to perform the communication task.

[0038] Optionally, status information includes but is not limited to the following: communication bus usage status, indicating whether the bus is currently occupied, which is the most basic communication bus status and is used to avoid resource conflicts; core usage permission status, reflecting each core's access rights to the bus, ensuring that only authorized cores can use the bus, improving security; transmission task queue status, displaying a list of tasks waiting to be executed, helping the system schedule and prioritize tasks; error status, recording errors that occur in bus communication, such as data verification failure, timeout, etc., for later troubleshooting; configuration status, saving the current bus configuration parameters, such as clock polarity, phase, data format, etc., to ensure that new tasks are compatible with existing configurations.

[0039] Optionally, the state information can be organized into a core-level state array to achieve seamless integration with multi-core architectures. The length of the array is equal to the number of cores, with one array element corresponding to each core, and each element storing bus state information specific to that core.

[0040] In this embodiment of the present invention, the core-level state array has the following advantages: Each core's state information is stored independently, avoiding race conditions and deadlock issues that may arise from state sharing. The interaction status between each core and the bus can be monitored in real time, enabling timely scheduling decisions and improving communication efficiency. As the number of cores increases, simply adjusting the array length can adapt to the new architecture and maintain system stability.

[0041] Optionally, the first verification result is mainly used to confirm whether the specific core is allowed to call the communication bus to perform the communication task. The first verification result may be "OK".

[0042] In this embodiment, after obtaining permission information for the communication bus, if it is determined that the core has call permission, various status information of the communication bus can be obtained. If the status information corresponding to the core indicates that the communication bus is in an idle state for the core, the communication bus can be verified to obtain a first verification result.

[0043] Optionally, this embodiment is a series of key control and verification steps before the core calls the communication bus to perform a communication task, and its core is to ensure the safe and efficient use of bus resources.

[0044] Optionally, before executing a communication task initiated by a core, it can be verified whether the core is authorized to use the communication bus. This verification is based on permission information, which predefines which core(s) can access a particular communication bus. If the permission information indicates that the core is authorized to use the bus, then the core can proceed to the next step of the process; otherwise, the task may be rejected or rerouted to a core with permission.

[0045] Optionally, once the permission verification is passed, various status information of the communication bus can be obtained. The above status information is multi-dimensional, including but not limited to: bus usage status, which determines whether the bus is currently occupied, which is an important basis for determining whether the core can immediately initiate a communication task. Core usage history, which records which cores have used the bus in the past, helps to understand the frequency and pattern of bus usage, and provides a reference for dynamic resource allocation. Task queue information, which displays the communication tasks currently waiting to be executed, helps the system determine the priority of task execution. Configuration status, confirms whether the current configuration of the bus is suitable for the communication task to be executed, such as clock frequency, data width and other settings. The above status information is stored in the form of a core-level status array, and each core corresponds to an element in the array, which contains all status information related to the core. This design ensures the independence and real-time nature of the status information, avoids mutual interference of status information between multiple cores, and enhances the robustness of the system.

[0046] Optionally, the bus usage status in the core's corresponding status information is further checked to confirm whether the bus is idle for the specific core. The above step is crucial because even if the core has the call permission, if the communication bus is being used by another communication task, then immediately initiating a new communication task may cause data conflicts or communication errors.

[0047] Optionally, after the core's permission information and bus usage status meet the requirements, the communication bus is verified to ensure that the bus is in good working condition and can support the upcoming communication task. The verification process may include: hardware status verification, checking whether the bus hardware is operating normally, such as the stability of the clock signal and data line; software configuration verification, ensuring that the bus configuration parameters match the task to be executed, such as data format and transmission rate; error status verification, detecting whether the bus has any unresolved errors, such as communication timeouts and signal interference. The first verification result reflects a comprehensive evaluation of the above verification steps. If the verification is successful, the first verification result allows the core to call the communication bus to perform the communication task, indicating that the system believes that the bus resources are available and the conditions for task execution are appropriate. Conversely, if any verification step fails, the first verification result will prevent the task from being executed, and the system may need to take measures, such as reporting an error, reconfiguring the bus, or rescheduling the task to another core.

[0048] In this embodiment of the present invention, permission information verification, acquisition of communication bus status information, idle state checking, and communication bus verification together constitute the complete control process for a multi-core MCU system to call the communication bus. This process ensures efficient resource management, secure communication task execution, and flexible task scheduling. By utilizing the core-level status array and the first verification result, the system can dynamically adapt to the characteristics of the multi-core environment, avoid resource conflicts, and improve overall performance.

[0049] Step S106, in response to the permission information indicating that the core does not have the calling permission, or in response to the permission information indicating that the core has the calling permission, obtain multiple status information of the communication bus, and in response to the status information indicating that the communication bus is in an occupied state for the core, verify the communication bus to obtain a second verification result.

[0050] In the technical solution of step S106 of the present invention, the second verification result is used to indicate that the core is prohibited from calling the communication bus to perform the communication task.

[0051] Optionally, the generation of the second verification result can be triggered by two conditions: If the permission information indicates that the core does not have permission to call the communication bus, a second verification result is generated directly, indicating that the call is prohibited. Even if the core has permission to call, if the status information indicates that the communication bus is currently occupied by the core, that is, the bus is busy executing tasks of other cores or undergoing maintenance, a second verification result will be generated, prohibiting the call. The second verification result is essentially a blocking mechanism, issuing a stop signal when a core attempts to call the communication bus but does not meet the call conditions. The significance of the second verification result is to ensure that the system adheres to pre-defined permission rules, and only authorized cores can initiate communication tasks, thereby maintaining system security and order. By monitoring the bus status in real time, conflicts and waste of bus resources can be avoided, ensuring that ongoing tasks are not interrupted, and maintaining stable and efficient communication. If the bus is occupied or the core does not have permission, returning the second verification result early can prevent the initiation of invalid tasks, reduce potential system errors, and provide guidance for subsequent task rescheduling or error handling.

[0052] Optionally, the second verification result may be “not OK” or “non-OK”.

[0053] In this embodiment, if the permission information indicates that the core does not have the calling permission, or the permission information indicates that the core has the calling permission but the obtained status information indicates that the communication bus for the core is occupied, the communication bus can be checked to obtain a second verification result.

[0054] Optionally, in the complex communication environment of a multi-core MCU, the above steps are necessary to ensure the rational allocation and safe use of system resources. The above steps involve checking the permission of the core to call the communication bus, obtaining status information, and generating a second verification result based on this information, ultimately deciding whether to prohibit the core from calling the communication bus.

[0055] Optionally, when a core attempts to invoke a communication task on the communication bus, its permissions information can be checked. If the permissions information indicates that the core is not authorized to invoke the bus, a second check result is generated without obtaining further status information, explicitly indicating that the core does not possess the required permissions, thus prohibiting the task from executing. This step ensures that all communication task invocations comply with established permissions rules, maintaining the security of system operations.

[0056] Optionally, if the permission information verification passes, indicating that the core has call permission, a deeper level of status information checking will be performed. Various communication bus status information is obtained, the most critical of which is the current bus usage status. If the status information indicates that the communication bus is occupied by the core, that is, the bus is being used by another core or task, further verification is performed, generating a second verification result.

[0057] Optionally, whether the core does not have permission to call the bus or the core has permission but the bus is currently occupied, the system will perform a comprehensive check of the communication bus, including but not limited to hardware status check, software configuration review, task priority assessment, etc., to generate a second check result. The main function of the second check result is to prohibit the core from calling the communication bus to perform communication tasks. Ensure that the bus hardware is not faulty or under maintenance. Check whether the bus software configuration supports the communication requirements of the current core, such as whether the data format, clock rate, etc. match. If the bus is occupied, the priority of other tasks in the waiting queue can also be evaluated to determine whether it is necessary or appropriate to delay the current core's task.

[0058] Optionally, the second check result represents a prohibition, notifying the core attempting to access the communication bus that it cannot execute the proposed communication task due to insufficient permissions or because the bus is currently occupied. This result generation and feedback mechanism is an important safety and control measure in multi-core communication systems. It not only prevents unauthorized task execution but also avoids system efficiency degradation and even errors caused by resource conflicts.

[0059] Optionally, once the second verification result is generated, one or a combination of the following actions may be taken: The current core's task may be temporarily stored or rescheduled to a time when the communication bus becomes available. An error message may be sent to the system log or developer interface, indicating the reason why the task was blocked from accessing the bus. If the core is not authorized, the system may prompt the user or developer to adjust permission settings to ensure that future tasks can legally access the bus. In some cases, other resource coordination may be attempted, such as transferring the task to another core with appropriate permissions and a currently idle bus.

[0060] Through the above mechanism, the multi-core MCU system can efficiently manage communication resources, ensure the safe calling of communication tasks, avoid unnecessary resource waste and task execution delays, and at the same time provide clear guidance and feedback to promote stable operation and optimization and upgrade of the system.

[0061] The core of the above steps S102 to S106 of the present application is to realize the verification of dynamic permissions and status. Specifically, for each core sending a request for a communication task to the communication bus, the permission information of the communication bus is obtained in real time to determine whether the core has the legal permission to call a specific communication bus. The above mechanism solves the problem of the lack of dynamic verification capability of static binding in related technologies, ensures that only authorized cores can access the corresponding communication bus, and avoids unexpected resource access conflicts. For cores with calling permissions, the corresponding status information can be further checked to determine whether the communication bus is currently in an idle state. Only when the communication bus is in an idle state and the core has permission, the verification of the communication bus will be performed to obtain a first verification result, indicating that the core can safely call the bus to perform the communication task. The above method ensures the rational use of communication bus resources, avoids data consistency problems and logical errors caused by concurrent operations, and improves the execution efficiency of communication tasks and system performance. For a core that has not obtained calling permission, or even if it has permission but the communication bus is currently occupied, a second verification result can be obtained, indicating that the core is prohibited from calling the communication bus to perform communication tasks, thereby achieving the technical effect of improving the verification effect of the communication bus in the microcontroller unit and solving the technical problem of poor verification effect of the communication bus in the microcontroller unit.

[0062] The above method of this embodiment is further introduced below.

[0063] As an optional embodiment, step S104, in response to the permission information that the core has the calling permission, obtain multiple status information of the communication bus, and in response to the status information corresponding to the core that the communication bus is in an idle state for the core, verify the communication bus to obtain a first verification result, including: in response to the permission information that the core has the calling permission, and in response to the status information corresponding to the core that the communication bus is in an idle state, obtain the driver coding information of the communication bus; use the driver coding information to drive the communication bus to perform the communication task; in response to driving the communication bus to complete the communication task, determine the first verification result.

[0064] In this embodiment, during verification of the communication bus to obtain a first verification result, if the permission information indicates that the core has call permission and the state information corresponding to the core indicates that the communication bus is in an idle state, driver coding information for the communication bus can be obtained. The driver coding information is used to drive the communication bus to perform a communication task. If the communication task is completed, the first verification result can be determined. The driver coding information can be an SPI driver code.

[0065] Optionally, in multi-core microcontroller systems, especially in applications involving high-speed communication buses such as SPI, ensuring the correct and efficient execution of communication tasks is crucial. This embodiment describes the entire process of obtaining and utilizing driver encoding information to drive the communication bus to execute the communication task and ultimately determine the first verification result when specific conditions are met (the core has call permission and the communication bus is in an idle state).

[0066] Optionally, when a core attempts to call a communication bus, it can check whether the core has been authorized (i.e., the permission information indicates that the core has the call permission). If the core has indeed been granted the call permission, the system will continue to check the current state of the communication bus to confirm whether it is idle. The idle state means that the communication bus has no ongoing communication tasks and can accept new task requests.

[0067] Optionally, in response to both of the above checks passing, the driver code information for the communication bus can be further obtained. This driver code information can refer to the driver code associated with the communication bus, such as the SPI driver code, which is the specific instruction sequence required to implement a specific communication task. This step ensures that the system is prepared with the appropriate driver code to control the communication bus, thereby efficiently executing the communication task.

[0068] Optionally, driver encoding information is used to drive the communication bus to perform communication tasks. This process includes loading the driver code into the core's execution context, setting the necessary communication parameters (such as clock speed and data width), and transmitting data through the bus's physical interface. In these steps, the driver encoding information acts as a bridge between the core and the communication bus, translating abstract communication instructions into concrete hardware operations.

[0069] Optionally, when the communication task is completed, a first verification result can be determined based on the task execution result. The first verification result reflects the operating status and performance of the communication bus during task execution. Typically, when the task is successfully completed without detecting any errors or anomalies, the first verification result indicates that the core is allowed to call the communication bus to execute the communication task, i.e., the verification is successful. The above steps not only verify the successful execution of the communication task but also confirm the effectiveness of the communication resource management of the multi-core MCU system.

[0070] Optionally, the first verification result is crucial for subsequent multi-core scheduling and communication task management. A successful verification indicates that resource allocation is reasonable and task execution is smooth, allowing for continued monitoring and scheduling of tasks on other cores. If the first verification result indicates a failure, this may indicate a hardware failure, software misconfiguration, or resource conflict. The system will need to implement error handling or resource rescheduling to ensure system stability and communication reliability.

[0071] As an optional embodiment, the core is used to communicate with an external device through a communication bus. The core includes at least one communication bus hardware interface. The communication bus hardware interface is used to connect to at least one external device through the communication bus. The driver coding information is used to drive the communication bus to perform a communication task, including: detecting the communication bus hardware interface to be driven to obtain a first detection result; in response to the first detection result that the communication bus hardware interface to be driven has not been called by a core other than the current core among multiple cores, the driver coding information is used to drive the communication bus hardware interface to perform a communication task through the communication bus, so that the core communicates with the external device.

[0072] In this embodiment, in the process of using the driver coding information to drive the communication bus to perform the communication task, the communication bus hardware interface to be driven can be detected to obtain a first detection result. If the first detection result is that the communication bus hardware interface to be driven has not been called by a core other than the current core among multiple cores, the driver coding information can be used to drive the communication bus hardware interface to perform the communication task through the communication bus, so that the core communicates with the external device. The communication bus hardware interface can be serial peripheral interface hardware (SPIhw).

[0073] Alternatively, in a multi-core MCU system, effectively managing and controlling the communication bus hardware interface is crucial for achieving stable and efficient communication between the cores and external devices. This embodiment focuses on how to detect the call status of the communication bus hardware interface to determine whether to use driver encoding information to drive the hardware interface, thereby achieving communication between a specific core and an external device.

[0074] Optionally, in a multi-core MCU architecture, each core can include at least one communication bus hardware interface, such as an SPI hardware interface (SPIhw), for data transmission with external devices via the communication bus. This design allows multiple cores to communicate with multiple devices simultaneously, improving the system's parallel processing capabilities and resource utilization efficiency.

[0075] Optionally, before using the driver encoding information to drive the communication bus to perform a communication task, the system first needs to detect the communication bus hardware interface to be driven to obtain a first detection result. This detection process mainly checks whether the hardware interface is currently being called by other cores, that is, verifies the exclusive status of the hardware interface. The first detection result is that the hardware interface is not being called by any core other than the current core.

[0076] Alternatively, if the first detection result indicates that the SPI hardware interface to be driven is not currently used by another core, this means that the current core can safely access and control the hardware interface to achieve communication with the external device. In this case, the system can use the pre-prepared driver encoding information, i.e., the SPI driver code, to drive the communication bus hardware interface.

[0077] Optionally, the current core loads the SPI driver code into its execution environment, preparing to call the hardware interface. Based on communication requirements, it sets the SPI hardware interface's configuration parameters, such as clock speed, data width, and mode. It then performs necessary initialization operations, such as setting registers, to ensure the hardware interface is in the correct initial state. Data transfer tasks are executed by calling functions in the SPI driver code, such as the SPI data write and read functions. After the task completes, the system verifies that the data transfer was successful and that the hardware interface was correctly released, preparing for the next call.

[0078] Optionally, the existence of the first detection result ensures exclusive access to the communication bus hardware interface and avoids resource conflicts. This is because in a multi-core environment, multiple cores may attempt to access the same hardware interface at the same time, resulting in data confusion and hardware failure. By detecting and confirming that the current core is the only user of the SPI hardware interface to be driven, the system can maintain the correctness and reliability of the communication task. After the first detection result is confirmed, the process of using the SPI driver encoding information to drive the hardware interface is actually the implementation method of the core and the external device communicating through the communication bus. This process not only reflects the efficient use of hardware resources, but also demonstrates the mechanism of close collaboration between the software driver and the hardware interface, ensuring smooth communication and accurate data transmission.

[0079] In this embodiment of the present invention, by detecting the call status of the communication bus hardware interface, combined with core-level permission management and the use of driver encoding information, an effective communication bus control and usage mechanism is provided in a multi-core environment. This not only enhances the system's resource management capabilities, but also ensures the stability and efficiency of communication between the core and external devices.

[0080] As an optional embodiment, the method also includes at least one of the following: in response to a macro definition instruction, based on the permission information, adding first macro definition information and second macro definition information in the driver coding information, wherein the first macro definition information is used to indicate that the core has the calling permission, and the second macro definition information is used to indicate that the core does not have the calling permission; in response to a constant setting instruction, based on the permission information, adding first constant information and second constant information in the driver coding information, wherein the first constant information is used to indicate that the core has the calling permission, and the second constant information is used to indicate that the core does not have the calling permission.

[0081] In this embodiment, in the design of a multi-core MCU system, managing the permissions for cores to call the communication bus is a critical step in ensuring system stability and security. This embodiment provides clear identification of whether a core has call permission by using macro definitions and constant settings. Both methods embed permission checks into the driver code.

[0082] Optionally, in the scenario where the core has call permission, a first macro definition information can be added to the driver coding information as a sign that the core is authorized to call the communication bus. For example, SPI_ACCESS_PERMITTED can be defined, and a check can be made to see if this macro is defined before calling the SPI communication function. Conversely, when the core is not authorized to call the communication bus, a second macro definition information, such as SPI_ACCESS_DENIED, can be added to explicitly indicate that the core does not have call permission. In the driver code, conditional compilation can be used or ignored for certain code blocks, depending on whether a specific macro definition exists.

[0083] Alternatively, macro definition checking is typically done during compilation, implemented by a preprocessor. This prevents unauthorized cores from accessing the SPI bus at compile time, thereby reducing runtime error checking overhead and enhancing system robustness and security.

[0084] Alternatively, another way to implement core call permissions is through constant settings. In the driver code, two constants can be predefined, such as ACCESS_GRANTED and ACCESS_DENIED, to indicate whether the core has permission to call the communication bus. Unlike macro definitions, constant settings tend to check permission status at runtime rather than at compile time.

[0085] Optionally, before calling the SPI communication function, a global or local variable (usually a constant) containing permission information is checked. This approach provides greater flexibility at runtime, allowing the core's permissions to be dynamically adjusted during software execution, but it may also incur additional runtime overhead, especially when permission checking becomes a performance bottleneck.

[0086] Alternatively, macro definitions are more suitable for determining permissions at compile time, providing early error detection and compile-time optimization, and are suitable for scenarios where permissions are fixed. Constant settings provide a way to check permissions at runtime, which is more suitable for scenarios where permissions may change dynamically, but may affect program execution efficiency.

[0087] It's important to note that in practice, the choice between macro definitions and constant settings depends on permission management requirements and system resource constraints. If permission assignments rarely change throughout the software lifecycle, macro definitions can simplify code and improve execution efficiency. On the other hand, if permissions may need to be adjusted at runtime, or to maintain code dynamics and flexibility, constant settings are more appropriate.

[0088] In an embodiment of the present invention, whether through macro definition or constant setting, the above steps provide a clear identification and control mechanism for the permission management of core calls to the communication bus in a multi-core system, which helps to avoid resource conflicts and ensure the orderly execution of communication tasks.

[0089] As an optional embodiment, the driver coding information includes a communication function, and different communication functions perform different communication tasks. The method also includes: in the process of using the driver coding information to drive the communication bus to perform the communication task, detecting the core that calls the communication function to obtain a second detection result; in response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, determining a second verification result.

[0090] In this embodiment, the driving code information may include a communication function, and the communication function may be an SPI transmission function.

[0091] Alternatively, in a multi-core MCU system, to improve resource utilization and efficiency, it is often necessary to distribute communication tasks among different cores. However, this distribution can lead to resource conflicts and data inconsistencies, particularly when a shared resource, such as a communication bus like the SPI, is called by multiple cores. The following is a detailed analysis of the steps in the above embodiment, which aim to ensure that the caller of the communication function is consistent with the initiator of the communication task through a detection and verification mechanism, thereby avoiding resource contention and data confusion among multiple cores.

[0092] Alternatively, in a multi-core environment, the driver code may include a series of communication functions responsible for communicating with the hardware, such as SPI transfer functions, which control data exchange between the SPI bus and peripherals. These communication functions perform specific communication tasks based on different communication requirements, such as data reading, data writing, or full-duplex data transmission.

[0093] Optionally, during the execution of a communication task, the core that calls the communication function can be tested to obtain a second test result. This test primarily confirms whether the core currently calling the SPI transfer function matches the core that originally initiated the communication task. The test process may include reading the core's identification, core status, or core configuration information and comparing it with the information of the core that initiated the communication task.

[0094] Optionally, call detection is typically implemented by the communication bus driver software and may involve the following steps: When a communication task is first initiated, the ID of the core initiating the communication task is recorded. When executing the SPI transfer function, the ID of the current core is obtained and compared with the recorded ID of the initiating core. If the ID of the current core does not match the ID of the initiating core, it indicates that an unauthorized core has attempted to call the communication function, and a second detection result is generated.

[0095] Optionally, if the second detection result indicates that the core calling the communication function is different from the core initiating the communication task, a second verification result can be determined, prohibiting the current core from continuing to call the communication bus to execute the communication task. The generation of this verification result is essentially a system permission management measure for multi-core resource call access, intended to prevent resource conflicts and data contention between different cores, and to ensure the accuracy and data integrity of the communication process.

[0096] Optionally, once the second verification result is confirmed, the following actions can be taken: Reassign the communication task to the original initiating core or a core with permission to ensure that the task is executed on the correct core. Logging an error or notifying the developer indicates which core attempted the unauthorized communication function call. In some cases, restoring the SPI bus state to the state before the call can prevent the unauthorized core's erroneous operation from affecting subsequent communication tasks.

[0097] In an embodiment of the present invention, by embedding a core detection and permission verification mechanism in the driver coding information, security and consistency are guaranteed for communication tasks in a multi-core MCU system. This not only helps prevent resource conflicts but also ensures the accuracy and reliability of data transmission, which is of great significance for maintaining communication stability and improving overall performance in a multi-core system. By generating and processing the second detection result and the second verification result, the core call behavior can be monitored and adjusted in real time to ensure efficient utilization of the communication bus and smooth system operation.

[0098] As an optional embodiment, the method includes at least one of the following: in response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, generating a prompt message based on the identification information of the communication function, and storing the prompt information in the storage medium of the microcontroller unit, wherein the prompt information is used to prompt that the communication function executes the communication task incorrectly; in response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, sending identification information to the core that initiates the communication task; in response to the core that initiates the communication task receiving the identification information and the communication bus being in an idle state, calling the communication function corresponding to the identification information to execute the communication task.

[0099] In this embodiment, in the design of a multi-core MCU, it is critical to ensure that each core correctly calls the communication bus to execute the assigned communication task. This embodiment effectively solves the problem of inconsistent inter-core communication function calls by introducing the second detection result and a series of response strategies.

[0100] Optionally, when the second detection result shows that the core that calls the communication function is different from the core that initiates the communication task, the system needs to take measures to avoid potential data competition and resource conflicts. The response mechanism here includes at least the following two: generating and storing prompt information, generating a prompt information based on the identification information of the communication function, clearly indicating the occurrence of an error, that is, a communication function is called incorrectly. This prompt information will then be stored in the storage medium of the MCU, such as a non-volatile memory, so as to provide a reference in subsequent system debugging or troubleshooting. Sending identification information to the correct core, that is, another processing method is to send the identification information of the communication function called by the erroneous core back to the core that initiated the communication task. The above mechanism is intended to make the initiating core aware of the fact that the function is called by the erroneous core, and also provides an opportunity for the correct execution of the task.

[0101] Optionally, the generation and storage of prompt information is crucial for system maintenance and troubleshooting: prompt information includes the identifier of the communication function, helping developers quickly locate the function and calling core where the error occurred, accelerating problem identification and resolution. By recording these errors, the system can accumulate statistical data on resource management, thereby optimizing scheduling algorithms and improving stability and reliability in multi-core environments.

[0102] Optionally, when the identification information is returned to the correct core, that core can re-execute the communication task at an appropriate time. The core receiving the identification information first confirms that the communication bus is idle—that is, no other core is currently using the bus. Based on the identification information, the core then calls the corresponding communication function and re-executes the previous communication task, ensuring that the task is completed on the correct core and under the correct conditions.

[0103] Optionally, when the current core calls a communication function, the system performs a second check to verify whether the calling core is the same core that initiated the communication task. If the check indicates an error in the calling core, the system generates a prompt or directly sends identification information back to the initiating core. If a prompt is generated, the system stores it in a storage medium. After receiving the identification information, the initiating core checks the communication bus status. If it confirms it is idle, it re-calls the communication function corresponding to the identification information to execute the task.

[0104] In an embodiment of the present invention, by introducing a second detection result and its corresponding response mechanism during the execution of inter-core communication tasks, common resource conflicts and data contention issues in multi-core systems are effectively prevented. Whether through the generation and storage of prompt information or the transmission of identification information between cores, the goal is to ensure that communication tasks are executed on the correct cores and under the correct conditions, thereby improving the stability and reliability of the entire system. This design approach is not only applicable to the SPI bus but can also be extended to the management of other shared communication resources, providing strong support for building more efficient and smoothly operating multi-core microcontroller systems.

[0105] As an optional embodiment, before responding to the core sending a communication task to the communication bus and obtaining permission information of the communication bus, the method also includes: obtaining a target number of cores in the microcontroller unit; based on the target number, determining the array length of the status array, wherein the status array includes multiple status information, and the array length is used to represent the number of status information in the status array.

[0106] In this embodiment, in a multi-core MCU system, communication bus permission management and status monitoring are key to ensuring stable system operation. This embodiment provides a structured state tracking mechanism for interactions between cores and the communication bus by obtaining a target number of cores and determining the length of the state array based on this number. This mechanism helps avoid resource conflicts in a multi-core environment and ensures that each core has orderly access to the shared communication bus.

[0107] Optionally, the target number of cores in the MCU can be obtained during initialization or during dynamic resource allocation. This can be accomplished by querying the system configuration, hardware description files, or runtime detection mechanisms. Knowing the number of cores is crucial for subsequent state management, as the length of the state array directly depends on the target number of cores.

[0108] Optionally, the length of the status array is determined based on the target number of cores. The status array is a data structure used to store communication bus status information corresponding to each core, such as usage status, permission status, and task queue status. The array length determines how much status information the array can store. Each core corresponds to an element in the array, which records the status of the core's interaction with the communication bus.

[0109] Optionally, the state array serves as a key data structure. Each core's status information is stored in a separate element of the state array. This allows the system to monitor each core's communication bus usage in real time, ensuring correct resource allocation and efficient scheduling. The state array can be used to check communication bus usage permissions, ensuring that only one core has exclusive access to the bus at any given time, thereby avoiding data contention and resource conflicts among multiple cores. The state array provides the foundation for multi-core resource management, enabling the system to dynamically adjust communication bus allocation strategies based on core status information, achieving load balancing and optimizing resource utilization.

[0110] Optionally, the target number of cores is obtained, and the length of the status array is determined based on this number. For example, if the system detects three cores, the length of the status array will also be set to 3, with one element allocated to each core. During access control and usage of the communication bus, the system will record the status information of each core's interaction with the communication bus in the status array. This may include the communication bus usage status, call permissions, task queue length, etc. When a core attempts to send a communication task to the communication bus, before checking the permission information, the location corresponding to the core is read from the status array to obtain its current communication bus usage status and permission status. Based on the status information recorded in the status array, the system can decide whether to allow the core to call the communication bus to perform the task, as well as how to schedule resources and allocate tasks among multiple cores to ensure smooth communication and overall system performance.

[0111] In this embodiment of the present invention, by obtaining the target number of cores and determining the array length of the state array, a refined state management solution for core-communication bus interactions is provided for multi-core MCU systems. Through structured data organization and real-time state tracking, this approach ensures the rational allocation and efficient utilization of communication bus resources, while mitigating the risk of data contention in multi-core environments. This approach lays a solid foundation for building stable, reliable, and high-performance multi-core microcontroller systems.

[0112] The technical solutions of the embodiments of the present invention are described below with reference to preferred implementation methods.

[0113] Currently, automotive MCU development is accelerating towards multi-core heterogeneous architectures, high real-time performance, and enhanced functional safety. With the surge in computing power demand in scenarios like intelligent driving and smart cockpits, MCU core counts are expanding from single-core to multi-core to support parallel processing of multi-domain tasks.

[0114] The SPI driver in the related art has a significant bottleneck in multi-core deployment. Although some drivers avoid bus deadlock through spin locks or status flags, the key state machine still has data consistency issues when operating concurrently on multiple cores. For example, modifying the SPI hardware usage flags of multiple cores at the same time may lead to state misjudgment and cause logical errors. For example, both cores believe that they have completed data transmission, but in fact only one core succeeds, resulting in subsequent state misjudgment. In addition, some drivers support configuring the core where the SPI driver is located, but the static binding between the core and the peripheral lacks dynamic verification capabilities. Once the application calls SPI on the wrong core, the driver cannot actively repair the link, resulting in transmission interruption and no fault tolerance mechanism. Therefore, there is still a technical problem of poor verification effect of the communication bus in the microcontroller unit.

[0115] However, an embodiment of the present invention proposes an SPI multi-core deployment and redundancy verification method, which expands the SPI state into an array that matches the number of cores. Each core independently maintains its own state, and atomic operations are combined to eliminate the risk of multi-core competition. Dynamic mapping verification between cores and peripherals is added to the driver interface layer, and call requests from erroneous cores are recorded. Tasks are automatically migrated to the command queue of the target core, and queue execution is triggered by SPI idle interrupts, achieving transparent error recovery and improving resource utilization. This achieves the technical effect of improving the verification effect of the communication bus in the microcontroller unit, solving the technical problem of poor verification effect of the communication bus in the microcontroller unit.

[0116] The following is a further introduction to the embodiments of the present invention.

[0117] In this embodiment, the state values ​​shared by multiple drivers are set as an array, the length of the array is equal to the length of the chip core, and different cores operate different array elements.

[0118] Optionally, this embodiment describes an innovative solution for SPI deployment and redundancy verification in a multi-core MCU environment. In a multi-core MCU, multiple cores may need to access and control shared SPI peripherals simultaneously. Traditionally, SPI drivers are typically designed for a single core, without fully considering concurrent access issues in a multi-core environment. This can lead to data contention, inconsistent states, and other issues, impacting system stability and performance.

[0119] Optionally, the core of this embodiment is to expand the SPI status value into an array whose length is equal to the number of MCU cores. This means that each core has an independent status value for maintaining and tracking the status of its SPI peripheral operations. This design effectively avoids data contention issues when multiple cores are operating concurrently, because different cores operate on different array elements and no longer share the same status value.

[0120] Optionally, in the SPI driver implementation, a state machine array is introduced to ensure that each core operates on its corresponding array element. This ensures that even if multiple cores attempt to access the SPI peripheral simultaneously, the corresponding state information of the multiple cores will not interfere with each other. Atomic operations are used in state array updates to ensure the integrity and consistency of state updates. The use of atomic operations prevents interruptions by other cores during the state update process, which could lead to inconsistent states. By isolating the state array, logical isolation of SPI operations between cores is achieved. Even when SPI resources are shared at the hardware level, the independence and consistency of SPI operations between cores can be maintained at the software level.

[0121] In this embodiment of the present invention, a core-level state array is used to address data consistency issues in SPI operations in a multi-core environment, improving system reliability and stability. This allows different cores to simultaneously process their respective SPI tasks without state confusion or data contention, thereby enhancing the concurrent processing capabilities of multi-core MCUs. During multi-core SPI operations, an additional verification mechanism is provided to ensure that even if a core fails, other cores can continue SPI operations correctly, improving system redundancy and fault tolerance.

[0122] In summary, the introduction of a core-level state array effectively resolves the concurrent access issue of SPI drivers in multi-core MCUs, improving data consistency, system stability, and multi-core concurrent processing capabilities. This represents a technical solution for SPI driver design in modern multi-core MCU environments. This design can better leverage the advantages of multi-core architectures and improve overall system performance and reliability.

[0123] In this embodiment, each SPI driver code specifies in the form of a macro definition or a const which core it is designed to be called, for example, core A.

[0124] Alternatively, the prevalence of multi-core MCU architectures has brought greater computing power and resource management flexibility. However, this also presents new challenges for software design, particularly regarding access and control of shared resources, such as peripherals like the SPI (Serial Peripheral Interface). In a multi-core environment, lack of clear management and control over the use of shared resources can lead to data contention and resource conflicts, impacting system stability and performance.

[0125] Optionally, the core of this embodiment is to introduce a mechanism to explicitly specify the core on which each SPI driver code is expected to run, that is, the driver is designed to be called by a specific core. This is achieved by using macro definitions or const constants in the driver code. For example, the SPI1 driver can be marked as SPI1_CORE_A, indicating that it should run on core A.

[0126] Optionally, when writing an SPI driver, explicitly specify its target kernel through macro definitions or const constants. This can be done during the driver initialization phase or within the interface function that calls the driver. At the driver's entry point (interface function), add kernel permission verification logic. When the function is called, the logic checks whether the call request comes from the expected kernel. If not, the driver can take preventive measures, such as rejecting the request, logging an error message, or returning a call failure in other ways. If the driver is called on an unexpected kernel, it can log the error number and return a non-OK value, or suspend the task and pass it to the correct kernel for execution.

[0127] In this embodiment of the present invention, the binding relationship between each SPI driver and a specific core is clearly defined, which helps to achieve resource isolation between cores and reduce data contention and state confusion that may arise when concurrently accessing the same SPI peripheral. By preventing SPI drivers from executing on the wrong core, uncertainty and potential errors in system operation are reduced, and the stability and reliability of multi-core systems are improved. This setting allows developers to plan the driver deployment core during the compilation phase, avoiding the complex dynamic resource allocation issues at runtime and simplifying driver deployment and system maintenance in multi-core environments.

[0128] In this embodiment, verification logic is added, and the driver using the same spihw cannot be called by different cores. A chip often has multiple spihws, each of which can be connected to multiple peripherals, each with a driver.

[0129] Alternatively, in multi-core MCU systems, resource sharing across multiple cores is a common design requirement, particularly for accessing peripherals such as SPI. SPI, a synchronous serial communication protocol, is widely used for data exchange between microcontrollers and external devices. However, when multiple cores attempt to simultaneously access peripherals connected via the same SPI hardware (spihw), resource conflicts, data inconsistencies, and even system crashes can result. Therefore, ensuring the correct deployment and use of SPI drivers in multi-core systems is crucial.

[0130] Optionally, this embodiment proposes an enhanced verification logic to ensure that all drivers using the same SPI hardware (SPIhw) are not called simultaneously by different cores. The above embodiment focuses on solving the exclusivity problem of SPI resources in a multi-core environment and preventing conflicts caused by concurrent access to the same SPI hardware.

[0131] Optionally, during the initialization or runtime of the SPI driver, a check logic is introduced to check whether the current driver has been called by another kernel. The check logic can be a global counter, a status flag, or a lock assigned to a specific kernel. By setting the kernel identifier in the driver (such as the macro definition or const constant described above), the driver is bound to a specific kernel, thereby establishing a static binding relationship between the kernel and the driver to prevent incorrect calls to the driver. If it is detected that a driver is called on the wrong kernel, the driver should be able to identify this situation and take appropriate error handling measures. This may include logging an error, returning an error code, aborting the operation, or migrating the task to the correct kernel.

[0132] In this embodiment of the present invention, by forcibly binding drivers to specific cores, drivers using the same SPI hardware are prevented from being called concurrently, thereby avoiding resource and data contention issues. This eliminates instability caused by concurrent SPI accesses and improves the overall stability and reliability of multi-core systems. This setup simplifies SPI driver management in a multi-core environment, reduces reliance on dynamic resource allocation and synchronization mechanisms, and makes system design more concise and clear.

[0133] In this embodiment, all functions of the same driver that need to call SPI transmission are added with a number and a verification logic. If these functions are called in a core that is inconsistent with feature 2, such as core B, the number is recorded and a non-ok value is returned.

[0134] Alternatively, in a multi-core MCU environment, SPI drivers are typically designed to run on specific cores to avoid resource conflicts and data races. However, as system complexity increases, software components may run on different cores at different development stages or system configurations, making it more difficult to correctly deploy and use the driver.

[0135] Optionally, in this embodiment, to enhance the reliability and controllability of the SPI driver in a multi-core environment, a unique number is added to each function that calls an SPI transfer, along with core permission verification logic. This innovation ensures that driver functions can only be executed on the intended core. If called on the wrong core, the driver will log an error message and respond appropriately.

[0136] Optionally, a unique number is assigned to each function that calls SPI transfer, such as SPI_TRANSFER_FUNC_1, SPI_READ_FUNC_2, etc. The above number is used as a function identifier in the driver code for subsequent core permission verification. At the entry of the function, a verification logic is added to check whether the currently executed kernel is consistent with the kernel expected by the driver. If the current kernel is inconsistent with the expected kernel (such as core A defined in feature 2), for example, it is core B, then the driver will not execute the function. If the verification finds that the function is called by the wrong kernel, the system will record the function number (such as SPI_TRANSFER_FUNC_1) and return a non-OK value (such as ERROR_NOT_ON_EXPECTED_CORE), indicating that the caller function failed to execute on the expected kernel.

[0137] In this embodiment of the present invention, by adding function numbers and verification logic, the system can effectively identify and prevent cross-core SPI calls, enhancing the isolation and security of inter-core resources. This prevents SPI operations from being executed on the wrong core, reducing the risk of data errors, inconsistent states, or system crashes caused by illegal core access. Recording error numbers during function calls provides clues for system maintenance and troubleshooting, allowing developers to quickly locate and resolve issues.

[0138] In this embodiment, the function may directly return notOK and record the number in the non-volatile storage space to remind the developer of the call error.

[0139] Alternatively, in a multi-core MCU architecture, the correct deployment and use of SPI drivers is crucial to ensuring system stability and data consistency. Since SPI operations are often closely related to specific hardware peripherals, improper cross-core calls may lead to unpredictable behavior or system failures.

[0140] Optionally, this embodiment refines the handling method. When an SPI driver function is called by an erroneous kernel, it not only returns an error status (notOK), but also records the function call number in non-volatile storage. This innovation provides a persistent record of erroneous calls, allowing developers to trace the specific circumstances of the erroneous call after the system restarts, thereby more accurately locating and fixing the problem.

[0141] Optionally, when an SPI driver function is called by an unexpected kernel, the function will immediately return an error status (notOK), preventing further SPI operations. At the same time, the function call number will be recorded in non-volatile storage. Non-volatile storage retains data even after system power failure, so developers can retrieve information about the erroneous call by checking non-volatile storage even after the system is restarted. When debugging or maintaining the system, developers can read the error log in non-volatile storage to understand which SPI function was called incorrectly on which kernel, providing clear guidance for subsequent code review and modification.

[0142] In an embodiment of the present invention, persistent logging of error calls improves error tracking efficiency, enabling developers to quickly locate the source of errors when debugging SPI driver-related system issues in a multi-core environment. By recording error call numbers, maintenance becomes simpler, eliminating the need for developers to rebuild the calling environment after each system restart to attempt to reproduce the error. After obtaining error information, measures can be taken to prevent similar errors from recurring, such as adjusting driver deployment, modifying kernel call logic, or adding more complex verification mechanisms.

[0143] In this embodiment, the function may return pending and pass the number to the correct core recorded in feature 2. The core calls the function corresponding to the number when idle, returns the SPI transfer signal to core B, and returns OK.

[0144] Alternatively, in a multi-core MCU system, multiple cores may need to access the same SPI device. However, direct concurrent access can easily lead to resource conflicts and data inconsistency. To address these issues, a mechanism can be set up to coordinate SPI access between different cores to ensure data transmission accuracy and system stability.

[0145] Optionally, when an SPI driver function is called by an unintended kernel, the function returns a "pending" status instead of failing immediately. At the same time, the calling number of the function is passed to the intended kernel so that the intended kernel can be responsible for executing the function at the appropriate time to complete the SPI data transfer.

[0146] Optionally, when the wrong core (such as core B) attempts to call the SPI driver function, the function returns "pending", indicating that the operation cannot be executed immediately. The wrong core passes the function number to the intended core (such as core A), which can be achieved through mechanisms such as shared memory, message queues, or interrupts. When the intended core (core A) detects an idle state or responds to a specific signal, it searches for and executes the SPI operation that matches the passed function number. After completion, it returns the data and success status to the core that originally attempted to call. After core A completes the data transfer, it returns the result of the SPI transfer to core B through some communication mechanism (such as shared memory, message passing). Core B knows that the SPI function was successfully executed on the correct core based on the returned status (OK).

[0147] In this embodiment of the present invention, by allowing erroneous calls to resume execution on the correct core, the system can better handle illegal core accesses and improve its adaptability and resilience to external errors. Core A executes the pending SPI operation while idle, avoiding resource waste while ensuring timely and accurate data transmission. Compared to directly logging errors, returning pending and executing on the correct core reduces unnecessary inter-core communication and lowers system overhead.

[0148] In this embodiment, the number transfer can use shared memory to add the number to the execution queue of the SPI driver. When idle, it can be defined as adding an SPI queue execution function at the end of a periodic task (for example, 10ms). The period is determined according to the priority of the function. The higher the priority, the smaller the period of the function.

[0149] Alternatively, in a multi-core MCU environment, managing shared resources, such as the SPI interface, is crucial for ensuring system reliability and response time. When an incorrect core attempts to call an SPI driver, the function call number can be passed to the correct core, which then executes the SPI operation during its idle cycle. The paper further clarifies the specific implementation strategies for this process, particularly how to leverage shared memory and periodic task scheduling to improve efficiency and reliability.

[0150] Alternatively, this embodiment utilizes shared memory to pass the function call number, adding it to the correct SPI driver execution queue and executing the queued SPI operations at the end of the periodic task. This mechanism ensures the continuity of function calls and, through priority scheduling, enables more rapid execution of important SPI operations, improving overall system performance and responsiveness.

[0151] Alternatively, in a multi-core environment, shared memory is an effective inter-process communication method. When an erroneous core (such as core B) attempts to call an SPI function, it writes the function call number (for example, FUNC_001) to a memory area shared with the correct core (such as core A). This area can be used to queue pending SPI operations. The correct core (core A) maintains an SPI driver execution queue and adds each new function call number to the queue. This queue can be sorted on a first-come, first-served basis or dynamically adjusted based on function priority. Core A defines a periodic task that executes every 10 milliseconds, for example. At the end of the task, the system checks the SPI queue for pending functions. If so, the queued SPI operations are executed according to their order or priority. The execution frequency of the periodic task can be dynamically adjusted based on the function priority. Higher-priority functions have shorter execution periods, enabling faster response times. The function priority is inversely proportional to the execution period of the periodic task. That is, higher-priority functions have shorter execution intervals for their corresponding periodic tasks, helping to ensure the timely completion of critical operations.

[0152] In this embodiment of the present invention, priority scheduling enables critical SPI operations to be executed in a shorter time, reducing system latency. Incorrect kernel calls do not cause operation failures; instead, they are completed on the correct kernel through a queue scheduling mechanism, enhancing the reliability and fault tolerance of the SPI driver in a multi-core environment. The combination of shared memory and periodic task scheduling helps to rationally allocate system resources, avoid unnecessary kernel and context switches, and reduce system overhead.

[0153] In this embodiment, a judgment logic needs to be added to determine whether the SPI queue execution function is executed. If the driver is executing a series of command sets that should not be inserted with other commands, the additional commands in the SPI queue should not be executed.

[0154] Alternatively, in a multi-core MCU architecture, multiple cores may need to collaboratively access shared SPI resources to perform data transfers or other operations. Solution 8, which uses shared memory to maintain an SPI function call queue and executes functions in the queue based on periodic task scheduling, provides a framework for managing SPI resources in a multi-core environment. However, in some cases, the SPI driver may need to execute a set of commands continuously to maintain data transfer integrity or meet specific protocol requirements.

[0155] Optionally, before executing a function in the SPI queue, a check logic is added to check whether the current SPI driver is in a command set that does not allow interruptions. This innovation is intended to prevent additional commands in the queue from being accidentally inserted into the ongoing command sequence, thereby disrupting the continuity and consistency of data transmission.

[0156] Optionally, before the SPI queue execution function starts executing, check whether the SPI driver is processing a critical command set. Critical command sets are tasks that need to be executed continuously and without interference, such as a series of initialization and configuration commands during SPI data transmission. If the SPI driver is executing a critical command set, the queue execution function will suspend the execution of newly added functions until the entire command set is completed. This mechanism can be implemented by maintaining a command set execution flag (such as COMMAND_SET_IN_PROGRESS), which is set when the critical command set starts and cleared when it is completed. If the function in the queue cannot be executed immediately, it can be temporarily retained in the queue until the critical command set is executed. The queue management algorithm must ensure that even if there are multiple pauses, the functions can be executed in the original order to maintain the fairness of the queue and the order of data transmission.

[0157] In embodiments of the present invention, by preventing queued functions from being inserted during the execution of critical command sets, the above method ensures data transmission continuity and correct protocol compliance, avoiding data errors or protocol violations. This also avoids resource contention during sensitive operations, reduces the likelihood of system failures, and thus improves overall system stability. By properly scheduling function execution, unnecessary kernel context switches and resource preemption are avoided, improving the efficiency of resource management in multi-core systems.

[0158] According to an embodiment of the present invention, a communication bus verification device in a micro control unit is also provided. It should be noted that the communication bus verification device in a micro control unit can be used to execute the communication bus verification method in the micro control unit in the above embodiment.

[0159] Figure 2 FIG. 1 is a schematic diagram of a communication bus verification device in a micro control unit according to an embodiment of the present invention. Figure 2 As shown, the communication bus verification device 200 in the micro control unit may include: an acquisition unit 202 , a first verification unit 204 and a second verification unit 206 .

[0160] The acquiring unit 202 is configured to acquire permission information of the communication bus in response to the core sending a communication task to the communication bus.

[0161] The first verification unit 204 is used to obtain multiple status information of the communication bus in response to the permission information that the core has the calling permission, and in response to the status information corresponding to the core that the communication bus is in an idle state for the core, verify the communication bus to obtain a first verification result.

[0162] The second verification unit 206 is used to obtain multiple status information of the communication bus in response to the permission information indicating that the core does not have the calling permission, or in response to the permission information indicating that the core has the calling permission, and in response to the status information indicating that the communication bus is in an occupied state for the core, verify the communication bus to obtain a second verification result.

[0163] In an embodiment of the present invention, the acquisition unit 202 acquires permission information of the communication bus in response to the core sending a communication task to the communication bus. The first verification unit 204 acquires various status information of the communication bus in response to the permission information indicating that the core has the call permission, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state relative to the core, the communication bus is verified to obtain a first verification result. The second verification unit 206 acquires various status information of the communication bus in response to the permission information indicating that the core does not have the call permission, or in response to the permission information indicating that the core has the call permission, and in response to the status information indicating that the communication bus is in an occupied state relative to the core, the communication bus is verified to obtain a second verification result, thereby solving the technical problem of poor verification effect of the communication bus in the microcontroller unit and achieving the technical effect of improving the verification effect of the communication bus in the microcontroller unit.

[0164] According to an embodiment of the present invention, a computer-readable storage medium is further provided. The storage medium includes a stored program, wherein the program executes the above method in the embodiment of the present invention.

[0165] According to an embodiment of the present invention, a processor is further provided. The processor is configured to run a program, wherein the program executes the above method in the embodiment of the present invention when running.

[0166] According to an embodiment of the present invention, a vehicle is further provided, which is used to execute the above method in the embodiment of the present invention.

[0167] According to another aspect of an embodiment of the present invention, an electronic device is provided, which includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the above method of the embodiment of the present invention.

[0168] According to another aspect of an embodiment of the present invention, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, it implements the above method of the embodiment of the present invention.

[0169] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0170] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0171] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0172] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0173] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM), random access memory (RAM), mobile hard disk, magnetic disk or optical disk, etc., various media that can store program code.

[0174] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for verifying a communication bus in a microcontroller unit, characterized in that: The microcontroller unit includes multiple cores and a communication bus, wherein different cores are used to run different functional domains, and the cores are used to communicate through the communication bus. The method includes: In response to the core sending a communication task to the communication bus, obtaining permission information of the communication bus, wherein the permission information is used to indicate whether the core has a calling permission to the communication bus; In response to the permission information indicating that the core has the calling permission, obtaining multiple status information of the communication bus, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, verifying the communication bus to obtain a first verification result, wherein the multiple status information corresponds one-to-one to the multiple cores, and the first verification result is used to indicate that the core is allowed to call the communication bus to perform the communication task; In response to the permission information indicating that the core does not have the calling permission, or in response to the permission information indicating that the core has the calling permission, multiple status information of the communication bus is obtained, and in response to the status information indicating that the communication bus is in the occupied state for the core, the communication bus is verified to obtain a second verification result, wherein the second verification result is used to indicate that the core is prohibited from calling the communication bus to perform the communication task.

2. The method according to claim 1, characterized in that In response to the permission information indicating that the core has the call permission, obtaining multiple status information of the communication bus, and in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, verifying the communication bus to obtain a first verification result, including: In response to the permission information indicating that the core has the calling permission, and in response to the state information corresponding to the core indicating that the communication bus is in the idle state, acquiring driver code information of the communication bus; Using the driving coding information, driving the communication bus to perform the communication task; In response to driving the communication bus to execute and complete the communication task, the first verification result is determined.

3. The method according to claim 2, characterized in that The core is used to communicate with an external device via the communication bus. The core includes at least one communication bus hardware interface. The communication bus hardware interface is used to connect to at least one of the external devices via the communication bus. The driver coding information is used to drive the communication bus to perform the communication task, including: Detecting the communication bus hardware interface to be driven to obtain a first detection result; In response to the first detection result that the communication bus hardware interface to be driven has not been called by a core other than the current core among the multiple cores, the communication bus hardware interface is driven using the driver coding information, and the communication task is performed through the communication bus to enable the core to communicate with the external device.

4. The method according to claim 3, characterized in that The method includes at least one of the following: In response to the macro definition instruction, based on the permission information, add first macro definition information and second macro definition information to the driver coding information, wherein the first macro definition information is used to indicate that the core has the calling permission, and the second macro definition information is used to indicate that the core does not have the calling permission; In response to a constant setting instruction, based on the permission information, first constant information and second constant information are added to the driver coding information, wherein the first constant information is used to indicate that the core has the calling permission, and the second constant information is used to indicate that the core does not have the calling permission.

5. The method according to claim 4, characterized in that The driving code information includes a communication function, and different communication functions perform different communication tasks. The method further includes: In the process of driving the communication bus to perform the communication task using the driving coding information, detecting the core that calls the communication function to obtain a second detection result; In response to the second detection result being that the core that calls the communication function is different from the core that initiates the communication task, the second verification result is determined.

6. The method according to claim 5, characterized in that The method includes at least one of the following: In response to the second detection result being that the core that calls the communication function is different from the core that initiates the communication task, generating prompt information based on the identification information of the communication function, and storing the prompt information in a storage medium of the microcontroller unit, wherein the prompt information is used to prompt that the communication function has an error in executing the communication task; In response to the second detection result that the core that calls the communication function is different from the core that initiates the communication task, the identification information is sent to the core that initiates the communication task; in response to the core that initiates the communication task receiving the identification information and the communication bus is in the idle state, the communication function corresponding to the identification information is called to execute the communication task.

7. The method according to claim 1, characterized in that Before acquiring permission information of the communication bus in response to the core sending the communication task to the communication bus, the method further includes: obtaining a target number of cores in the microcontroller unit; Based on the target quantity, an array length of a state array is determined, wherein the state array includes a plurality of the state information, and the array length is used to represent the quantity of the state information in the state array.

8. A communication bus verification device, characterized in that: The microcontroller unit includes multiple cores and a communication bus, wherein different cores are used to run different functional domains, and the multiple cores are used to communicate through the communication bus. The device includes: an acquiring unit, configured to acquire permission information of the communication bus in response to the core sending a communication task to the communication bus, wherein the permission information is used to indicate whether the core has a calling permission to the communication bus; a first verification unit configured to, in response to the permission information indicating that the core has the calling permission, obtain multiple pieces of status information of the communication bus, and, in response to the status information corresponding to the core indicating that the communication bus is in an idle state for the core, verify the communication bus to obtain a first verification result, wherein the multiple pieces of status information correspond one-to-one to the multiple cores, and the first verification result indicates that the core is allowed to call the communication bus to perform the communication task; A second verification unit is configured to obtain a plurality of status information of the communication bus in response to the permission information indicating that the core does not have the calling permission, or in response to the permission information indicating that the core has the calling permission, and to verify the communication bus in response to the status information indicating that the communication bus is in the occupied state for the core, to obtain a second verification result, wherein the second verification result is used to indicate that the core is prohibited from calling the communication bus to perform the communication task.

9. A processor, characterized in that: The processor is configured to run a program, wherein the program executes the method according to any one of claims 1 to 7 when running.

10. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method according to any one of claims 1 to 7.

12. A vehicle, characterized in that: Used to perform the method according to any one of claims 1 to 7.

Images