TWI768198B - Microcontroller, memory module, and method for updating firmware of the microcontroller - Google Patents

Abstract

The present disclosure provides a microcontroller unit having a processing unit and a memory unit. The memory unit is configured to include a bootloader section with a computer program code. When the computer program code is executed by the processing unit, the microcontroller unit performs a check mechanism according to a plurality of data blocks and a plurality of checksums associated with the data blocks to generate a plurality of first check results during update of firmware. A memory module including the microcontroller unit is also provided. A method for initializing and updating firmware of the microcontroller unit is also provided.

Description

Microcontroller, memory module and method for updating firmware of microcontroller

The present invention relates to a microcontroller, a memory module and a method for updating the firmware of the microcontroller, in particular to a microcontroller, a memory module and a method for updating the firmware without power failure.

A memory module may include a module board and some volatile memory components mounted on the module board. Some components other than memory components (eg, optical components, audio components, etc.) can also be integrated into the module board. One or more controllers (eg, Microcontroller Unit, MCU) are thus introduced on the memory module to control these components.

The firmware run by the controller may need to be updated to fix bugs that cause the failure of these non-memory components or to add features to these non-memory components.

The present invention provides a firmware update solution that does not require shutting down the computer power to minimize interruption to users.

Some embodiments of the present invention provide a microcontroller unit (Microcontroller Unit, MCU). The MCU includes a processing unit and a memory unit. The memory unit is configured to include a boot loader section. The boot loader section is configured to store computer code. The computer code, when executed by the processing unit, causes the MCU to perform a first check mechanism according to a plurality of data blocks and a plurality of check sums associated with the data blocks to generate a plurality of first check mechanisms during the firmware update phase test result.

Some embodiments of the present invention provide a memory module. The memory module includes a module board, a plurality of volatile memory components and an MCU. The module board has an interface. The volatile memory component is disposed on the module board, and is electrically connected to an external central processing unit (CPU) through an interface. The MCU is disposed on the module board and is configured to: receive a plurality of data blocks and a plurality of checksums from an external CPU in a boot loader mode, each of the plurality of data blocks and a plurality of checksums from the plurality of checksums a specified checksum pairing of the sums, wherein the data blocks and the checksums are retrieved from the updated firmware file by the external CPU; and checking whether each of the plurality of data blocks corresponds to the specified checksums.

Some embodiments of the present invention provide a method for updating the firmware of an MCU. The MCU is communicatively coupled to an external CPU via a channel. The method includes: an external CPU receives an updated firmware file; the external CPU executes the updated firmware file to obtain a plurality of data blocks and a plurality of checksums associated with the data blocks; the MCU receives the data in the plurality of data blocks The first data block and the plurality of checksums are assigned to a first checksum of the first data block; and the MCU executes a check mechanism according to the first data block and the first checksum to generate a first check result.

Some embodiments of the present invention provide a method for initializing an MCU. The MCU is communicatively coupled to an external CPU via a channel. The method includes: the MCU checks and executes a first check mechanism according to the application data in the application section and the application in the data section to generate a first check result; when the first check result is correct, the MCU enters the application program mode; when the first check result is incorrect, the MCU enters the boot loader mode; and When the MCU is in the boot loader mode, execute the mentioned method of updating the firmware of the MCU.

10: Internet connection

11: Update the firmware provider

13: Updated firmware receiver

21: Updated firmware provider

23: Updated firmware device

25: User terminal

27: Computer-readable media

110:Updated firmware

130: Busbar

131: Communication module

132: Central Processing Unit

133: Memory module

135:MCU

139: Motherboard

210: Updated firmware

230: Busbar

231: Interface

232:CPU

233: Memory Module

235:MCU

239: Motherboard

310: Updated firmware file

330: System management bus or inter-circuit bus

332:CPU

333: Memory Module

334: Module Board

335:MCU

336: Serial presence detection unit

337: Interface

339: Motherboard

411: Data block

412: Checksum

435:MCU

435M: memory unit

435P: Processing unit

901: Connector

903:MCU

4350: Application section

4350a: Application Data

4352: Data section

4352a: Information on application data

4352b: Application Checksum

4354: Bootloader section

PG: computer code

PG1: First Check Mechanism

PG2: Second Inspection Mechanism

S501: Operation

S502: Operation

S503: Operation

S504: Operation

S505: Operation

S701: Operation

S702: Operation

S703: Operation

S704: Operation

S705: Operation

S706: Operation

S707: Operation

S708: Operation

S709: Operation

S801: Operation

S802: Operation

S803: Operation

S804: Operation

S805: Operation

S806: Operation

S807: Operation

S808: Operation

S809: Operation

S810: Operation

S811: Operation

U1: Volatile Memory Components

U2: Volatile Memory Components

U3: Volatile Memory Components

U4: Volatile Memory Components

U5: Volatile Memory Components

U6: Volatile Memory Components

U7: Volatile Memory Components

U8: Volatile Memory Components

Aspects of the invention are best understood when the following detailed description is read in conjunction with the accompanying drawings. It should be noted that various features may not be drawn to scale. In fact, the dimensions of the various features may be arbitrarily increased or decreased for clarity of discussion.

1 is a block diagram of a firmware update environment including an updated firmware provider and an updated firmware receiver, according to some embodiments of the present invention.

2 is a block diagram of a firmware update environment including an updated firmware provider, a user terminal, and a computer-readable medium, according to some embodiments of the present invention.

3 is a connection diagram illustrating the connection between a memory module and a motherboard according to some embodiments of the present invention.

4A and 4B are block diagrams showing several functional blocks in a microcontroller unit according to some embodiments of the invention.

5 is a flowchart showing a method for firmware initialization and update according to some embodiments of the present invention.

6 is a schematic diagram of processing an updated firmware file according to some embodiments of the present invention.

7 is a flowchart showing a method for firmware initialization and update according to some embodiments of the present invention.

8 is a flowchart showing a method for firmware initialization and update according to some embodiments of the present invention.

9 is a memory module according to some comparative embodiments of the present invention.

The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Specific examples of components and configurations are described below to simplify the present disclosure. Of course, these components and configurations are examples only and are not intended to be limiting. In the present invention, reference in the following description to the formation of the first feature over or on the second feature may include embodiments in which the first feature is formed in direct contact with the second feature, and may also include additional features that may be formed on the first feature and the second feature so that the first feature may not be in direct contact with the second feature. Additionally, the present disclosure may repeat reference numerals and/or letters in various instances. This repetition is for the purpose of simplicity and clarity, and does not in itself indicate a relationship between the various embodiments and/or configurations discussed.

Embodiments of the invention are discussed in greater detail below. It should be appreciated, however, that the present disclosure provides many applicable concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are illustrative only and do not limit the scope of the invention.

Also, for ease of description, such as "under", "below", "above", "upper", "lower", " The spatially relative terms "left", "right", and similar terms, may be used herein to describe the relationship of one element or feature to another element or feature as illustrated in the figures. In addition to the orientation depicted in the figures, spatially relative terms are intended to encompass different orientations of the device in use or operation. The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein interpreted accordingly. It will be understood that when an element is referred to as being "connected" or "coupled to" another element, it can be directly connected or coupled to the other element or intervening elements may be present.

The numerical ranges and parameters setting forth the broad scope of the invention are approximations, and the numerical values set forth in the specific examples are reported as precisely as possible. Some numerical values, however, may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements. In addition, as used herein In use, the term "about" generally means within ±10%, ±5%, ±1%, or ±0.5% of a given value or range. Alternatively, as is generally understood by those skilled in the art, the term "about" means within an acceptable standard error of the mean. Except in operating/working examples, or unless expressly specified otherwise, numerical ranges, amounts, values, and percentages (such as amounts of materials, durations, temperatures, operating conditions, ratios of amounts, and the like disclosed herein) All of the like) should be understood to be modified in all instances by the term "about". Accordingly, unless indicated to the contrary, the numerical parameters set forth in this disclosure and the appended claims are approximations that may vary. At a minimum, each numerical parameter should be understood in light of the number of reported significant digits and by applying ordinary rounding techniques. A range can be expressed herein as from one endpoint to the other or between the two endpoints. All ranges disclosed herein are inclusive of the endpoints unless otherwise specified. The term "substantially coplanar" can refer to two surfaces that lie within a few micrometers (μm) along the same plane, such as within 10 μm, 5 μm, 1 μm, or 0.5 μm along the same plane. When values or properties are said to be "substantially" the same, the term can mean that the values are within ±10%, ±5%, ±1%, or ±0.5% of the mean of the values.

Some components can be integrated into Dynamic Random Access Memory (DRAM) modules to provide additional functions (eg, visual effects, audio effects, power management, etc.). A Microcontroller Unit (MCU) is also incorporated into the DRAM module to control these components.

Referring to FIG. 1 , which is a block diagram of a firmware update environment including an updated firmware provider 11 and an updated firmware receiver 13 according to some embodiments of the present invention. The updated firmware receiving end 13 includes a communication module 131 , a central processing unit (CPU) 132 and a memory module 133 including an MCU 135 . The communication module 131 , the CPU 133 and the memory module 133 are arranged on the motherboard 139 and are electrically coupled by the bus bar 130 . firmware here In the update environment, a network connection 10 is established between the updated firmware provider 11 and the updated firmware receiver 13 for transmitting related data. The interaction between these elements will be further described below.

In some embodiments, when the updated firmware 110 is developed and ready for distribution, the updated firmware provider 11 may transmit the updated firmware 110 to the updated firmware receiver 13 via the network connection 10 . On the other hand, the communication module 131 of the updated firmware receiving end 13 receives the updated firmware 110 . Then, after the updated firmware 110 is received by the updated firmware receiver 13 , the CPU 132 of the updated firmware receiver 13 can preprocess the updated firmware 110 and forward the updated firmware 110 to the memory module 133 MCU135. Therefore, the MCU 135 can update the firmware of the MCU 135 through the updated firmware 110 .

It should be particularly understood that, in some embodiments, the communication module may be a combination of a network data transmitter and a network data receiver, or a combination of circuits for transmitting network data and receiving network data. However, such descriptions are not intended to limit hardware-implemented embodiments of the present invention.

2, which is a block diagram of a firmware update environment including an updated firmware provider 21, an updated firmware device 23, a user terminal 25, and a computer-readable medium 27 according to some embodiments of the present invention. The updated firmware device 23 includes an interface 231 , a CPU 232 and a memory module 233 including an MCU 235 . The interface 231 , the CPU 233 and the memory module 233 are disposed on the motherboard 239 and are electrically coupled by the bus bar 230 . The interaction between these elements will be further described below.

In some embodiments, the updated firmware 210 may first be recorded on the computer-readable medium 27 when the updated firmware 210 is developed and ready for distribution. Then, the updated firmware provider 21 provides the computer-readable medium 27 with the updated firmware 210 to the user terminal 25 . After the user terminal 25 obtains the computer-readable medium 27 with the updated firmware 210, the updated The interface 231 of the firmware device 23 can be used to retrieve the updated firmware 210 from the computer-readable medium 27 . Next, after the updated firmware device 23 retrieves the updated firmware 210 , the CPU 232 of the updated firmware device 23 can preprocess the updated firmware 210 and forward the updated firmware 210 to the MCU 235 of the memory module 233 . Therefore, the MCU 235 can update the firmware of the MCU 235 through the updated firmware 210 .

It should be particularly understood that, in some embodiments, the computer-readable medium may be implemented as a non-transitory electronic product, such as read-only memory (ROM), flash memory, floppy disk, hard disk, optical disk ( Compact Disc, CD), Digital Versatile Disc (DVD), Blu-ray Disc (Blueray Disc, BD) or any other storage media with the same function. The interface can be an I/O port or a data reading device for receiving computer-readable media. However, such descriptions are not intended to limit hardware-implemented embodiments of the present invention.

3, which is a connection diagram illustrating the connection between the memory module 333 on the motherboard 339 and the CPU 332 according to some embodiments of the present invention. The memory module 333 includes a module board 334 having an interface 337 , an MCU 335 disposed on the module board 334 , and a plurality of volatile memory components U1 to U8 disposed on the module board 334 . The memory module 333 is attached to the motherboard 339 via the interface 337 , and the MCU 335 exchanges data with the CPU 332 on the motherboard 339 via the interface 337 . The interaction between these elements will be further described below.

