CN115904793B - Memory transfer method, system and chip based on multi-core heterogeneous system - Google Patents
Memory transfer method, system and chip based on multi-core heterogeneous system Download PDFInfo
- Publication number
- CN115904793B CN115904793B CN202310190933.0A CN202310190933A CN115904793B CN 115904793 B CN115904793 B CN 115904793B CN 202310190933 A CN202310190933 A CN 202310190933A CN 115904793 B CN115904793 B CN 115904793B
- Authority
- CN
- China
- Prior art keywords
- application processor
- processor
- abnormal
- identification bit
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012546 transfer Methods 0.000 title claims abstract description 56
- 238000000034 method Methods 0.000 title claims abstract description 47
- 230000002159 abnormal effect Effects 0.000 claims abstract description 75
- 230000004044 response Effects 0.000 claims abstract description 16
- 230000005856 abnormality Effects 0.000 claims abstract description 9
- 238000013507 mapping Methods 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 230000036316 preload Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Debugging And Monitoring (AREA)
Abstract
Memory transfer method, system and chip based on multi-core heterogeneous system, which is applied to multi-core chip comprising security processor and application processor, the method comprises: when the watchdog of the application processor triggers an abnormal signal, the abnormal signal is sent to the safety processor; the secure processor controls the application processor to restart based on the exception signal; detecting a restarting reason and a crash dump identification bit after the application processor is restarted; in response to the restart cause being an abnormal restart and the crash dump flag being enabled, the application processor stores the running environment of the application processor in which the abnormality occurred to the memory and clears the crash dump flag. The memory transfer method based on the multi-core heterogeneous system can ensure that the running environment transfer of the abnormal application processor is not only suitable for application scenes which can respond to interruption, but also suitable for application scenes which respond to interruption failure, thereby effectively improving the reliability and universality of the memory transfer.
Description
Technical Field
The present disclosure relates to the field of data processing technologies, and in particular, to a memory transfer method based on a multi-core heterogeneous system, and a chip.
Background
In a complex SOC (System On Chip), there are multiple heterogeneous or homogenous processing cores to meet the needs of various complex scenarios. However, the complex system has software debugging difficulty, and when a certain processing core in the SOC is abnormal, debugging interfaces such as JTAG (Joint Test Action Group, joint test working group) and the like are often lacking in a product scheme for a debugger to use, so that the running environment of the abnormal processing core needs to be saved for offline analysis, thereby facilitating relevant engineers to carry out problem positioning.
In the related art, the transfer function is realized by switching an abnormal OS (Operating System) of an abnormal processor. However, the exception handler is limited by the precondition that the exception handler needs to normally respond to the interrupt, that is, the transfer function of the exception handler is limited when the exception handler is in an interrupt response failure scenario.
Disclosure of Invention
In order to solve at least one problem in the prior art, an object of the present application is to provide a memory transfer method, system and chip based on a multi-core heterogeneous system, which can ensure that the transfer of the operating environment of an abnormal application processor is not only applicable to an application scenario capable of responding to an interrupt, but also applicable to an application scenario capable of responding to an interrupt failure, thereby effectively improving the reliability and universality of memory transfer.
In order to achieve the above object, the memory transfer method based on a multi-core heterogeneous system provided in the present application is applied to a multi-core chip including a secure processor and an application processor, and the method includes:
when the watchdog of the application processor triggers an abnormal signal, the abnormal signal is sent to the safety processor;
the secure processor controls the application processor to restart based on the exception signal;
detecting a restarting reason and a crash transfer identification bit after the application processor is restarted;
and in response to the restart reason being abnormal restart and the crash dump identification bit being enabled, the application processor stores the running environment of the application processor with the abnormality into a memory, and clears the crash dump identification bit.
Further, before the step of restarting the application processor, the method further includes:
and the safety processor sets default starting reasons of the application processors and starts watchdog of each application processor so as to monitor abnormal operation conditions of each application processor.
Still further, after the step of launching the application processor watchdog, further comprising:
the application processor watchdog starts timing;
in response to the timing exceeding a preset threshold, the application processor watchdog triggers the exception signal and sends to the secure processor.
Still further, the method further comprises:
after the safety processor receives the abnormal signal, determining whether the crash dump identification bit is enabled or not based on the abnormal signal;
in response to the crash dump flag being enabled, the secure processor loops detecting until the crash dump flag is detected to be cleared.
Still further, the method further comprises:
responding to the crash transfer identification bit as non-enabling, the safety processor sets the corresponding abnormal identification bit of the application processor, sets the crash transfer identification bit as enabling, and sends a control signal to the first application processor or the second application processor to control the application processor receiving the control signal to restart;
wherein,,
the first application processor is an application processor which sends the abnormal signal to the safety processor;
the second application processor is an application processor having a mapping relation with the first application processor.
Further, the method further comprises:
and after the application processor watchdog sends the abnormal signal to the safety processor, resetting and rechemating.
Further, the reasons for the abnormal restart include: application processor watchdog timeout and automatic restart.
Further, the running environment comprises memory information of the running module of the application processor with the exception.
To achieve the above object, the present application further provides a multi-core heterogeneous system, including:
at least one application processor for sending an exception signal to a secure processor when its watchdog triggers the exception signal;
a secure processor controlling the application processor to restart based on the exception signal;
the application processor is also used for detecting a restarting reason and a crash transfer identification bit after restarting; and in response to the restart reason being abnormal restart and the crash dump identification bit being enabled, storing the running environment of the abnormal application processor into a memory, and clearing the crash dump identification bit.
In order to achieve the above purpose, the present application further provides a chip, on which the multi-core heterogeneous system as described above is integrated.
In order to achieve the above purpose, the present application further provides a circuit board, which includes the chip as described above.
In order to achieve the above purpose, the vehicle machine is further provided, and comprises the chip.
In order to achieve the above object, the present application further provides an electronic device, including: a memory and a processor, the memory having stored therein computer instructions, the processor being configured to execute the instructions to perform the steps of a memory transfer method based on a multi-core heterogeneous system as described above.
To achieve the above object, the present application provides a computer readable storage medium having stored thereon computer instructions which when executed perform the steps of the memory transfer method based on a multi-core heterogeneous system as described above.
According to the memory transfer method, system and chip based on the multi-core heterogeneous system, when an abnormal signal is triggered through a watchdog of an application processor, the abnormal signal is sent to a safety processor, the safety processor controls the application processor to restart based on the abnormal signal, after the application processor restarts, a restarting reason and a crash transfer identification bit are detected, and when the restarting reason is abnormal and the crash transfer identification bit is enabled, the application processor stores the running environment of the application processor with the abnormality into a memory, and the crash transfer identification bit is cleared. Therefore, the running environment transfer of the abnormal application processor can be ensured to be suitable for application scenes which can respond to the interrupt, and also suitable for application scenes which can respond to the interrupt failure, so that the reliability and universality of the memory transfer are effectively improved.
Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the application.
Drawings
The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate and explain the application and do not limit it. In the drawings:
FIG. 1 is a flow chart of a memory transfer method based on a multi-core heterogeneous system according to an embodiment of the present application;
FIG. 2 is a flow chart of a memory transfer method based on a multi-core heterogeneous system according to another embodiment of the present application;
FIG. 3 is a block diagram of a multi-core heterogeneous system according to an embodiment of the present application;
FIG. 4 is a block diagram of a chip according to an embodiment of the present application;
FIG. 5 is a block diagram of a circuit board according to an embodiment of the present application;
FIG. 6 is a block diagram of a vehicle according to an embodiment of the present application;
fig. 7 is a block diagram of an electronic device according to an embodiment of the present application.
Detailed Description
Embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present application are shown in the drawings, it is to be understood that the present application may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided to provide a more thorough and complete understanding of the present application. It should be understood that the drawings and examples of the present application are for illustrative purposes only and are not intended to limit the scope of the present application.
It should be understood that the various steps recited in the method embodiments of the present application may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present application is not limited in this respect.
The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.
It should be noted that the terms "first," "second," and the like herein are merely used for distinguishing between different devices, modules, units, or data and not for limiting the order or interdependence of the functions performed by such devices, modules, units, or data.
It should be noted that references to "one" or "a plurality" in this application are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be interpreted as "one or more" unless the context clearly indicates otherwise. "plurality" is understood to mean two or more.
Hereinafter, embodiments of the present application will be described in detail with reference to the accompanying drawings.
Fig. 1 is a flowchart of a memory transfer method based on a multi-core heterogeneous system according to an embodiment of the present application. The memory transfer method based on the multi-core heterogeneous system of the present application will be described in detail below with reference to fig. 1.
In step 101, when the watchdog of the application processor triggers an exception signal, the exception signal is sent to the secure processor.
It should be noted that, the memory transfer method is applied to a multi-core chip including a secure processor and an application processor, which utilizes the advantage of multi-core heterogeneous SOC to construct a architecture in which the secure processor monitors the application processor, and the application processor may be plural.
In this embodiment, before the step of restarting the application processor, the method further includes: the security processor sets default starting reasons of the application processors and starts the watchdog of each application processor so as to monitor abnormal conditions of operation of each application processor.
Further, after the step of starting the application processor watchdog, further comprising: the application processor watchdog starts timing; in response to the timing exceeding a preset threshold, the application processor watchdog triggers an exception signal and sends to the secure processor.
In a specific example, the secure processor is booted, and may specifically run on a DDR (Double Data Rate) synchronous dynamic random access memory. The secure processor may first set the default boot reason for the application processor and boot each application processor watchdog. The application processor watchdog may monitor the running status of the units such as atf (trusted firmware under arm architecture), bootloader, kernel, etc. of the corresponding application processor. When the monitored unit of the application processor operates normally, a signal is output to the dog feeding end of the watchdog at intervals; when the monitored unit is abnormal, the dog cannot be fed within a specified time, and in this case, the watchdog triggers an abnormal signal and sends the abnormal signal to the safety processor.
Further, the method further comprises: after the application processor watchdog sends the abnormal signal to the safety processor, resetting and rescaling are carried out, so that the application processor is continuously monitored.
At step 102, the secure processor controls the application processor to restart based on the exception signal.
Specifically, after the secure processor receives the exception signal sent by the application processor watchdog, the secure processor restarts the application processor (the application processor is in a default state before restarting), so that a subsequent dump step is executed by the application processor.
It may be understood that the application processor that is restarted may be a first application processor or a second application processor, where the first application processor is an application processor that sends the above-mentioned exception signal to the secure processor, and the second application processor is an application processor that has a mapping relationship with the first application processor in the multi-core chip. The specific restarting scheme can be configured through the secure processor, namely, the secure processor determines the application processor with the corresponding transfer resource, so that the flexibility and the functionality of transfer can be improved. Especially, compared with the related technology (the function of the SOC coprocessor is limited, such as that large memory cannot be accessed, related hardware resources are lacking, and the like) for realizing the transfer by using the SOC coprocessor, the effect is remarkable.
In a specific example, when a plurality of application processors are abnormal, message forwarding can be performed through the secure processor, and the message forwarding is unified to a preloader of one application processor to perform a dump operation.
In the embodiment of the application, the method further comprises the following steps: after the safety processor receives the abnormal signal, determining whether the collapse transfer identification bit is enabled or not based on the abnormal signal; in response to the crash dump flag being enabled, the secure processor loops detecting until it is detected that the crash dump flag is cleared.
Further, the method further comprises: and responding to the fact that the collapse transfer identification bit is not enabled, setting an abnormal identification bit of the corresponding application processor by the safety processor, setting the collapse transfer identification bit to be enabled, and sending a control signal to the first application processor or the second application processor to control the application processor receiving the control signal to restart.
Specifically, the secure processor determines whether a crash dump flag (crashdump flag) is enabled according to the received exception signal, if crashdump flag is 1, that is, the application processor is in a dump state, the secure processor may perform loop detection by calling a sleep function until it is detected that crashdump flag is cleared, that is, the dump is completed. If the crashdump flag is 0, that is, the application processor is in a non-dump state, the secure processor sets the corresponding application processor exception flag to 1, sets the crashdump flag to 1, sets the exception start reason, and restarts the application processor to be executed for dump.
After the application processor is restarted, the restart cause and crash dump flag are detected, step 103.
Specifically, after the application processor is restarted, whether the restart cause is an abnormal restart may be determined by a preload unit (preloader), and whether the crash dump identifier bit is enabled may be determined, so that whether to perform a dump on the running environment of the abnormal application processor is determined according to the restart cause and the crash dump identifier bit in the next step.
It should be noted that, the restart reason may be set in advance by the application processor, and the restart reason includes a normal restart and an abnormal restart. The cause of the abnormal restart may include two types, one being software-non-processable exception, such as application processor watchdog timeout, and the other being software-processable exception, such as automatic restart (panic).
In step 104, in response to the restart cause being a special restart and the crash dump flag being enabled, the application processor stores the running environment of the application processor in which the exception occurred to memory and clears the crash dump flag.
The running environment may include memory information of a running module of the abnormal application processor. The storage can be specifically performed by means of USB (Universal Serial Bus ), SD card (Secure Digital Card, secure digital card), USB flash disk and the like.
Specifically, if the restart cause is abnormal restart and the crash dump flag is enabled, the application processor stores the running environment of the application processor with the abnormality in the memory, and clears the crash dump flag after completion. If the restart cause is abnormal restart and the crash dump flag is not enabled, or if the restart cause is not abnormal restart, the operating environment of the abnormal application processor is not dumped, and the operation is continued for the application processor.
The present application will be further explained and illustrated by a specific example.
Fig. 2 is a flowchart of a memory transfer method based on a multi-core heterogeneous system according to the embodiment, and referring to fig. 2, the memory transfer method includes the following steps:
step 201: the secure processor and the application processor are powered up.
Step 202: it is determined whether the secure processor initiates OK. If yes, go to step 203; if not, go to step 204.
Step 203: the secure processor sets a default start reason, starts each application processor watchdog, and performs steps 205 and 208.
Step 204: the secure processor is handled to initiate an exception.
Step 205: the security processor determines whether the application processor initiates OK. If yes, go to step 206; if not, step 207 is performed.
Step 206: the secure processor determines whether an exception signal sent by the application processor watchdog is monitored. If yes, go to step 212.
Step 207: the processing application processor initiates an exception.
Step 208: the application processor enters a Preloader stage, and after early initialization, whether the application processor is restarted or not is determined. If the abnormal restart is performed, determining whether a crashdump flag exists; if not, it is determined whether the application processor is preloaded with OK. If the crashdump flag exists, entering crashdump (crash dump), and then clearing the crashdump flag; if the crashdump flag does not exist, a determination is made as to whether the application processor is preloaded with OK. If the application processor preloads OK, then step 209 is performed; if the application processor preloads NG, step 210 is performed.
Step 209: the atf is started, its watchdog is reinitialized, and it is determined whether the atf is operating OK. If not, go to step 210; if yes, the bootloader is started, the watchdog is reinitialized, and whether the bootloader operates is determined to be OK or not. If not, go to step 210; if yes, starting the kernel, reinitializing the watchdog, and determining whether the kernel operates OK. If not, go to step 210; if yes, normal starting is performed.
Step 210: it is determined whether the application processor can handle the exception. If yes, go to step 211; if not, an exception signal is sent to the secure processor and step 206 is performed.
Step 211: the cause of the restart is confirmed, an exception signal is sent to the secure processor, and step 206 is performed.
Step 212: it is determined whether crashdump flag is present. If yes, go to step 213; if not, go to step 214.
Step 213: the sleep function is called and step 212 continues.
Step 214: the application processor exception flag is set and the crashdump flag is set, then step 203 is performed.
In summary, according to the memory transfer method based on the multi-core heterogeneous system in the embodiment of the application, when an abnormal signal is triggered by a watchdog of an application processor, the abnormal signal is sent to a secure processor, the application processor is controlled to restart based on the abnormal signal by the secure processor, after the application processor restarts, a restart reason and a crash transfer identification bit are detected, and when the restart reason is abnormal and the crash transfer identification bit is enabled, the application processor stores the running environment of the application processor with the abnormality into a memory, and clears the crash transfer identification bit. Therefore, the running environment transfer of the abnormal application processor can be ensured to be suitable for the application scene which can respond to the interrupt and the application scene which can respond to the interrupt failure, so that the reliability and universality of the memory transfer are effectively improved.
Fig. 3 is a block diagram of a multi-core heterogeneous system according to an embodiment of the present application. Referring to fig. 3, a multi-core heterogeneous system 30 includes: at least one application processor 31 and a security processor 32.
Wherein at least one application processor 31 is configured to send an exception signal to the security processor 32 when its watchdog triggers an exception signal. The secure processor 32 controls the restart of the application processor 31 based on the abnormality signal.
The application processor 31 is further configured to detect a restart cause and a crash dump identifier after restarting; in response to the restart cause being an abnormal restart and the crash dump flag being enabled, the running environment of the application processor 31 in which the abnormality occurred is stored to the memory, and the crash dump flag is cleared.
In this embodiment, the security processor 32 is further configured to set a default start reason for the application processor 31 and start the watchdog of each application processor before the restart step of the application processor 31, so as to monitor the abnormal situation of each application processor 31.
Further, the application processor 31 is further configured to start timing the application processor watchdog after the step of starting the application processor watchdog; in response to the timing exceeding a preset threshold, the application processor watchdog triggers an exception signal and sends to the secure processor 32.
Further, the secure processor 32 is further configured to determine, based on the exception signal, whether the crash dump flag is enabled after receiving the exception signal; in response to the crash dump flag being enabled, secure processor 32 loops detection until it is detected that the crash dump flag is cleared.
Further, the secure processor 32 also responds to the crash dump flag being disabled, sets the exception flag of the corresponding application processor 31, sets the crash dump flag to be enabled, and sends a control signal to the first application processor or the second application processor to control the application processor 31 receiving the control signal to restart.
Wherein the first application processor is an application processor 31 that sends an exception signal to a secure processor 32; the second application processor is the application processor 31 having a mapping relation with the first application processor.
In this embodiment, the application processor 31 is further configured to clear and recime after the application processor watchdog sends the exception signal to the security processor 32.
It should be noted that, the explanation of the memory transfer method based on the multi-core heterogeneous system in the above embodiment is also applicable to the multi-core heterogeneous system in the above embodiment, and will not be repeated here.
According to the multi-core heterogeneous system, when an abnormal signal is triggered by the watchdog of the application processor, the abnormal signal is sent to the safety processor, the safety processor controls the application processor to restart based on the abnormal signal, after the application processor restarts, the restart reason and the crash dump identification bit are detected, and when the restart reason is abnormal and the crash dump identification bit is enabled, the application processor stores the running environment of the application processor with the abnormality into the memory, and the crash dump identification bit is cleared. Therefore, the running environment transfer of the abnormal application processor can be ensured to be suitable for application scenes which can respond to the interrupt, and also suitable for application scenes which can respond to the interrupt failure, so that the reliability and universality of the memory transfer are effectively improved.
Fig. 4 is a block diagram of a chip according to an embodiment of the present application. Referring to fig. 4, a chip 300 is shown on which the multi-core heterogeneous system 30 of the above-described embodiment is integrated.
Fig. 5 is a block diagram of a circuit board according to an embodiment of the present application. Referring to fig. 5, a circuit board 400 includes the chip 300 of the above-described embodiment.
Fig. 6 is a block diagram of a vehicle according to an embodiment of the present application. Referring to fig. 6, a vehicle 500 includes the chip 300 of the above-described embodiment.
Fig. 7 is a block diagram of an electronic device according to an embodiment of the present application. Referring to fig. 7, an electronic device 600, a memory 601 and a processor 602, the memory 601 storing computer instructions, the processor 602 being arranged to execute the instructions to perform the steps of the memory transfer method based on a multi-core heterogeneous system as described above.
In one embodiment of the present application, there is also provided a computer readable storage medium, which may be included in the system described in the above embodiment; or may exist alone without being assembled into the system. The computer readable storage medium carries one or more computer instructions, which when executed, implement the steps of the memory transfer method based on the multi-core heterogeneous system of the above embodiment.
Embodiments of the present application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example, but not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
It should be understood that, although the steps in the flowcharts of the specification are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least a portion of the steps in the flowcharts may include a plurality of sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, the order in which the sub-steps or stages are performed is not necessarily sequential, and may be performed in turn or alternately with at least a portion of the sub-steps or stages of other steps or other steps.
It is noted that the specific values mentioned above are only for the purpose of illustrating the implementation of the present application in detail as examples and should not be construed as limiting the present application. In other examples or embodiments or examples, other values may be selected according to the present application, without specific limitation.
Those of ordinary skill in the art will appreciate that: the foregoing description is only a preferred embodiment of the present application, and is not intended to limit the present application, but although the present application has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that modifications may be made to the technical solutions described in the foregoing embodiments, or that equivalents may be substituted for part of the technical features thereof. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.
Claims (14)
1. A memory transfer method based on a multi-core heterogeneous system, which is applied to a multi-core chip comprising a security processor and an application processor, the method comprising:
when the watchdog of the application processor triggers an abnormal signal, the abnormal signal is sent to the safety processor;
the security processor judges whether a crash dump identification bit is enabled according to the received abnormal signal, if the crash dump identification bit is not enabled, the abnormal identification bit of the application processor is set, the crash dump identification bit is set to be enabled, the abnormal starting reason is set, and the application processor is restarted;
detecting a restarting reason and a crash transfer identification bit after the application processor is restarted;
and in response to the restart reason being abnormal restart and the crash dump identification bit being enabled, the application processor stores the running environment of the application processor with the abnormality into a memory, and clears the crash dump identification bit.
2. The method of claim 1, further comprising, prior to the step of restarting the application processor:
and the safety processor sets default starting reasons of the application processors and starts watchdog of each application processor so as to monitor abnormal operation conditions of each application processor.
3. The method of claim 2, further comprising, after the step of launching the application processor watchdog:
the application processor watchdog starts timing;
in response to the timing exceeding a preset threshold, the application processor watchdog triggers the exception signal and sends to the secure processor.
4. A method according to claim 3, characterized in that the method further comprises:
after the safety processor receives the abnormal signal, determining whether the crash dump identification bit is enabled or not based on the abnormal signal;
in response to the crash dump flag being enabled, the secure processor loops detecting until the crash dump flag is detected to be cleared.
5. The method according to claim 4, wherein the method further comprises:
responding to the crash transfer identification bit as non-enabling, the safety processor sets the corresponding abnormal identification bit of the application processor, sets the crash transfer identification bit as enabling, and sends a control signal to the first application processor or the second application processor to control the application processor receiving the control signal to restart;
wherein,,
the first application processor is an application processor which sends the abnormal signal to the safety processor;
the second application processor is an application processor having a mapping relation with the first application processor.
6. A method according to claim 3, characterized in that the method further comprises:
and after the application processor watchdog sends the abnormal signal to the safety processor, resetting and rechemating.
7. The method of claim 1, wherein the cause of the abnormal restart comprises: application processor watchdog timeout and automatic restart.
8. The method of claim 1, wherein the operating environment includes memory information of an operating module of the application processor in which the exception occurred.
9. A multi-core heterogeneous system, comprising:
at least one application processor for sending an exception signal to a secure processor when its watchdog triggers the exception signal;
the security processor judges whether a crash dump identification bit is enabled according to the received abnormal signal, if the crash dump identification bit is not enabled, the security processor sets the abnormal identification bit of the application processor, sets the crash dump identification bit as enabled, sets an abnormal starting reason and restarts the application processor;
the application processor is also used for detecting a restarting reason and a crash transfer identification bit after restarting; and in response to the restart reason being abnormal restart and the crash dump identification bit being enabled, storing the running environment of the abnormal application processor into a memory, and clearing the crash dump identification bit.
10. A chip having integrated thereon the multi-core heterogeneous system of claim 9.
11. A circuit board comprising the chip of claim 10.
12. A vehicle comprising the chip of claim 10.
13. An electronic device comprising a memory and a processor, wherein the memory has stored therein computer instructions, the processor being arranged to execute the instructions to perform the steps of the memory-transfer method of any of claims 1 to 8 based on a multi-core heterogeneous system.
14. A computer readable storage medium having stored thereon computer instructions which when executed perform the memory transfer method based on a multi-core heterogeneous system according to any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310190933.0A CN115904793B (en) | 2023-03-02 | 2023-03-02 | Memory transfer method, system and chip based on multi-core heterogeneous system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310190933.0A CN115904793B (en) | 2023-03-02 | 2023-03-02 | Memory transfer method, system and chip based on multi-core heterogeneous system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115904793A CN115904793A (en) | 2023-04-04 |
| CN115904793B true CN115904793B (en) | 2023-05-23 |
Family
ID=85733785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310190933.0A Active CN115904793B (en) | 2023-03-02 | 2023-03-02 | Memory transfer method, system and chip based on multi-core heterogeneous system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115904793B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117234787B (en) * | 2023-11-14 | 2024-02-23 | 苏州元脑智能科技有限公司 | Method and system for monitoring running state of system-level chip |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109032822A (en) * | 2017-06-09 | 2018-12-18 | 中兴通讯股份有限公司 | A kind of store method and device of computer crash information |
| CN112506688A (en) * | 2020-12-02 | 2021-03-16 | 北京握奇智能科技有限公司 | Hardware watchdog control system and method of OBU |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11288406A (en) * | 1998-04-02 | 1999-10-19 | Toshiba Corp | Multi-processor system with operation monitoring function |
| CN111679929A (en) * | 2020-06-03 | 2020-09-18 | 北京经纬恒润科技有限公司 | Control method applied to multi-core heterogeneous system |
| CN112463430B (en) * | 2020-12-03 | 2022-10-25 | 哲库科技(北京)有限公司 | Crash information storage method and medium for multi-core system, and electronic device |
| CN112905395B (en) * | 2021-03-12 | 2022-08-23 | 湖南长城银河科技有限公司 | Self-error-correction starting system for heterogeneous multi-core/many-core microprocessor |
| CN114756832A (en) * | 2022-04-26 | 2022-07-15 | 广州芯之联科技有限公司 | Watchdog overtime restart field capture system, method, device and storage medium |
| CN115576734B (en) * | 2022-11-18 | 2023-05-05 | 南京芯驰半导体科技有限公司 | Multi-core heterogeneous log storage method and system |
| CN115576258B (en) * | 2022-12-08 | 2023-04-04 | 小米汽车科技有限公司 | Vehicle chip system control method, system-on-chip and vehicle |
-
2023
- 2023-03-02 CN CN202310190933.0A patent/CN115904793B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109032822A (en) * | 2017-06-09 | 2018-12-18 | 中兴通讯股份有限公司 | A kind of store method and device of computer crash information |
| CN112506688A (en) * | 2020-12-02 | 2021-03-16 | 北京握奇智能科技有限公司 | Hardware watchdog control system and method of OBU |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115904793A (en) | 2023-04-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109032822B (en) | Method and device for storing crash information | |
| US8489932B2 (en) | Server system and crash dump collection method | |
| CN111273923B (en) | FPGA (field programmable Gate array) upgrading method based on PCIe (peripheral component interface express) interface | |
| JP2001101033A (en) | Fault monitoring method for operating system and application program | |
| CN114064132B (en) | Method, device, equipment and system for recovering system downtime | |
| US20220055637A1 (en) | Electronic control unit and computer readable medium | |
| CN115904793B (en) | Memory transfer method, system and chip based on multi-core heterogeneous system | |
| CN115237644B (en) | System fault processing method, central operation unit and vehicle | |
| CN110865900A (en) | Method for enhancing robustness of embedded system | |
| CN117130832A (en) | Monitoring reset method and system of multi-core heterogeneous system, chip and electronic equipment | |
| CN115292077A (en) | Kernel exception handling method and system | |
| CN107179911B (en) | Method and equipment for restarting management engine | |
| JP2003186697A (en) | System and method for testing peripheral device | |
| CN107273291B (en) | Processor debugging method and system | |
| CN115576734A (en) | Multi-core heterogeneous log storage method and system | |
| JP2007094537A (en) | Memory dump device and memory dump collection method | |
| KR101300806B1 (en) | Apparatus and method for handling abnormal processing in multi process system | |
| JP2001101034A (en) | Fault restoring method under inter-different kind of os control | |
| JP4633553B2 (en) | Debug system, debugging method and program | |
| CN116991637B (en) | Operation control method and device of embedded system, electronic equipment and storage medium | |
| CN117234787B (en) | Method and system for monitoring running state of system-level chip | |
| JP6023898B1 (en) | Information processing apparatus, information processing method, and information processing program | |
| CN114138534B (en) | Recovery and positioning method, device and equipment for system hang failure and storage medium | |
| JP2998804B2 (en) | Multi-microprocessor system | |
| CN112084049B (en) | Method for monitoring resident program of baseboard management controller |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |