(19)
(11)EP 3 531 289 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
04.11.2020 Bulletin 2020/45

(21)Application number: 19156613.2

(22)Date of filing:  12.02.2019
(51)International Patent Classification (IPC): 
G06F 11/10(2006.01)

(54)

PROCESSING SYSTEM, RELATED INTEGRATED CIRCUIT, DEVICE AND METHOD

VERARBEITUNGSSYSTEM, ZUGEHÖRIGE INTEGRIERTE SCHALTUNG, VORRICHTUNG UND VERFAHREN

SYSTÈME DE TRAITEMENT, CIRCUIT INTÉGRÉ ASSOCIÉ, DISPOSITIF ET PROCÉDÉ


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 21.02.2018 IT 201800002895

(43)Date of publication of application:
28.08.2019 Bulletin 2019/35

(73)Proprietors:
  • STMicroelectronics Application GmbH
    85609 Aschheim (DE)
  • STMicroelectronics International N.V.
    1118 BH Schiphol (NL)

(72)Inventors:
  • COLOMBO, Mr. Roberto
    D-81829 München (DE)
  • RANJAN, Mr. Om
    110043 Najafgarh, New Delhi (IN)

(74)Representative: Meindl, Tassilo 
Buzzi, Notaro & Antonielli d'Oulx S.p.A. Corso Vittorio Emanuele ll, 6
10123 Torino
10123 Torino (IT)