In some embodiments, when the MCU 335 enters the boot loader mode, the MCU 335 may enter the update process. Therefore, the MCU 335 receives the plurality of data blocks and the plurality of checksums of the updated firmware file 310 from the CPU 332 . Each of the plurality of data blocks is paired with a designated checksum of the plurality of checksums. Next, the MCU 335 checks whether each data block corresponds to the specified checksum. When each data block corresponds to a specified checksum, the data block is verified and the updated firmware file 310, which is a collection of data blocks, is thus verified. Therefore, MCU 335 can borrow Update from the updated firmware file 310 and enter application mode. On the other hand, when there is a data block that does not correspond to the specified checksum, the transmission of the data block may be incomplete or the data block may be accidentally altered or corrupted during transmission. Therefore, the MCU 335 can remain in the boot loader mode and recheck whether each data block corresponds to the specified data block.

In some embodiments, the MCU 335 can communicate with the CPU 332 on the motherboard 339 via the interface 337 and a System Management Bus (SMBus) or Inter-Integrated Circuit (IIC) bus 330 . In some embodiments, the memory module 333 includes a Serial Presence Detect (SPD) unit 336 , and an SMBus or IIC bus 330 can be used for the SPD unit 336 to communicate with the CPU 332 . In some embodiments, the MCUs 335 share a communication channel, such as an SMBus or IIC bus 330 between the SPD unit 336 and the CPU 332 . Since the SMBus or CII bus 330 connects multiple devices or modules to the motherboard 339 , the aforementioned multiple devices or modules can simultaneously send or receive data via the SMBus or CII bus 330 . However, the SMBus or CII bus 330 can only allow one device or module to send or receive data to/from the motherboard 339 at a time, so a faulty or incomplete data transfer may necessarily occur on the SMBus or CII Occurs between bus 330 and CPU 332 on motherboard 339 . In order to reduce this transmission difficulty, especially when using SMBus or CII bus 330 as a communication channel, the accuracy of data transmission can be improved by transmitting a pair of data blocks at a time and specifying a checksum, as shown in Figures 5 to 5 of the present invention. discussed in FIG. 8 .

It should be particularly appreciated that, in some embodiments, the volatile memory elements U1-U8 may comprise memory cells of DRAM. The interface 337 may be an interface compatible with Peripheral Component Interconnect (PCI) or Peripheral Component Interconnect Express (PCI-E, PCIe). However, this The class descriptions are not intended to limit hardware-implemented embodiments of the present invention.

4A, which is a block diagram showing functional blocks in MCU 435 according to some embodiments of the present invention. The MCU 435 includes a processing unit 435P and a memory unit 435M. Memory unit 435M may include bootloader section 4354. The boot loader section 4354 stores the computer code PG. The interaction between these elements will be further described below.

In some embodiments, the computer code PG, when executed by the processing unit 435P, causes the MCU 435 to execute the first check mechanism PG1 according to the plurality of data blocks 411 and the plurality of checksums 412 associated with the data blocks to A plurality of first check results are generated during firmware update. In other words, when the MCU 435 is in the boot loader mode, the MCU 435 executes the first check mechanism PG1 according to the data block 411 and the checksum 412 to generate a first check result, and checks whether the first check result is useful for updating the firmware all right.

4B, which is a block diagram showing detailed functional blocks in MCU 435 according to some embodiments of the present invention. Memory unit 435P may further include application section 4350 and data section 4352. Application section 4350 stores application data 4350a. Data section 4352 stores information 4352a and application checksum 4352b of application data 4350a. The interaction between these elements will be further described below.

In some embodiments, the application data 4350a may include the application firmware of the MCU 435. The information 4352a of the application data 4350a may include the version of the application firmware, the size of the application firmware, and the memory address of the application firmware. Application checksum 4352b may be the checksum data generated based on application data 4350a.

It should be noted that, in some embodiments, the generation of application checksum 4352b may be performed by entering application data 4350a into the checksum function. In detail, check and letter The number can be related to a hash function, a fingerprint, a randomization function, or a cryptographic hash function. Thus, when the application data 4350a is input into the checksum function, the application checksum 4352b corresponding to the application data 4350a is exported as the output of the checksum function. Thus, due to the correlation between application data 4350a and application checksum 4352b, application checksum 4352b can be used to verify that application data 4350a has not been accidentally altered or corrupted.

The boot loader section 4354 stores computer code PG for the MCU 435 to perform different checking mechanisms at different stages. In some embodiments, the MCU 435 is in the initialization phase when the MCU 435 is activated, and the computer code PG is executed by the processing unit 435P for executing the second check mechanism PG2 according to the application data 4350a and the application checksum 4352, to A second check result is generated. Specifically, since the application checksum 4352b is the checksum data of the application data 4350a, the processing unit 435 can check whether the application checksum 4352b corresponds to the application data 4350a, and generate a second check result.

In some embodiments, when the second check result is correct, that is, when the application checksum 4352b corresponds to the application data 4350a, the processing unit 435P controls the MCU 435 to enter the application mode. Thus, application checksum 4352b corresponding to application data 4350a may indicate that application data 4350a may not have been accidentally altered or corrupted. Therefore, the MCU 435 can enter the application mode. In some embodiments, when the second check result is incorrect, that is, when the application checksum 4352b does not correspond to the application data 4350a, the processing unit 435P controls the MCU 435 to enter the boot loader mode. Thus, failure to correspond to application checksum 4352b of application data 4350a may indicate that application data 4350a may have been accidentally altered or corrupted. Therefore, the MCU 435 can enter the boot loader mode to update the application data 4350a.

In some embodiments, the MCU 435 is in the update stage when it is being updated segment, and the computer code PG is executed by the processing unit 435P to execute the first check mechanism PG1 according to the data blocks 411 and the checksums 412 assigned to the data blocks 411 to generate a first check result. Specifically, when the MCU 435 is in the update phase, the processing unit 435P first receives the data block 411 and the checksum 412 . Since one checksum 412 is assigned to one data block 411, the processing unit 435P can check whether the checksum 412 corresponds to the data block 411, respectively, and generate a first check result.

In some embodiments, when the first check result of the data block 411 and the checksum 412 is correct, that is, when the checksum 412 corresponds to the data block 411 respectively, the processing unit 435P controls the MCU 435 to enter from the boot loader mode application mode. Thus, the checksum 412 corresponding to the data block 411 may indicate that the transmission of the data block 411 used to update the MCU 435 has been completed and the received data block 411 has been verified. Thus, the MCU 435 can be updated and then enter application mode.

In some embodiments, when one of the first check results is incorrect, that is, when a data block 411a of the data blocks 411 does not correspond to a checksum 412a in the checksum 412 assigned to the data block 411a, The processing unit 435P controls the MCU 435 to remain in the boot loader mode. Thus, failure to correspond to a data block 411a of the specified checksum 412a may indicate that one of the transmissions for updating the data block 411a of the MCU 435 is incomplete or that the data block 411a may be accidentally altered or corrupted during the transmission. Therefore, the MCU 435 can remain in the boot loader mode. In addition, the MCU 435 may re-fetch the data block 411a and the checksum 412a for regenerating the corresponding check result, and recheck the correctness of the corresponding check result based on the aforementioned operations.

Some embodiments of the present invention include a method for firmware initialization and update, and a flowchart of which is shown in FIG. 5 . The methods of some embodiments are used in MCUs (eg, the aforementioned The MCU of the embodiment), and the MCU communicates with an external CPU (eg, the CPU of the motherboard of the foregoing embodiment) through a channel (eg, the SMBus or the IIC bus of the foregoing embodiment). The detailed operation of the method is as follows.

The MCU performs operation S501 to check and execute a check mechanism according to the application data stored in the application section of the MCU and the application program stored in the data section of the MCU to generate a check result. In this embodiment, the application checksum should correspond to the application data. The MCU performs operation S502 to check whether the check result is correct. In other words, in operation S502, the MCU checks whether the application checksum corresponds to the application data.