(56)References cited: : 
US-A1- 2009 063 865
US-B1- 7 225 373
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    Technical Field



    [0001] Embodiments of the present disclosure relate to processing systems, such as micro-controllers, having associated a memory in which configuration data are stored.

    Background



    [0002] Figure 1 shows a typical electronic system, such as the electronic system of a vehicle, comprising a plurality of processing systems 10, such as embedded systems or integrated circuits, e.g., a Field Programmable Gate Array (FPGA), Digital Signal Processor (DSP) or a micro-controller (e.g., dedicated to the automotive market).

    [0003] For example, in Figure 1 are shown three processing systems 101, 102 and 103 connected through a suitable communication system 20. For example, the communication system may include a vehicle control bus, such as a Controller Area Network (CAN) bus, and possibly a multimedia bus, such as a Media Oriented Systems Transport (MOST) bus, connected to vehicle control bus via a gateway. Typically, the processing systems 10 are located at different positions of the vehicle and may include, e.g., an Engine Control Unit (ECU), a Transmission Control Unit (TCU), an Anti-lock Braking System (ABS), a body control modules (BCM), and/or a navigation and/or multimedia audio system.

    [0004] Future generations of processing systems, in particular micro-controllers dedicated to automotive applications, will exhibit a significant increase in complexity, mainly due to the increasing number of functionalities (such as new protocols, new features, etc.) and to the tight constraints concerning the operation conditions of the system (such as lower power consumption, increased calculation power and speed, etc.).

    [0005] Figure 2 shows a block diagram of an exemplary digital processing system 10, such as a micro-controller, which may be used as any of the processing systems 10 of Figure 1.

    [0006] In the example considered, the processing system 10a comprises at least one processing unit 102, such as a microprocessor, usually the Central Processing Unit (CPU), programmed via software instructions. Usually, the software executed by the processing unit 102 is stored in a program memory 104a, such as a non-volatile memory, such as a Flash memory or EEPROM. Generally, the memory 104a may be integrated with the processing unit 102 in a single integrated circuit, or the memory 104a may be in the form of a separate integrated circuit and connected to the processing unit 102, e.g. via the traces of a printed circuit board. Thus, in general the memory 104a contains the firmware for the processing unit 102, wherein the term firmware includes both the software of a micro-processor and the programming data of a programmable logic circuit, such as a FPGA.

    [0007] In the example considered, the processing unit 102 may have associated one or more resources 106, such as:
    • one or more communication interfaces, such as Universal asynchronous receiver/transmitter (UART), Serial Peripheral Interface Bus (SPI), Inter-Integrated Circuit (I2C), Controller Area Network (CAN) bus, Ethernet, and/or debug interfaces; and/or
    • one or more analog-to-digital and/or digital-to-analog converters; and/or
    • one or more dedicated digital components, such as hardware timers and/or counters, or a cryptographic co-processor; and/or
    • one or more analog components, such as comparators, sensors, such as a temperature sensor, etc.; and/or
    • one or more mixed signal components, such as a PWM (Pulse-Width Modulation) driver.


    [0008] Accordingly, the digital processing system 10 may support different functionalities. For example, the behavior of the processing unit 102 is determined by the firmware stored in the memory 104a, e.g., the software instructions to be executed by a microprocessor 102 of a micro-controller 10. Thus, by installing a different firmware, the same hardware (micro-controller) can be used for different applications. Often, the behavior of the processing system 10 may also be varied based on configuration data CD. For example, these configuration data CD may be written into specific areas of the non-volatile program memory 104a and retrieved when the processing system 10a is powered on. Alternatively or in addition, the configuration data CD may be stored in an additional non-volatile memory 104b, such as a one-time programmable (OTP) memory, e.g. implemented with fuses. For example, the program memory 104a may be used, in case the blocks shown in Figure 2 are integrated in a common integrated circuit. Conversely, an additional non-volatile memory 104b may be used, in case the program memory 104a is an external memory, and only the other blocks are integrated in a common integrated circuit. Accordingly, generally, the configuration data CD are stored in a non-volatile memory (104a and/or 104b) of the integrated circuit comprising the blocks requiring configuration data, such as the processing unit 102 and/or one or more of the hardware resources 106.

    [0009] For example, such configuration data CD are often calibration data used to guarantee that the hardware behavior is uniform, thereby compensating possible production process tolerances. For example, this applies often to the calibration of analog components of the processing system, such as a temperature sensor, analog-to-digital converter, voltage reference, etc. For example, a voltage monitor threshold level of an analog comparator could be "trimmed" to the exact intended value by adjusting some levels with configuration/calibration data, which are written by the producer of the hardware of the processing systems, e.g. the micro-controller producer.

    [0010] Moreover, the configuration data CD may also be used to customize the behavior of the hardware, e.g., the hardware resources 106, according to different application needs. For example, once the firmware of the processing system 10 has been stored in the processing system 10, some configuration data may be written in order to deactivate the debug interface, which e.g. could be used to download the firmware of the processing system 10.

    [0011] The processing system may also be configured to permit that a first part of the configuration data CD is written by the producer of the hardware of the processing system (e.g., the producer of an integrated circuit), and a second part of the configuration data CD is written by the developer of the firmware of the processing system 10.

    [0012] Typically, the programmed configuration data CD are read during a reset phase, which usually starts as soon as the processing system 10 is powered on. Specifically, as shown in Figure 2, the processing system 10 may comprise for this purpose a configuration module 108 configured to read the configuration data CD from the non-volatile memory 104a and/or 104b, and distribute these configuration data CD within the processing system 10.

    [0013] Specifically, the present application relates to a processing system comprising a signature verification circuit according to the preamble of Claim 1, which is known, e.g. from document US 7 225 373 B1.

    Summary



    [0014] The invention is defined by the appended independent claims.

    [0015] In view of the above, it is an objective of various embodiments of the present disclosure to provide solutions for monitoring the correct operation of the blocks involved during the configuration of the processing system.

    [0016] According to one or more embodiments, one or more of the above objectives is achieved by means of a processing system having the features specifically set forth in the claims that follow. Embodiments moreover concern a related integrated circuit, device and method.

    [0017] The claims are an integral part of the technical teaching of the disclosure provided herein.

    [0018] As mentioned before, various embodiments of the present disclosure relate to a processing system. In various embodiments, the processing system comprise at least one hardware block, a non-volatile memory, a hardware configuration module and a plurality of configuration data clients.

    [0019] Specifically, in various embodiments, each configuration data client comprising a register, wherein with each configuration data client is associated a respective address, and wherein each configuration data client is configured to receive configuration data addressed to the respective address and store the configuration data received in the register. The hardware block(s) are connected to the configuration data clients and change operation as a function of the configuration data stored in the registers of the configuration data clients.

    [0020] In various embodiments, the respective configuration data are stored in the non-volatile memory. Specifically, the configuration data are stored in the form of data packets comprising an attribute field identifying the address of one of the configuration data clients and the respective configuration data. In various embodiments, the hardware configuration module is thus configured to sequentially read the data packets from the non-volatile memory and transmit the respective configuration data read from the non-volatile memory to the respective configuration data client.

    [0021] In various embodiments, the non-volatile memory has stored also signature data, wherein the hardware configuration module is configured to read also the signature data from the non-volatile memory.

    [0022] Specifically, in various embodiments, the processing system comprises moreover a signature calculation circuit configured to calculate further signature data as a function of the respective configuration data transmitted to the configuration data clients and/or stored in the registers of the configuration data clients. For example, for this purpose, once having received configuration data, each configuration data client may transmit the respective configuration data to the signature calculation circuit. Additionally or alternatively, the signature calculation circuit may monitor the data transmitted between the hardware configuration module and the configuration data clients, e.g. in case a common bus is used

    [0023] The signature data and the further signature data are provided to a signature verification circuit. Specifically, in various embodiments, the signature verification circuit compares the signature data read from the non-volatile memory with the signature data calculated by the signature calculation circuit and generates an error signal when the signature data do not correspond. For example, the signature calculation circuit may calculate the signature data with a hashing function, such as MD5 or Secure Hash Algorithm, e.g. SHA-1 or SHA-256, or calculate the signature data by encoding and/or encrypting the configuration data, e.g. by using the Advanced Encryption Standard or Data Encryption Standard, and selecting a subset of the encoded/encrypted data.

    [0024] In various embodiments, the signature data may be stored together with the configuration data in the non-volatile memory in the form of one or more data packets. More specifically, in various embodiments, the signature calculation circuit itself has associated at least one configuration data client. In this case, the signature data may thus be stored in the non-volatile memory in the form of configuration data comprising one or more data packets comprising an attribute field identifying the address of the configuration data client(s) associated with the signature calculation circuit.

    [0025] Generally, the non-volatile memory may comprise also a plurality of sets of configuration data, wherein respective signature data are stored for each set of configuration data, and wherein the signature calculation circuit is configured to calculate respective signature data for the configuration data of each set of configuration data transmitted to the configuration data clients and/or stored in the registers of the configuration data clients.

    Brief description of the figures



    [0026] Embodiments of the present disclosure will now be described with reference to the annexed drawings, which are provided purely by way of non-limiting example and in which:
    • Figure 1 shows a typical electronic system;
    • Figure 2 shows a processing system comprising a configuration module;
    • Figure 3 shows a first embodiment of a processing system comprising a non-volatile memory having stored configuration data, a configuration module and configuration data clients;
    • Figure 4 shows an embodiment of the processing system of Figure 3;
    • Figures 5a and 5b show embodiments for calculating signature data as a function of the configuration data transmitted to the configuration data clients of Figure 3;
    • Figures 6a and 6b show embodiments for reading pre-calculated signature data from the non-volatile memory of Figure 3;
    • Figure 7 shows an embodiment of a processing system configured to compare the calculated signature data of Figures 5a and 5b with the pre-calculated signature data of Figures 6a and 6b;
    • Figure 8 shows an embodiment of a configuration data client;
    • Figure 9 is a flowchart illustrating a method of operating a processing system in accordance with the present disclosure; and
    • Figure 10 shows an embodiment of a processing system which takes into account life cycle data during the signature verification.

    Detailed Description



    [0027] In the following description, numerous specific details are given to provide a thorough understanding of embodiments. The embodiments can be practiced without one or several specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

    [0028] Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

    [0029] The headings provided herein are for convenience only and do not interpret the scope or meaning of the embodiments.

    [0030] In the following Figures 3 to 10 parts, elements or components which have already been described with reference to Figures 1 and 2 are denoted by the same references previously used in such Figures; the description of such previously described elements will not be repeated in the following in order not to overburden the present detailed description.

    [0031] As described in the foregoing, the hardware of processing system 10a may be configurable by means of a set of configuration data, i.e. parameters which are (e.g. permanently) stored in the non-volatile memory.

    [0032] For example, Figure 3 shows a possible embodiment for distributing such configuration data CD in the processing system 10a as described e.g. with respect to Figure 2. Accordingly, the description of Figure 2 applies in its entirety also to the processing system 10a of Figure 3.

    [0033] In the embodiment considered, one or more configuration data CD are stored in one or more non-volatile memories 104 (i.e., memories 104a and/or 104b). In various embodiments, these configuration data CD are stored in reserved memory areas, e.g. in the form of a plurality of consecutive memory locations.

    [0034] Accordingly, in the embodiment considered, the configuration module 108 accesses the reserved memory areas containing the configuration data CD, reads the configuration data CD and transmits the configuration data CD to a respective block 110 within the processing system 10a. Generally, the block 110 may correspond to any block of the processing system 10a requiring configuration data and may correspond to the processing unit 102, a hardware resource 106, or even a memory (e.g. the memory 104a). For example, the block 110 may be a debug interface of the processing system 10a, which is enabled or disabled based on the configuration data CD. Similarly, the configuration data CD may be used to configure read and/or write protected areas of a memory.

    [0035] In the embodiment, each block 110 has associated a respective configuration data client 112. For example, in Figure 3 are shown three blocks 110a, 110b and 110c and three configuration data clients 112a, 112b and 112c. Generally, each configuration data client 112 may be associated univocally to a single hardware block 110, and provided configuration data only to the associated hardware block 110, e.g. a specific hardware resource 106, or may be associated with a plurality of hardware blocks 110, e.g. a plurality of hardware resource 106. In general, the configuration data clients 112a, 112b and 112c may also be integrated in the respective block 110a, 110b and 110c.

    [0036] Accordingly, in the embodiment considered, the configuration module 108 may determine for each target block 110 to be configured the respective configuration data (selected from the configuration data CD) and transmit the configuration data associated with the target block 110 to the configuration data client 112 associated with the target block 110. Similarly, while reading the configuration data CD from the memory 104, the configuration module 108 may determine the target block(s) for the current configuration information and send the current configuration data to the configuration data client (s) associated with the respective target block(s). Generally, any communication may be used for transmitting the configuration data to the configuration data client 112, including both serial and parallel communications. For example, the configuration module 108 and the configuration data clients 112 may be connected via a bus 114, and each configuration data clients 112 may have associated a respective target address.

    [0037] Accordingly, each configuration data client 112 is configured to receive the configuration data from the module 108, store them into the internal register, e.g. store them into one or more internal flip-flops or latches. The data stored in the register may then be used to generate one or more signals, which influence the behavior of one or more hardware blocks 110.

    [0038] Figure 4 shows in this respect a possible embodiment of the communication between the configuration module 108 and the configuration data clients 112.

    [0039] Specifically, also in this case, the processing system 10a comprises a configuration module 108 configured to read the configuration data CD from one or more non-volatile memories 104 (e.g., memories 104a and/or 104b) and a plurality of configuration data clients 112 configured to receive respective configuration data from the module 108 and distribute them among a plurality of blocks 110 (not shown) requiring configuration data. For example, as mentioned before, each configuration data client 112 may be associate univocally with a respective block 110. For example, in the embodiment considered, the processing system 10a comprises again three configuration data clients 112a, 112b and 112c.

    [0040] In the embodiment considered, the configuration module 108 comprises a data read module 1080 configured to read the configuration data CD from the memory 104 and a dispatch module 1082 configured to transmit the configuration data to the configuration data clients 112.

    [0041] Generally, any communication may be used for communication between the dispatch module 1082 and the configuration data clients 112.

    [0042] For example, in various embodiments, the communication between the dispatch module 1082 and the configuration data clients 112 is based on data frames in accordance with a given format, called in the following Device Configuration Format (DCF). For example, in various embodiments, each data frame comprises two fields: the payload (i.e., the real data), called DCF Format payload, and possible additional data attributes used to identify the receiver of the data, called DCF Format attributes, wherein the receiver is one of the configuration data clients 112 representing a DCF client. For example, the data attributes may consist in 16 or 32 bits, wherein a given number of bits specifies the address of one of the configuration data clients 112, and the payload may consist in 16 or 32 bits. For example, in various embodiments, the data read module 1080 is configured to read blocks of 64 bits from the memory 104, wherein the first 32 bits contain the data attributes (including the address of a configuration data client) and the second 32 bits contain the configuration data to be transmitted to the address specified in the data attributes.

    [0043] In the embodiment considered, each configuration data client/DCF client 112 is a hardware module, usually comprising a combinational circuit configured to store the received data in an internal register implemented, e.g., with flip-flops/latches, thereby permitting to distribute, via one or more internal signals generated as a function of the data stored in the internal register, the configuration data received to various parts of the associate hardware block(s) 110. For example, as mentioned before, each configuration data client 112 may have associated a univocal address (i.e., univocal within each processing system 10a) and analyses the data transmitted by the dispatch module 1082 in order to determine whether the additional data attributes (DCF Format attributes) contain the address associated with the configuration data client 112.

    [0044] For example, as mentioned before, the configuration data CD may also comprise security configuration data used to activate or deactivate given security functions of the processing system 10a, such as:
    • the external access to a debug interface;
    • the (read and/or write) access to given memory locations, etc.


    [0045] In this case, a first configuration data client 112 may store configuration data CD, which signal to a memory of the processing system 10a, such as the memory 104, whether to enable or disable a write and/or read protection associated with one or more memory blocks of the memory. Similarly, a second configuration data client 112 may store configuration data used to generate a signal controlling the access to a debug interface. Specifically, the associated blocks 110 do not use directly the configuration data CD stored in the non-volatile memory 104 but the configuration data stored in the respective configuration data client 112.

    [0046] In various embodiments, the module 108 may also comprises a state control module 1084 configured to manage the various configuration phases of the processing system 10a. For example, in various embodiments, once the processing system 10a is switched-on, a reset module 116 of the processing system 10a may generate a reset signal RESET, which is used to perform a reset of the various components of the processing system 10a. For example, the reset signal RESET may correspond to a reset pulse of a given number of clock cycles, provided to the blocks 110 of the processing system 10a. For example, in the embodiment considered, the reset signal RESET may be used by the configuration data clients 112 in order to set the internal register to a given reset value. Similarly, in response to a reset, the state control module 1084 may activate the configuration phase. Specifically, during the configuration phase, the data read module 1080 may read the configuration data CD from the memory 104 and the dispatch module 1082 may send the configuration data CD to the various configuration data clients 112, thereby overwriting the reset values.

    [0047] Accordingly, as mentioned before, the configuration data CD may be stored as data packets/DCF frames in one or more reserved memories of at least one non-volatile memory 104. Generally, the configuration data programmed to the non-volatile memory 104 may not include necessarily configuration data CD for all configuration data clients 112 but only the configuration data CD which are different from the default/reset values.

    [0048] For example, as mentioned in the foregoing, the configuration data CD may comprise several sub-sets of configuration data:
    • a first group of configuration data (e.g., calibration data) written by the producer of the processing system 10a, e.g. the chip manufacture; and
    • a second group of configuration data written during a later stage, such as configuration data written by the firmware developer and/or a system integrator, such as the producer of an Engine Control Unit (ECU).


    [0049] Generally, these groups of configuration data may be written to different areas of the memory(ies) 104, thereby permitting that these groups may be configured independently. Conversely, in various embodiments a single non-volatile memory 104 is used and the data packets/DCF frames may be stored consecutively one after the other. For example, the producer of the processing system 10a may store a first set of configuration data CD to the non-volatile memory and a software developer may store a second set of configuration data to the non-volatile memory by appending the new configuration data to the first set of configuration data. Similarly, also the system developer, e.g. the producer of an ECU, may set a third set of configuration data by appending further configuration data to the second set of configuration data.

    [0050] In the embodiment considered, the configuration module 108 reads these data packets/DCF frames from the non-volatile memory 104 during the reset phase, e.g. as controlled by the state control module 1084. Specifically, in various embodiments, the configuration module 108, in particular the data read module 1080, starts the read operation from a start address of the memory 104 (which may be fixed or programmable) and continuous the reading operation until the last data packets/DCF frame has been read from the non-volatile memory 104. Generally, the data read module 1080 may also access a plurality of non-volatile memories 104, or generally a plurality of memory areas which may belong to one or more non-volatile memories 104. For example, a first memory area may be programmable only by the producer of the processing unit 10a and a second memory area may be programmable by the software and/or system developer.

    [0051] In the embodiment considered, each data packet/DCF frame read from the non-volatile memory 104 is provided to the dispatch module 1082, which forwards the configuration data CD included in the data packet/DCF frame, in particular the payload, to a respective configuration data client 112. Specifically, in the embodiment considered, the dispatch module 1082 is configured to generate a data signal DATA having a given number of bits (corresponding to the bits of the payload) containing the configuration data to be transmitted to a given configuration data client 112 and further control signals for selecting the target configuration data client 112. For example, in the embodiment considered, the dispatch module 1082 generates also an address signal ADR containing the address of the target configuration data client 112 and optionally a chip select signal CS used to signal that the address signal ADR and the data signal DATA are valid. For example, in various embodiments, the address signal ADR (and the chip select signal CS) may be provided to a decoder 124 configured to activate one of the configuration data clients 112 as a function of the address signal ADD. For example, in the embodiment considered, the decoder 124 may set a chip select signal CSa in order to indicate that the configuration data client 112a should read the data signal DATA when the address signal ADR corresponds to an address assigned to the configuration data client 112a (and the chip select signal CS is set). Similarly, the decoder 124 may set a chip select signal CSb in order to indicate that the configuration data client 112b should read the data signal DATA when the address signal ADR corresponds to an address assigned to the configuration data client 112b (and the chip select signal CS is set), etc.

    [0052] Thus, the configuration module 108 will sequentially read the configuration data packets and transmit the respective configuration data to the associated configuration data client 112. Accordingly, the configuration data CD may be stored during the various production and development phase as a sequence of consecutive data packets/DCF frames. For example, this implies that, in case the one or more non-volatile memories 104 contain two or more data packets/DCF frames, which are addressed to the same configuration data client 112, the configuration data module 108 will transmit sequentially the respective configuration data of these two or more data packets/DCF frames to the same configuration data client 112, and the configuration data client 112 will overwrite the previous values, i.e., the configuration data client 112 will only provide the last configuration data having been received.

    [0053] Generally, due to the fact that the configuration data CD stored in the one or more non-volatile memories 104 may also be used to control the various security features of the processing system 10a, it is advantageous that the programmed configuration data CD cannot be altered anymore. For example, in various embodiments, each non-volatile 104 may be configured to inhibit write accesses to already programmed memory locations of the memory area(s) which may comprise configuration data, i.e., the non-volatile memory area(s) where the configuration data may be stored cannot be erased or re-programmed, thereby ensuring that configuration data CD already stored in the one or more non-volatile memories 104 may be altered within the non-volatile memory 104.

    [0054] Generally, the use of plural DCF frames addressed to the same configuration data client 112 may be useful in order to permit a recalibration of the processing system, e.g. by appending a DCF frame with new calibration data to the already existing configuration data CD in the non-volatile memory 104. In fact, in this way, the various calibration data will be read during the reset phase, but the respective configuration data client 112 will only use the calibration data programmed last. Conversely, it may be rather dangerous when already activated security and/or safety functions could be deactivated by simply appending respective configuration data CD to the non-volatile memory 104.

    [0055] Accordingly, in various embodiments, each configuration data client 112 may be configured to permit or inhibit overwriting of previous configuration data. For example, possible solutions for controlling the write operations in a configuration data client 112 are described in the Italian patent application IO2018000001633.

    [0056] Thus, the arrangement described with respect to Figure 4 provides an efficient solution for distributing configuration data CD within a processing system 10a, permitting also that the configuration data CD may be set by different entities (producer, software developer, etc.) without having to overwrite the previous configuration data in the non-volatile memory 104. Moreover, also the reconfiguration of previously written configuration data may be limited within each configuration data client 112.

    [0057] However, the arrangement does not take into account that the configuration data provided by the memory 104 may not correspond to the configuration data stored to the memory 104.

    [0058] For example, the memory 104 may provide incorrect data due to errors in the data contained in the memory, e.g. due to corruption of the configuration data CD, or due to an intentional modification of the data stored in the memory 104. A possible solution to this problem is the use of an error-correcting code (ECC) memory. For example, in this case, the memory 104 comprises an error detection and/or correction circuit 1040 (see Figure 4), which detects and possibly also corrects modifications in the data read from the memory.

    [0059] However, the memory 104 itself may not operate correctly and may not provide at all configuration data or skip one or more configuration data. For example, this may happen when the communication between the data read module 1080 and the memory 104 is not operating correctly. For example, as mentioned before, the data read module 1080 may send an address signal to the memory 104 and the memory 104 may return the respective data signal containing the data stored at the address provided. Hence, an alteration of the address bus (both intentional, like in the case of an attack, or unintentional, like in the case of a malfunction) may result, e.g., in a reading of different data and/or skipping the reading of some configuration data. Similarly, also the data bus between the memory 104 and the data read module 1080 may not operate correctly. However, such malfunctions may not be detected by an error detection and/or correction circuit 1040, insofar as the data read from the memory for a given (incorrect) address are indeed correct and only the communication of the data and/or the address signal is affected by a malfunction.

    [0060] However, in case some configuration data CD are not read correctly or skipped, there could be consequences for availability (the device might not work properly), quality (a wrong behavior could compromise the overall quality), safety (a wrong behavior could translate into a safety threat) and/or security (some security functions may be deactivated).

    [0061] In the following will thus be described embodiments able to verify whether the data transmitted to the configuration data clients 112 indeed corresponds to the data initially written to the non-volatile memory 104.

    [0062] Figure 5a shows a first embodiment of a modified processing system 10a, which essentially corresponds the architecture described with respect to Figure 3. Accordingly, the respective description and the exemplary detailed embodiment of Figure 4 also apply in this case.

    [0063] Specifically, with respect to Figure 3, the memory 104 does not only contain the configuration data CD, but also a respective signature HASH calculated as a function of the configuration data CD.

    [0064] Generally, the term "signature" indicates that the respective signature data are calculated as a function of the configuration data. For example, a hashing function may be used for this purpose, such as MD5 or Secure Hash Algorithm (SHA), e.g. SHA-1 or SHA-256. Generally, the configuration data may also be encoded and/or encrypted, e.g. by using Advanced Encryption Standard (AES) or Data Encryption Standard (DES), and a subset of the encrypted data, e.g. the last data packet, may be used as signature field.

    [0065] As mentioned before, the configuration data may comprise a plurality of sets of configuration data. In this case, each set of configuration data comprises a respective signature. Generally, the signature of the first set of configuration data is calculated as a function of the respective configuration data. Conversely, the signature of the following sets of configuration data may be calculated either:
    • exclusively as a function of the respective set of configuration data, i.e. the signature is independent from the previous sets of configuration data; or
    • taking into account also the previous configuration data, e.g. by calculating a signature for the configuration data of all previous sets of configuration data.


    [0066] Preferably, the first solution is used in order to render the sets of configuration data independent from each other. However, also the second solution may be implemented rather easily when a signature calculation method is used which may simply use the signature of the previous set of configuration data as starting value for the calculation of the new signature. For example, the respective signature value may be provided by the producer of the processing system to the following software developer, etc.

    [0067] In the embodiment considered, the processing system 10a comprises moreover a signature calculation circuit 130 configured to recalculate the signature directly as a function of the configuration data read from the memory 104.

    [0068] Specifically, in the embodiment shown in Figure 5a, the signature calculation circuit 130 receives at input the configuration data having been stored in the internal registers of the data clients 112, i.e. each configuration data client 112 provides the configuration data received not only to the associated hardware block(s) 110 but also the signature calculation circuit 130. Due to the sequential transmission of the configuration data packets to the configuration data clients 112, each configuration data client 112 may thus signal sequentially that new data have been arrived and the signature calculation circuit 130 may read the configuration data from the configuration data client having currently received configuration data, thereby re-calculating a signature HASH' as a function of the configuration data received by the configuration data clients 112.

    [0069] Conversely, Figure 5b shows an embodiment, wherein the signature calculation circuit 130 receives at input the data transmitted to the configuration data client, e.g. the signature calculation circuit 130 monitors the data transmitted on the communication channel 114, e.g. the data signal DATA of Figure 4. Thus, assuming that the configuration data clients also receive the configuration data transmitted, also in this case, the signature calculation circuit may recalculate a signature HASH' as a function of the configuration data transmitted to the configuration data clients 112.

    [0070] Thus, knowing the original signature HASH stored in the memory 104 and by recalculating a signature HASH' as a function of the configuration data provided to the configuration data clients, the processing system 10a may verify whether both signatures correspond.

    [0071] Generally, the solution of Figure 5a is preferably, insofar as indeed the data stored in the configuration data clients 112 are verified, thereby permitting a verification of all intermediate components from the memory 104 up to the configuration data clients 112. However, in this case, the signature calculation circuit 130 has to be connected to all configuration data clients 112 rendering the solution more complex than the solution of Figure 5b, which merely has to monitor the communication channel 114, while still ensuring that the configuration data read from the memory 104 are indeed correct.

    [0072] Figure 6a shows a first embodiment for verifying both signatures HASH and HASH'.

    [0073] Specifically, in the embodiment considered, the configuration module 108 is configured to read the signature HASH from the memory 104 and provide the signature HASH directly to a signature verification circuit 132 configured to compare the signature HASH with the recalculated signature HASH'.

    [0074] Conversely, Figure 6b shows an embodiment, wherein the signature HASH is stored as one or more of the configuration data packets (in particular the last one of a respective set of configuration data). Moreover, one or more of the configuration data clients 112, e.g. the client 112c, represent configuration data clients of the signature verification circuit 132. Thus, by storing in the attribute field of the configuration data packets the address of the respective configuration data client(s) 112, the configuration module 108 will read the signature HASH as a normal configuration data packet and will transmit the signature HASH via the communication channel 114 to the configuration data client (s) associated with the signature verification circuit 132.

    [0075] Accordingly, in both cases, the signature verification circuit 132 receives at input the signature HASH stored in the memory 104 and the signature HASH' recalculated by the signature calculation circuit 130 (see also Figures 5a and 5b) . The circuit 132 may thus verify whether both signatures correspond and may generate an error signal ERR when the signatures do not correspond.

    [0076] For example, Figure 7 shows an embodiment of the verification of the signatures based on the architecture shown in Figure 4.

    [0077] Specifically, as mentioned before, the processing system 10a has to handle an expected configuration data signature HASH and a run-time calculated configuration data signature HASH'. For example, in Figure 7 is shown again a memory 104, possibly comprising an error detection and/or correction circuit 1040, which receives at input an address signal MEM_A and provides at output a data signal MEM_D comprising the respective data. Specifically, as before, the memory 104 comprises one or more sets of configuration data CD, and for each set of configuration data CD a respective signature field. For example, in the embodiment considered, each set of configuration data CD comprises a start packet START _RECORD _DCF. The optional start packet START_RECORD_DCF is followed by one or more configuration data packets DCF_x, DCF_y, DCF_z, etc. comprising the configuration data to be transmitted to the configuration data clients 112 and one or more signature packet HASH_DCF comprising the signature HASH. Preferably, all these packets follow the DCF format described in the foregoing. As described in the foregoing, the signature HASH is pre-calculated and stored in the memory 104 together with the configuration data (typically during the production stage of the processing system and/or the software development phase).

    [0078] Accordingly, the data read module 1080 of the configuration module 108 may read the configuration data including the records START_RECORD_DCF, DCF_x, DCF_y, DCF_z, HASH_DCF from the memory 104 by providing a suitable address signal MEM_A. For example, the data read module 1080 may start the reading from the start address of the first record (i.e. START_RECORD_DCF or DCF_x based on whether a start record is used) and continue reading until the signature record HASH_DCF is detected (e.g. in the absence of a start record START_RECORD_DCF).

    [0079] During the reading of the configuration data records, the data read module 1080 provides the respective configuration data packets (DCF_x, DCF_y, DCF_z, etc.) to the dispatch module 1082 which transmits the configuration data to the configuration data clients 112, e.g. by using the address signal ADR, the data signal DATA and the chip select signal CS described in the foregoing.

    [0080] In the embodiment considered, the processing system 10a comprises moreover a signature calculation circuit 130 configured to capture the configuration data sent to/received by the configuration data clients 112 and calculates in run-time the signature HASH' as a function of the transferred data.

    [0081] For example, for this purpose, the signature calculation circuit 130 may monitor the data signal DATA and or read the configuration data CD' stored in the configuration data clients 112. As mentioned before the later solution is preferable in order to verify also the operation of the configuration data clients 112 themselves. Conversely the former being less complex. Specifically, the former solutions may also be suitable, when the configuration data clients 112 themselves comprise failure detection mechanisms.

    [0082] For example, Figure 8 shows an embodiment of a configuration data client 112 with failure detection mechanism.

    [0083] Specifically, the configuration data client comprises a register 118, e.g. in the form of flip-flops or latches, configured to store the data received via the data signal DATA. For example, in the embodiment considered, the data provided via the data signal DATA are stored in the register 118 when a respective chip select signal CSi is set.

    [0084] In the embodiment considered, the data received do not contain only configuration data, but also error detection data, such as one or more parity bits. Accordingly, in the embodiment considered, the register 118 provides respective configuration data CD' and error detection data PD. For example, as described in the foregoing, the configuration data CD' are provided to one or more blocks 110 of the processing system 10a and optionally also to the signature calculation circuit 130. However, in the embodiment considered, the configuration data CD' and the error detection data PD are provided also to an error detection circuit 120 configured to recalculate the error data as a function of the configuration data CD' and verify whether the recalculated error data correspond to the error detection data PD. For example, in Figure 8, the circuit 120 may generate an error signal ERRP when the error data do not correspond.

    [0085] Accordingly, in such an architecture, each configuration data client may verify whether the transmitted configuration data CD' are also valid.

    [0086] Generally, the signature calculation circuit 130 may thus calculate the signature HASH' sequentially while the configuration data are transmitted to the configuration data clients 112. Once all configuration data CD have been transmitted to the configuration data clients 112, the data read module 112 will thus also read the signature packet(s) HASH_DCF comprising the signature HASH. Specifically, in the embodiment considered, the signature HASH is stored in a register 1090 within the configuration module 108.

    [0087] Accordingly, in the embodiment considered, the signature calculation circuit 130 and the register 1090 provide the signatures HASH and HASH' to a signature verification circuit 132, which compares the signatures HASH and HASH' and generates an error signal ERR when the signatures HASH and HASH' do not correspond.

    [0088] As mentioned before, the one or more signature packets HASH_DCF may also be transmitted to one or more of the configuration data clients 112, which in turn provides then the signature HASH, representing in this case configuration data CD' for the signature verification circuit 132, to the signature verification circuit 132.

    [0089] In the embodiments considered, the two signatures HASH and HASH' are compared directly at a hardware, i.e. by the circuit 132. Additionally or alternatively, the signature values HASH and HASH' may also be provided to the processing unit 102, thereby permitting a software verification of the values. For this purpose, the signature values may be stored in one or more registers addressable by the processing unit 102, so called special-function-registers.

    [0090] Figure 9 shows a method of operation a processing system 10a as described before.

    [0091] Specifically, after a start step 2000, a set of configuration data CD is determined at a step 2002 based on the applications needs, including e.g. calibration data and or security configuration data. Moreover, the respective signature HASH is calculated at the step 2002 and the respective set of configuration data CD including the signature HASH is stored to the non-volatile memory 104 of the processing system 104.

    [0092] At a following step 2004 the processing system 10a is switched on. Accordingly, the processing system 10a will recalculate via the circuit 130 the signature HASH' based on the data transmitted to the configuration data clients 112 and the circuit 132 will compare the signature HASH' with the signature HASH, possibly generating the error signal ERR (e.g. by setting the error signal ERR to high).

    [0093] Accordingly, by monitoring the error signal ERR at a step 2006, the method may detect an incorrect behavior during the reading of the configuration data CD.

    [0094] For example, in case an error is detected (output "Y" of the verification step 2006), one or more operations may be performed at a step 2008 and the method ends at a stop step 2010. The operations at the step 2008 may include, e.g., reprogramming the configuration data, activating a test function of the memory 104 and/or other blocks of the system, resetting the whole micro-controller, etc.

    [0095] Conversely, in case no error is detected (output "N" of the verification step 2006), the method ends directly at the step 2010.

    [0096] In various embodiments, the signature verification circuit 132 may also take into account the life cycle stage of the processing system 10a.

    [0097] For example, Figure 10 shows the exemplary embodiment of Figure 7, wherein an addition block providing life cycle data LCD has been added. Specifically, the life cycle data LCD indicate the life cycle of the product. The life cycle is a permanent signature written into a non-volatile memory, which determines the stage of the processing system 10a during its life-time. For example, the life cycle may be encoded with a bit sequence. In the embodiment considered, this bit sequence is stored in a separate non-volatile memory 126, preferably a one-time programmable memory. In general, the life cycle data LCD may also be stored at reserved memory locations of the memory 104.

    [0098] For example, in various embodiments, the bit sequence LCD stored in the memory 126 may indicate one of the following stages:
    • "production" (LC1), when the processing system 10a, e.g. a micro-controller, is in the chip fabric;
    • "customer delivery" (LC2), when the processing system 10a has been shipped to the 1st tier customer (e.g., a producer of an engine control unit);
    • "OEM production" (LC3), when the device has been shipped to a next-level customer (e.g., a car maker);
    • "in field" (LC4), when the device is installed in the final product (e.g. in a car sold in the market);
    • "failure analysis" (LC5), when the device is shipped back to producer of the processing system 10a or the software developer for diagnostic purposes.


    [0099] In various embodiments, the life cycle data LCD is written such that once a certain stage is reached, it is not possible to revert it back to a previous stage, i.e., the life cycle can only advance. For example, this may be implemented with a one-hot encoding in which a fuse is burned each time a given stage has been reached. For example, the advancing of the life cycle to the next stage may be done by the entity who owns the device in the current life cycle stage (e.g., chip producer will advance the life cycle when it is shipped to the customer delivery stage; the 1st tier customer will advance the life cycle when it is shipped to the OEM production stage, etc.).

    [0100] Accordingly, in this case, the signature verification circuit 132 may by selectively activated or deactivated as a function of the life cycle data LCD. For example, the hardware comparison within the circuit 132 may be activated only when the life cycle indicated by the life cycle data LCD is set to "OEM production" (LC3) or "in field" (LC4) stage, because in other stages the error signal ERR may prevent the testability of the processing system 10a.

    [0101] The solutions described in the foregoing have thus the advantage that the processing system 10a is able to verify that the configuration data CD stored in the memory 104 (which as mentioned in the foregoing may comprise plural sets possibly programmed both by the producer and the customer) are correctly read when the processing system 10a is switched on.

    [0102] For example, as mentioned before, incorrect configuration data may be transmitted or some configuration data may not be transmitted at all due to run-time faults altering the address bus MEM_A. In the solutions described, such address failures may thus be detected without having to use complex data exchange protocols, such as end-to-end error correction (e2eECC) between the non-volatile memory 104 and the configuration data clients.

    [0103] Of course, without prejudice to the principle of the invention, the details of construction and the embodiments may vary widely with respect to what has been described and illustrated herein purely by way of example, without thereby departing from the scope of the present invention, as defined by the ensuing claims.


    Claims

    1. A processing system (10a) comprising:

    - a plurality of configuration data clients (112), each configuration data client (112) comprising a register (118), wherein with each configuration data client (112) is associated a respective address (ADR), and wherein each configuration data client (112) is configured to receive configuration data (DATA) addressed to the respective address (ADR) and store said configuration data received (DATA) in said register (118); and

    - at least one hardware block (110) configured to change operation as a function of the configuration data (CD') stored in the registers (118) of said plurality of configuration data clients (112);

    - a non-volatile memory (104) comprising configuration data (CD) for said plurality of configuration data clients (112) and first signature data (HASH);

    - a hardware configuration module (108) connected to said configuration data clients (112) through a common data bus (DATA) and configured to sequentially read (1080) data from said non-volatile memory (104) and transmit the respective configuration data (DATA) read from said non-volatile memory (104) to the respective configuration data client (112), and to read said first signature data (HASH) from said non-volatile memory (104); and

    - a signature calculation circuit (130) and a signature verification circuit (132); the processing system being characterized in that said configuration data (CD) are stored in the form of data packets (DCF_x, DCF_y, DCF_z) comprising an attribute field identifying the address (ADR) of one of said plurality of configuration data clients (112) and the respective configuration data, wherein said non-volatile memory (104) comprises a plurality of sets of configuration data (CD), wherein respective first signature data (HASH) are stored for each set of configuration data (CD), and wherein:

    - said signature calculation circuit (130) is configured to:

    - monitor the data transmitted on said common data bus (DATA) between said hardware configuration module (108) and said configuration data clients (112), and

    - calculate respective second signature data (HASH') as a function of the respective configuration data (DATA) of each set of configuration data (CD) transmitted to said configuration data clients (112); and

    - a signature verification circuit (132) configured to:

    - compare said first signature data (HASH) read from said non-volatile memory (104) with the respective second signature data (HASH') calculated by said signature calculation circuit (130), and

    - generate an error signal (ERR) when said first signature data (HASH) read from said non-volatile memory (104) and the respective second signature data (HASH') calculated by said signature calculation circuit (130) do not correspond.


     
    2. The processing system (10a) according to Claim 1, wherein said first signature data (HASH) are stored together with said configuration data (CD) in said non-volatile memory (104) the form of one or more data packets (HASH _DCF).
     
    3. The processing system (10a) according Claim 1 or Claim 2, wherein said signature calculation circuit (130) has associated at least one configuration data client (112) and wherein said first signature data (HASH) are stored in said non-volatile memory (104) in the form of configuration data comprising one or more data packets (HASH_DCF) comprising an attribute field identifying the address (ADR) of said at least one configuration data client (112) associated with said signature calculation circuit (130).
     
    4. The processing system (10a) according to any of the previous claims, wherein said signature calculation circuit (130) is configured to:

    - calculate said second signature data with a hashing function, such as MD5 or Secure Hash Algorithm, e.g. SHA-1 or SHA-256; or

    - calculate said second signature data by encoding and/or encrypting said configuration data, e.g. by using the Advanced Encryption Standard or Data Encryption Standard, and selecting a subset of the encoded/encrypted data.


     
    5. The processing system (10a) according to Claim 4, wherein said signature verification circuit (132) is configured to generate said error signal (ERR) taking into account life-cycle data (LCD) stored in a one-time programmable memory (126) of said processing system (10a) .
     
    6. An integrated circuit, such as a micro-controller, comprising a processing system (10a) according to any of Claims 1 to 5.
     
    7. A device, such as a vehicle, comprising a plurality of processing systems (10a) according to any of Claims 1 to 5.
     
    8. A method of operating a processing system (10a) according to any of Claims 1 to 5, comprising the steps of:

    - storing (2002) a plurality of sets of configuration data (CD) and respective first signature data (HASH) for each set of configuration data (CD) in the non-volatile memory (104) of said processing system (10a), wherein said configuration data (CD) are stored in the form of data packets (DCF_x, DCF_y, DCF_z) comprising an attribute field identifying the address (ADR) of one of said plurality of configuration data clients (112) and the respective configuration data;

    - starting (2004) said processing system (10a); and

    - monitoring (2006) the error signal (ERR) generated by said signature verification circuit (132).


     


    Ansprüche

    1. Verarbeitungssystem (10a), umfassend:

    - eine Vielzahl von Konfigurationsdaten-Clients (112), wobei jeder Konfigurationsdaten-Client (112) ein Verzeichnis (118) umfasst, wobei jedem Konfigurationsdaten-Client (112) eine jeweilige Adresse (ADR) zugeordnet ist, und wobei jeder Konfigurationsdaten-Client (112) konfiguriert ist, um Konfigurationsdaten (DATA) zu empfangen, die an die jeweilige Adresse (ADR) gerichtet sind, und die empfangenen Konfigurationsdaten (DATA) in dem Verzeichnis (118) zu speichern; und

    - mindestens einen Hardware-Block (110), der konfiguriert ist, um in Abhängigkeit von den Konfigurationsdaten (CD'), die in den Verzeichnissen (118) der Vielzahl von Konfigurationsdaten-Clients (112) gespeichert sind, den Betrieb zu wechseln;

    - einen nicht flüchtigen Speicher (104), der Konfigurationsdaten (CD) für die Vielzahl von Konfigurationsdaten-Clients (112) und erste Signaturdaten (HASH) umfasst;

    - ein Hardware-Konfigurationsmodul (108), das mit den Konfigurationsdaten-Clients (112) über einen gemeinsamen Datenbus (DATA) verbunden ist, und konfiguriert ist, um sequenziell Daten aus dem nicht flüchtigen Speicher (104) auszulesen (1080) und die jeweiligen, aus dem nicht flüchtigen Speicher (104) ausgelesenen Konfigurationsdaten (DATA) an den jeweiligen Konfigurationsdaten-Client (112) zu übertragen, und um die ersten Signaturdaten (HASH) aus dem nicht flüchtigen Speicher (104) auszulesen; und

    - eine Signaturberechnungsschaltung (130) und eine Signaturüberprüfungsschaltung (132);

    wobei das Verarbeitungssystem dadurch gekennzeichnet ist, dass die Konfigurationsdaten (CD) in der Form von Datenpaketen (DCF_x, DCF_y, DCF_z) gespeichert sind, die ein Attributfeld umfassen, welches die Adresse (ADR) von einem der Vielzahl von Konfigurationsdaten-Clients (112) und die jeweiligen Konfigurationsdaten identifiziert, wobei der nicht flüchtige Speicher (104) eine Vielzahl von Konfigurationsdatensätzen (CD) umfasst, wobei jeweilige erste Signaturdaten (HASH) für jeden Konfigurationsdatensatz (CD) gespeichert sind, und wobei:

    - die Signaturberechnungsschaltung (130) konfiguriert ist zum:

    - Überwachen der in dem gemeinsamen Datenbus (DATA) zwischen dem Hardware-Konfigurationsmodul (108) und den Konfigurationsdaten-Clients (112) übertragenen Daten, und

    - Berechnen jeweiliger zweiter Signaturdaten (HASH') in Abhängigkeit von den jeweiligen Konfigurationsdaten (DATA) jedes zu den Konfigurationsdaten-Clients (112) übertragenen Konfigurationsdatensatzes (CD); und

    - eine Signaturüberprüfungsschaltung (132), konfiguriert zum:

    - Vergleichen der ersten, aus dem nicht flüchtigen Speicher (104) ausgelesenen Signaturdaten (HASH) mit den jeweiligen zweiten Signaturdaten (HASH'), die durch die Signaturberechnungsschaltung (130) berechnet werden, und

    - Generieren eines Fehlersignals (ERR), wenn die ersten, aus dem nicht flüchtigen Speicher (104) ausgelesenen Signaturdaten (HASH) und die jeweiligen zweiten, durch die Signaturberechnungsschaltung (130) berechneten Signaturdaten (HASH') nicht übereinstimmen.


     
    2. Verarbeitungssystem (10a) nach Anspruch 1, wobei die ersten Signaturdaten (HASH) gemeinsam mit den Konfigurationsdaten (CD) in dem nicht flüchtigen Speicher (104) in der Form von einem oder mehreren Datenpaketen (HASH_DCF) gespeichert sind.
     
    3. Verarbeitungssystem (10a) nach Anspruch 1 oder Anspruch 2, wobei die Signaturberechnungsschaltung (130) mindestens einen zugeordneten Konfigurationsdaten-Client (112) aufweist, und wobei die ersten Signaturdaten (HASH) in dem nicht flüchtigen Speicher (104) in der Form von Konfigurationsdaten gespeichert sind, die ein oder mehrere Datenpakete (HASH_DCF) umfassen, die ein Attributfeld umfassen, das die Adresse (ADR) des mindestens einen Konfigurationsdaten-Client (112) identifiziert, der der Signaturberechnungsschaltung (130) zugeordnet ist.
     
    4. Verarbeitungssystem (10a) nach einem der vorstehenden Ansprüche, wobei die Signaturberechnungsschaltung (130) konfiguriert ist zum:

    - Berechnen der zweiten Signaturdaten mit einer Hash-Funktion, wie MD5 oder einem sicheren Hash-Algorithmus, z.B. SHA-1 oder SHA-256; oder

    - Berechnen der zweiten Signaturdaten durch Codieren und/oder Verschlüsseln der Konfigurationsdaten, z.B. durch Verwenden des Advanced Encryption Standards oder Data Encryption Standards, und Auswählen einer Teilmenge der codierten/verschlüsselten Daten.


     
    5. Verarbeitungssystem (10a) nach Anspruch 4, wobei die Signaturüberprüfungsschaltung (132) konfiguriert ist, um das Fehlersignal (ERR) zu generieren, das Lebenszyklusdaten (LCD) berücksichtigt, die in einem einmal programmierbaren Speicher (126) des Verarbeitungssystems (10a) gespeichert sind.
     
    6. Integrierte Schaltung, wie ein Mikro-Controller, ein Verarbeitungssystem (10a) nach einem der Ansprüche 1 bis 5 umfassend.
     
    7. Vorrichtung, wie ein Fahrzeug, eine Vielzahl von Verarbeitungssystemen (10a) nach einem der Ansprüche 1 bis 5 umfassend.
     
    8. Verfahren zum Betreiben eines Verarbeitungssystems (10a) nach einem der Ansprüche 1 bis 5, die folgenden Schritte umfassend:

    - Speichern (2002) einer Vielzahl von Konfigurationsdatensätzen (CD) und jeweiliger erster Signaturdaten (HASH) für jeden Konfigurationsdatensatz (CD) in dem nicht flüchtigen Speicher (104) des Verarbeitungssystems (10a), wobei die Konfigurationsdaten (CD) in der Form von Datenpaketen (DCF_x, DCF_y, DCF_z) gespeichert sind, die ein Attributfeld umfassen, welches die Adresse (ADR) von einem der Vielzahl von Konfigurationsdaten-Clients (112) und die jeweiligen Konfigurationsdaten identifiziert;

    - Starten (2004) des Verarbeitungssystems (10a); und

    - Überwachen (2006) des Fehlersignals (ERR), das durch die Signaturüberprüfungsschaltung (132) generiert wird.


     


    Revendications

    1. Système de traitement (10a) comprenant :

    une pluralité de clients de données de configuration (112), chaque client de données de configuration (112) comprenant un registre (118), dans lequel à chaque client de données de configuration (112) est associée une adresse respective (ADR), et dans lequel chaque client de données de configuration (112) est configuré pour recevoir des données de configuration (DATA) adressées à l'adresse respective (ADR) et stocker lesdites données de configuration (DATA) reçues dans ledit registre (118) ; et

    au moins un bloc matériel (110) configuré pour changer de fonctionnement en fonction des données de configuration (CD') stockées dans les registres (118) de ladite pluralité de clients de données de configuration (112) ;

    une mémoire non volatile (104) comprenant des données de configuration (CD) pour ladite pluralité de clients de données de configuration (112) et des premières données de signature (HASH) ;

    un module de configuration de matériel (108) connecté auxdits clients de données de configuration (112) par un bus de données commun (DATA) et configuré pour lire séquentiellement (1080) : des données depuis ladite mémoire non volatile (104) et transmettre les données de configuration (DATA) respectives lues depuis ladite mémoire non volatile (104) au client de données de configuration (112) respectif, et pour lire lesdites premières données de signature (HASH) depuis ladite mémoire non volatile (104) ; et

    un circuit de calcul de signature (130) et un circuit de vérification de signature (132) ;

    le système de traitement étant caractérisé en ce que lesdites données de configuration (CD) sont stockées sous la forme de paquets de données (DCF_x, DCF_y, DCF_z) comprenant un champ d'attribut identifiant l'adresse (ADR) de l'un de ladite pluralité de clients de données de configuration (112) et les données de configuration respectives, dans lequel ladite mémoire non volatile (104) comprend une pluralité de séries de données de configuration (CD), dans lequel des premières données de signature (HASH) respectives sont stockées pour chaque série de données de configuration (CD), et dans lequel :
    ledit circuit de calcul de signature (130) est configuré pour :

    contrôler les données transmises sur ledit bus de données commun (DATA) entre ledit module de configuration de matériel (108) et lesdits clients de données de configuration (112), et

    calculer des secondes données de signature (HASH') respectives en fonction des données de configuration (DATA) respectives de chaque série de données de configuration (CD) transmise auxdits clients de données de configuration (112) ; et

    un circuit de vérification de signature (132) configuré pour :

    comparer lesdites premières données de signature (HASH) lues depuis ladite mémoire non volatile (104) avec les secondes données de signature (HASH') respectives calculées par ledit circuit de calcul de signature (130), et

    générer un signal d'erreur (ERR) quand lesdites premières données de signature (HASH) lues depuis ladite mémoire non volatile (104) et les secondes données de signature (HASH') respectives calculées par ledit circuit de calcul de signature (130) ne se correspondent pas.


     
    2. Système de traitement (10a) selon la revendication 1, dans lequel lesdites premières données de signature (HASH) sont stockées ensemble avec lesdites données de configuration (CD) dans ladite mémoire non volatile (104) sous la forme d'un ou plusieurs paquets de données (HASH_DCF).
     
    3. Système de traitement (10a) selon la revendication 1 ou la revendication 2, dans lequel ledit circuit de calcul de signature (130) a associé au moins un client de données de configuration (112) et dans lequel lesdites premières données de signature (HASH) sont stockées dans ladite mémoire non volatile (104) sous la forme de données de configuration comprenant un ou plusieurs paquets de données (HASH_DCF) comprenant un champ d'attribut identifiant l'adresse (ADR) dudit au moins un client de données de configuration (112) associé audit circuit de calcul de signature (130).
     
    4. Système de traitement (10a) selon l'une quelconque des revendications précédentes, dans lequel ledit circuit de calcul de signature (130) est configuré pour :

    calculer lesdites secondes données de signature avec une fonction de hachage, comme un MD5 ou un algorithme de hachage sécurisé, par exemple SHA_1 ou SHA_256 ; ou

    calculer lesdites secondes données de signature en codant et/ou cryptant lesdites données de configuration, par exemple en utilisant la l'Advanced Encryption Standard ou le Data Encryption Standard, et en sélectionnant une sous-série des données codées/cryptées.


     
    5. Système de traitement (10a) selon la revendication 4, dans lequel ledit circuit de vérification de signature (132) est configuré pour générer ledit signal d'erreur (ERR) en prenant en compte des données de cycle de vie (LCD) stockées dans une mémoire programmable une seule fois (126) dudit système de traitement (10a).
     
    6. Circuit intégré, comme une microcommande, comprenant un système de traitement (10a) selon l'une quelconque des revendications 1 à 5.
     
    7. Dispositif, comme un véhicule, comprenant une pluralité de systèmes de traitement (10a) selon l'une quelconque des revendications 1 à 5.
     
    8. Procédé de fonctionnement d'un système de traitement (10a) selon l'une quelconque des revendications 1 à 5, comprenant les étapes de :

    stockage (2002) d'une pluralité de séries de données de configuration (CD) et de premières données de signature (HASH) respectives pour chaque série de données de configuration (CD) dans la mémoire non volatile (104) dudit système de traitement (10a), dans lequel lesdites données de configuration (CD) sont stockées sous la forme de paquets de données (DCF_x, DCF_y, DCF_z) comprenant un champ d'attribut identifiant l'adresse (ADR) de l'un de ladite pluralité de clients de données de configuration (112) et les données de configuration respectives ;

    démarrage (2004) dudit système de traitement (10a) ; et

    contrôle (2006) du signal d'erreur (ERR) généré par ledit circuit de vérification de signature (132).


     




    Drawing


























    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description