In some embodiments, when the check result is correct (ie, when the pair of application checksums correspond to application data), the MCU performs operation S503 to enter the application mode. In some embodiments, when the check result is incorrect (ie, when the pair of application checksums and application data do not correspond), the MCU performs operation S504 to enter the boot loader mode. The MCU performs operation S505 to perform firmware update based on the foregoing embodiment.

Some embodiments of the present invention include a method for firmware initialization and update, and a flowchart of which is shown in FIG. 7 . The methods of some embodiments are used in an MCU (eg, the MCU of the aforementioned embodiments), and the MCU communicates with an external CPU (eg, the CPU of the motherboard of the aforementioned embodiments) via channels (eg, the SMBus and IIC bus of the aforementioned embodiments) ) communication. The detailed operation of the method is as follows.

Before updating the MCU with the updated firmware file, the updated firmware file can be processed by the external CPU to derive data blocks and checksum pairs, as shown in FIG. 6 . Subsequently, the MCU performs operation S701 to enter the boot loader mode. The MCU performs operation S702 to receive a pair of data block i and a checksum i of one of the updated firmware files through the channel. In some embodiments, the updated firmware file includes N number of data blocks and N number of checks associated with the N number of data blocks Checksum, and checksum i is assigned to block i, where i equals 1 to N. The MCU performs operation S703 to perform a check mechanism on the pair of data blocks i and checksum i to generate a check result i. The MCU performs operation S704 to determine whether the check result i is correct. In other words, in operation S704, the MCU checks whether the checksum i corresponds to the data block i.

In some embodiments, when the check result i is correct (ie, when the pair of data block i and the check sum i correspond), the MCU performs operation S705 to determine whether the data block i is the last data block. If the data block i is not the last data block, the MCU performs operation S706 to add a value of 1 to i, and performs operation S702 on the MCU to receive the next pair of data blocks and the specified checksum and perform subsequent operations. If the data block i is determined to be the last data block, the MCU performs operation S707 to update the firmware of the MCU with the updated firmware file, which may be a set of the paired data blocks and the specified checksum . The MCU performs operation S708 to enter the application mode after the firmware of the MCU is updated.

In some embodiments, when the check result i is determined to be incorrect in operation S704 (that is, when the pair of data block i and checksum i do not correspond), operation S702 is directly performed on the MCU to receive the pair again Block i and check sum i and perform subsequent operations.

In some embodiments, the MCU may be instructed to enter boot loader mode before updating the firmware. Specifically, when the external CPU retrieves the updated firmware file from the updated firmware provider via the communication module of the motherboard, the external CPU can instruct the MCU to enter the boot loader mode and prepare to update the firmware.

In some embodiments, when the check result i is determined to be incorrect in operation S704, the MCU optionally performs operation S709 (represented by a dotted line) to notify the external CPU to resend the data block i of the updated firmware file and the checksum i.

Some embodiments of the present invention include a method for firmware initialization and update method, and its flowchart is shown in FIG. 8 . The methods of some embodiments are used in an MCU (eg, the MCU of the aforementioned embodiments), and the MCU communicates with an external CPU (eg, the CPU of the motherboard of the aforementioned embodiments) via channels (eg, the SMBus and IIC bus of the aforementioned embodiments) ) communication. The detailed operation of the method is as follows.

Similarly, before updating the MCU with the updated firmware file, the updated firmware file can be processed by the external CPU to derive data blocks and checksum pairs, as shown in FIG. 8 . Subsequently, the MCU performs operation S801 to enter the boot loader mode. The MCU performs operation S802 to receive a pair of data block i and a checksum i of one of the updated firmware files through the channel. In some embodiments, the updated firmware file includes N number of data blocks and N number of checksums associated with the N number of data blocks, and the checksum i is assigned to data block i, where i equals 1 to N. The MCU performs operation S803 to perform a check mechanism on the pair of data blocks i and checksum i to generate a check result i. The MCU performs operation S804 to determine whether the check result i is correct. In other words, in operation S804, the MCU checks whether the checksum i corresponds to the data block i.

In some embodiments, when the check result i is correct (ie, when the pair of data block i and the check sum i correspond), the MCU performs operation S805 to determine whether the data block i is the last data block. If the data block i is not the last data block, the MCU performs operation S806 to add a value of 1 to i, and performs operation S802 for the MCU to receive the next pair of data blocks and the specified checksum and perform subsequent operations.

In some embodiments, if the data block i is the last data block, the MCU performs operation S807 to perform a general check mechanism on the updated firmware file to generate a general check result. The MCU executes S808 to determine whether the total check result is correct. In other words, in operation S808, the MCU checks whether the total checksum corresponds to the updated firmware file.

In some embodiments, when the total check result is correct (that is, when the pair is updated When the new firmware file and the total checksum are corresponding), the MCU executes operation S809 to update the firmware of the MCU by the updated firmware file, which is a set of the paired data blocks and the specified checksum. The MCU performs operation S810 to enter the application mode after the firmware of the MCU is updated.

In some embodiments, when the total check result is incorrect (that is, when the updated firmware file and the total checksum do not correspond), the MCU performs operation S811 to reset the i value to 1, and performs operations on the MCU S802 to receive the first pair of data blocks and the specified checksum and perform subsequent operations.

In some embodiments, when the check result i is determined to be incorrect in operation S804 (that is, when the pair of data block i and checksum i do not correspond), operation S802 is directly performed on the MCU to receive the pair again Block i and specify checksum i and perform subsequent operations.

Referring to FIG. 9, a comparative example of a memory module is shown. The memory modules include MCU 903, sockets, jumpers or connectors 901 for external connection, and some memories U1, U2, U3, U4, U5, U6, U7 and U8.

In general, if a memory module fails due to any physical or hardware damage found in MCU 903, the old MCU is replaced with another MCU (eg, a new or good MCU not shown in Figure 9). ) can be one of the solutions to this problem.

Another MCU with an updated or relatively new version of software or firmware can be used to replace MCU 903 even if the memory module fails due to software or firmware issues. However, receptacles, jumpers or connectors 901 may provide an option for addressing the aforementioned problems. For example, connector 901 may receive signals or commands to update software or firmware implemented in MCU 903 . Before updating, the electronic device (eg, personal computer, laptop, mobile phone, or the like) in which the memory module resides must be turned off or powered off to remove or unplug the memory module. Subsequently, the memory modules must be sent to the service provider for on-site updates. Turn off electronic devices and Sending the memory module may cause inconvenience to the user. In addition, the connector 901 occupying a relatively large space or area on the memory module (eg, the circuit layout of the electrical connection between the connector 901 and the MCU 903 ) may adversely affect the miniaturization of the memory module.

10: Internet connection

11: Update the firmware provider

110:Updated firmware

130: Busbar

131: Communication module

132: Central Processing Unit

133: Memory module

135:MCU

139: Motherboard

Claims (16)

A microcontroller unit (MCU) for a memory module, comprising: a processing unit; and a memory unit, wherein the memory unit is configured to include: an application section configured to store application data; and a boot loader section configured to store a computer code that, when executed by the processing unit, causes the MCU to: from an external central processing unit (CPU) ) receives a plurality of data blocks and a plurality of checksums; performs a first check mechanism according to the plurality of data blocks and the plurality of checksums associated with the data blocks to generate a plurality of first checksums in a firmware update stage a check result; and when the plurality of first check results are correct, entering an application mode from a boot loader mode by using the application data stored in the application section; wherein the external CPU The MCU is disposed on the same motherboard as the memory module, and the MCU receives the plurality of data blocks and the plurality of checksums from the external CPU through an interface of a module board of the memory module. The MCU of claim 1, wherein the memory unit is further configured to include: a data section configured to store an application checksum and information associated with the application data; When the computer code is executed by the processing unit, the MCU is further made to: check and execute a second check mechanism according to the application data in the application section and the application in the data section, so as to A second check result is generated in an initialization phase. The MCU of claim 2, wherein the information of the application data in the data section includes a size or an address of the application data in the application section. The MCU of claim 2, wherein the second check mechanism is checked and executed according to the application data in the application section and the application in the data section to generate the second check result in the initialization phase further It includes: entering an application program mode when the second check result is correct; and entering a boot loader mode when the second check result is incorrect. The MCU of claim 1, wherein the MCU is further caused to execute: when one of the plurality of first check results is incorrect, remain in the boot loader mode. A memory module, comprising: a module board with an interface; a plurality of volatile memory components arranged on the module board and electrically connected to an external central processing unit (CPU) through the interface; and a microcontroller unit (MCU) arranged on the module board to communicate with the external via the interface CPUs exchange data, wherein the external CPU and the memory module are located on the same motherboard, and the MCU is configured to: receive blocks of data and checksums from the external CPU in a bootloader mode , each of the plurality of data blocks is paired with a specified checksum from the plurality of checksums, wherein the plurality of data blocks and the plurality of checksums are retrieved by the external CPU from an updated firmware file ; check whether each of the plurality of data blocks corresponds to the specified checksum; and when each of the plurality of data blocks corresponds to the specified checksum, store in an application section by using to enter an application mode from the boot loader mode. The memory module of claim 6, wherein the MCU is configured to communicate with the external CPU via a system management bus (SMBus) or an inter-integrated circuit bus (IIC). The memory module of claim 7, further comprising a serial presence detection (SPD) unit in communication with the external CPU via the SMBus or the IIC. A method for updating a firmware of a microcontroller unit (MCU) of a memory module through an interface of a module board of the memory module and an external central processing unit (CPU) to The method includes: receiving an updated firmware file by the external CPU; executing the updated firmware file by the external CPU to obtain a plurality of data blocks and a plurality of data blocks associated with the plurality of data blocks a checksum; Receiving, by the MCU through the interface of the module board of the memory module, a first data block of the plurality of data blocks and the plurality of checksums assigned to the first data block from the external CPU a first checksum, wherein the external CPU and the memory module are arranged on the same motherboard; the MCU executes a check mechanism according to the first data block and the first checksum to generate a first check result; by the MCU according to the updated firmware file and a firmware check and executing a general check mechanism to generate a general check result; when the general check result indicates that the updated firmware file corresponds to the firmware check When and, update the firmware of the MCU through the updated firmware file by the MCU; and enter an application by the MCU using application data stored in an application section after updating the firmware program mode. The method of claim 9, further comprising: entering, by the MCU, a boot loader mode according to an instruction from the external CPU; wherein the first data block is received by the MCU in the boot loader mode and the first checksum. The method of claim 9, further comprising: when the first check result indicates that the first data block corresponds to the first checksum, receiving, by the MCU, a second data block of the plurality of data blocks and a second checksum of the plurality of checksums assigned to one of the second data blocks; and The checking mechanism is executed according to the second data block and the second checksum to generate a second check result. The method of claim 9, further comprising: receiving, by the MCU, the first data block of the plurality of data blocks when the first check result indicates that the first data block does not correspond to the first checksum and the first checksum among the plurality of checksums; and the MCU executes the check mechanism according to the first data block and the first checksum to regenerate the first check result. The method of claim 12, wherein receiving the first data block and the first checksum when the first check result indicates that the first data block does not correspond to the first checksum further comprises: when the first check result when indicating that the first data block does not correspond to the first checksum, by the MCU notifying the external CPU to resend the first data block and the first checksum assigned to the first data block; and by the The MCU receives the first data block and the first checksum. The method of claim 9, further comprising: receiving, by the MCU, a final data block of the plurality of data blocks and a final checksum of the plurality of checksums assigned to the final data block; and The check mechanism is executed according to the last data block and the last checksum to generate a last check result; when the last check result indicates that the last data block corresponds to the last checksum, by The MCU checks and executes the general check mechanism according to the updated firmware file and the firmware to generate the general check result. The method of claim 9, wherein the channel comprises a system management bus (SMBus) or an inter-integrated circuit bus (IIC). A method for initializing a microcontroller unit (MCU) as claimed in claim 2, the MCU being communicatively coupled with an external central processing unit (CPU) via the interface of the module board of the memory module, The method includes: by the MCU checking and executing the second checking mechanism according to the application data in the application section and the application in the data section to generate the second check result; when the first check When the second check result is correct, the MCU enters an application mode; when the second check result is incorrect, the MCU enters a boot loader mode; and when the MCU is in the boot loader mode , execute the method as in claim 9.

Images