Patent Publication Number: US-2021191709-A1

Title: Touch system and method for updating firmware

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     This application claims priority from Republic of Korea Patent Application No. 10-2019-0171570, filed on Dec. 20, 2019, which is hereby incorporated by reference in its entirety. 
     BACKGROUND 
     1. Field of Technology 
     The embodiment relates to a touch system and a method for updating firmware. 
     2. Description of the Prior Art 
     In general, various embedded systems such as digital cameras, smart phones, and the like, especially digital devices including touch functions, have a system operating program, which is called firmware, provided in a controller (e.g., a central processing unit (CPU)) and a memory unit. 
     These devices allow firmware to be updated from outside the device in order to expand a touch function and to troubleshoot problems. 
     In addition, the updating of the firmware by general users in digital devices has the advantage of reducing maintenance costs of manufacturers by allowing the users to solve the problems of the devices themselves. 
     However, since firmware is a program that directly affects system operation, the updating process thereof requires considerable care, and incomplete updating due to mistakes or accidents may cause a serious problem with malfunction of the device. 
     SUMMARY 
     An objective of the embodiment, in one aspect, is to provide a technique for eliminating errors that occur in firmware when updating the firmware. 
     In order to attain the above objective, an embodiment provides a touch system including: a processor; a first memory configured to store a first firmware and a second firmware for driving the processor in different storage areas; and a second memory to which the first firmware is uploaded by the processor, wherein the first firmware is configured to receive update-data for the first firmware from a host after being executed by the processor in the state of being uploaded to the second memory, store body data of the update-data in the first memory, and then store header data of the update-data in a blank section provided at the front of a memory section in which the body data is stored in the first memory. 
     The touch system may further include a touch driving circuit configured to supply a driving signal to a sensor electrode of the touch panel provided in an electronic device and receive a response signal to the driving signal from the sensor electrode, thereby generating touch data, and the first firmware executed by the processor may calculate touch coordinates on the touch panel on the basis of the touch data, and may provide the touch coordinates to the host. 
     The first firmware may verify validity of the body data after storing the body data in the first memory and, if the validity of the body data is proved, may store the header data in the first memory. 
     The first firmware may verify validity of the header data after storing the header data in the first memory and, if the validity of the header data is proved, may complete updating of the first firmware. 
     The first firmware may divide the body data into a plurality of data blocks, may sequentially store the same in the first memory, may verify the validity of one data block whenever one data block is stored in the first memory, and if the validity is proved for all of the plurality of data blocks, may store the header data in the first memory. 
     The touch system may further include a communication interface including a first communication interface configured to provide a communication path between the processor and the first memory, and a second communication interface configured to provide a communication path between the processor and the host. 
     The first firmware may temporarily store the update-data in the second memory, may configure a first address to an N th  address (N is a natural number), which belong to a range of addresses for a memory section storing the header data in the first memory, as a blank section, and may then store the body data in an (N+1) th  address of the first memory and in addresses subsequent thereto. 
     The second firmware may be uploaded to the second memory, and may be executed by the processor when an error occurs in the first firmware. 
     The second firmware may receive the update-data of the first firmware from the host, and may store the header data of the update-data in the first memory after storing the body data of the update-data in the first memory such that the header data is stored in a blank section provided at the front of the memory section in which the body data is stored. 
     A blank area corresponding to a predetermined memory section may be provided between the storage area of the first firmware and the storage area of the second firmware in the first memory. 
     In another embodiment, a method for updating firmware in a touch system provided in an electronic device may include: a data reception step of receiving update-data for the firmware from a host of the electronic device; a data temporary-storage step of temporarily storing the update-data in a second memory of the electronic device; a body data storage step of storing body data of the update-data in a first memory of the electronic device and verifying the validity of the body data; and a header data storage step of storing header data of the update-data in the first memory if the validity of the body data is proved. 
     In the header data storage step, the touch system may store the header data in a blank section provided at the front of the section in which the body data is stored in the first memory. 
     The body data storage step may include the steps of: dividing the body data temporarily stored in the second memory into a plurality of data blocks; sequentially storing the plurality of data blocks in the first memory while verifying validity of one data block whenever one data block is stored in the first memory; and verifying the validity for all of the plurality of data blocks. 
     The touch system may include: a touch driving circuit configured to supply a driving signal to a sensor electrode of a touch panel provided in the electronic device and receive a response signal to the driving signal from the sensor electrode, thereby generating touch data; and a touch device configured to receive the touch data from the touch driving circuit through the execution of the firmware and calculate touch coordinates on the touch panel on the basis of the touch data. 
     In the body data storage step, the validity of body data is verified using one or more of parity checking, cyclically redundancy checking (CRC), and checksum. 
     As described above, according to the embodiment, it is possible to normally complete updating of firmware by storing header data of update-data and verifying the validity thereof after storing body data thereof and verifying validity thereof in order to eliminate errors that may occur when updating firmware. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The above and other aspects, features, and advantages of the present disclosure will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: 
         FIG. 1  is a diagram illustrating the configuration of a touch system according to an embodiment; 
         FIG. 2  is a diagram illustrating an example of a data storage area of a first memory according to an embodiment; 
         FIGS. 3 to 5  are diagrams illustrating a process of updating firmware according to an embodiment; and 
         FIG. 6  is a flowchart illustrating a process of updating firmware in a touch system according to an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a diagram illustrating the configuration of a touch system according to an embodiment. 
     Referring to  FIG. 1 , a touch system  100  according to an embodiment may include a touch driving circuit  110 , a touch microcontroller unit (MCU)  120 , and a first memory  130 , which interwork with a touch panel  10  of an electronic device and a host  20 . Here, the host  20  may be the main controller of an electronic device. For example, if the electronic device is a mobile communication terminal, the host  20  may be an application processor of the mobile communication terminal, and if the electronic device is a monitor or a television (TV), the host  20  may be a multi-core processor of the monitor or the TV. 
     Meanwhile, the touch panel  10  may be bonded on an upper polarizing plate of a display panel (not shown), or may be formed between an upper polarizing plate and an upper substrate. In addition, in the case where the touch panel  10  is formed by an in-cell type, the touch panel  10  may be formed on a lower substrate together with a pixel array in the display panel (not shown). 
     The touch panel  10  may include sensor electrodes including driving electrodes and reception electrodes. 
     The touch driving circuit  110  supplies driving signals to sensor electrodes of the touch panel  10 . 
     In addition, the touch driving circuit  110  may receive response signals from the sensor electrodes, and may output touch data according to the response signals. 
     When an object such as a user&#39;s body or a touch pen approaches or touches a portion of the touch panel  10 , the difference in magnitude between the response signal corresponding to the portion of the touch panel  10  and the response signals of other portions thereof may increase. Thus, the touch driving circuit  110  may generate touch data on the object approaching or touching the portion of the touch panel  10  according thereto. 
     The touch MCU  120 , that is, a touch device, may calculate touch coordinates on the touch panel  10  using the touch data generated in the touch driving circuit  110 . 
     In addition, the touch MCU  120  may transmit the touch coordinates to the host  20 . 
     The touch MCU  120  may include a processor  122 , a second memory  124 , and a communication interface  126 . Here, the communication interface  126  may include a first communication interface  126   a  providing a communication path between the processor  122  and the first memory  130 , and a second communication interface  126   b  providing a communication path between the processor  122  and the host  20 . In addition, the second memory  124  may be volatile memory such as RAM (random access memory). 
     The processor  122  may receive touch data from the touch driver  110  through a third communication interface (not shown), may upload first firmware stored in the first memory  130 , which will be described below, to the second memory  124 , and may execute the same. 
     According to this, the touch MCU  120  may calculate touch coordinates on the touch panel  10  on the basis of the touch data, and may transmit the touch coordinates to the host  20  such that the electronic device may generate an event through the touch coordinates. 
     In other words, the first firmware may include a first algorithm for calculating touch coordinates on the touch panel  10  on the basis of the touch data. 
     Meanwhile, the first firmware may further include a second algorithm for managing updating of the first firmware. 
     Specifically, the first firmware executed by the processor  122  may receive update-data for the first firmware from the host  20 . Here, the first firmware may temporarily store the update-data in the second memory  124 . 
     In addition, the first firmware may store header data of the update-data after storing body data of the update-data in a first firmware storage area  220  of the first memory  130  as shown in  FIG. 2 . Here, the first firmware may store the header data in a blank section provided at the front of the memory section in which the body data is stored. A detailed description thereof will be given with reference to  FIGS. 3 to 5 . 
     Conventionally, only the validity of header data of update-data is verified after storing the header data in the first memory  130 , and if the validity of the header data is proved, body data is stored in the first memory  130  without verifying the validity thereof. Therefore, if errors occur in the body data when updating firmware, updating of the firmware is not normally completed. 
     In order to solve the problem, in an embodiment, header data is stored after body data is stored in the first memory  130 . Here, the first memory  130  may be nonvolatile memory such as flash memory. 
     In an embodiment, the first firmware, which is uploaded to the second memory  124  and is running, may verify the validity of body data after storing the body data in a first firmware storage area  220  of the first memory  130 , and, if the validity of the body data is proved (e.g., confirmed), may store header data in the first firmware storage area  220 . Here, the first firmware may delete existing first firmware stored in the first firmware storage area  220  before storing the body data in the first firmware storage area  220 . 
     When storing the body data in the first memory  130 , the first firmware may divide the body data into a plurality of data blocks, and may sequentially store the same in the first firmware storage area  220  of the first memory  130 , wherein the first firmware may verify the validity of one data block whenever one data block is stored in the first memory  130 . 
     If the validity is proved for all of the plurality of data blocks through the method described above, the first firmware may store header data in the first firmware storage area  220  of the first memory  130 . 
     Thereafter, the first firmware may verify the validity of the header data, and, if the validity of the header data is proved, may complete the updating of the first firmware. Here, since the first firmware is uploaded to the second memory  124  by the processor  122  and is running, existing first firmware stored in the first memory  130  may be updated. 
     In an embodiment, the first firmware may verify the validity of body data or the validity of header data using one or more of parity checking, cyclically redundancy checking (CRC), and checksum. 
     In an embodiment, when storing update-data in the first firmware storage area  220  of the first memory  130  as shown in  FIG. 2 , the firmware may configure a first address to an N th  address, which belong to the range of addresses for the memory section for storing header data in the first firmware storage area  220  of the first memory  130 , as a blank section, and may then store the body data temporally stored in the second memory  124  in an (N+1) th  address of the first firmware storage area  220  and in addresses subsequent thereto, as shown in  FIG. 3 . 
     In addition, if the validity of the body data is proved, the first firmware may store the header data, which is temporarily stored in the second memory  124 , in the blank section of the first firmware storage area  220  as shown in  FIG. 4 . 
     Thereafter, if the validity of the header data is proved through the verification of the validity thereof, the first firmware may complete the updating of the first firmware as shown in  FIG. 5 . 
     As described above, in an embodiment, it is possible to normally complete the updating of firmware by storing header data of update-data and verifying the validity thereof after storing body data thereof and verifying validity thereof in order to eliminate errors that may occur when updating firmware. 
     Meanwhile, in an embodiment, a second firmware, which is different from the first firmware, may be further stored in the first memory  130 , and when errors occur in the first firmware due to frequent execution of the first firmware or the like, the processor  122  may execute the second firmware so as to update the first firmware having errors into normal first firmware. 
     Specifically, in an embodiment, the first memory  130  may store the first firmware in the first firmware storage area  220 , and may store the second firmware in the second firmware storage area  240  as shown in  FIG. 2 . 
     Here, a boot loader stored in a boot loader storage area  210  causes the processor  122  to upload the first firmware stored in the first firmware area  122  to the second memory  124  and to execute the same when power is supplied to the electronic device including the touch system  100 . 
     In addition, when errors occur in the first firmware, the boot loader causes the processor  122  to upload the second firmware stored in the second firmware storage area  240  to the second memory  124  and to execute the same. 
     The first firmware stored in the first firmware storage area  220  may be the firmware for driving of the processor  122  in normal times. In other words, the first firmware may include a first algorithm for calculating touch coordinates on the touch panel  10  on the basis of touch data, and may further include a second algorithm for managing the updating of the first firmware. 
     Here, the first firmware storage area  220  may be a memory area in which read and write operations are possible. 
     The second firmware stored in the second firmware storage area  240  may be uploaded to the second memory  124  by the processor  122  when errors occur in the first firmware, and may be executed by the processor  122 , thereby receiving update-data for the first firmware from the host  20 . The second firmware storage area  240  may be a read-only memory area. 
     The second firmware may store header data of update-data in the first firmware storage area  220  of the first memory  130  after storing body data of the update-data in the first firmware storage area  220  such that the header data is stored in a blank section provided at the front of the memory section in which the body data is stored. 
     In other words, the second firmware may include a third algorithm for managing updating of the first firmware. In addition, the second firmware may further include a first algorithm for calculating touch coordinates on the touch panel  10  on the basis of touch data. 
     Here, the second firmware, like the first firmware, may verify the validity of body data after storing the body data in the first firmware storage area  220  of the first memory  130 , and, if the validity of the body data is proved, may store header data in the first firmware storage area  220 . Here, the second firmware may delete existing first firmware stored in the first firmware storage area  220  before storing the body data in the first firmware storage area  220 . 
     When storing the body data in the first firmware storage area  220 , the second firmware may divide the body data into a plurality of data blocks, and may sequentially store the same in the first firmware storage area  220  of the first memory  130  while verifying the validity of one data block whenever one data block is stored in the first memory  130 . 
     If the validity is proved for all of the plurality of data blocks through the method described above, the second firmware may store header data in the first firmware storage area  220  of the first memory  130 . 
     Thereafter, the second firmware may verify the validity of the header data, and, if the validity of the header data is proved, may complete the updating of the first firmware. 
     In an embodiment, when the second firmware stores update-data in the first firmware storage area  220  of the first memory  130  as shown in  FIG. 2 , the second firmware may configure a first address to an N th  address, which belong to the range of addresses for the memory section for storing header data in the first firmware storage area  220  of the first memory  130 , as a blank section, and may then store the body data in an (N+1) th  address of the first firmware storage area  220  and in addresses subsequent thereto, as shown in  FIG. 3 . 
     In addition, if the validity of the body data is proved, the second firmware may store the header data in the blank section of the first firmware storage area  220  as shown in  FIG. 4 . 
     As described above, in an embodiment, first firmware for driving of the processor  122  in normal times and second firmware for driving of the processor  122  in the case where errors occur in the first firmware are stored in the first memory  130 , respectively, and even if errors occur in the first firmware, the first firmware may be updated through the second firmware. 
     If the size of data on the first firmware becomes more than the existing size thereof when updating the first firmware, the update-data of the first firmware may be stored to exceed the first firmware storage area  220 . Therefore, a blank area  230  corresponding to a specific memory section may be provided between the first firmware storage area  220  and the second firmware storage area  240  in the first memory  130 . In other words, when allocating the memory sections of the first memory  130 , the blank area  230  may be allocated between the first firmware storage area  220  and the second firmware storage area  240 . 
     Hereinafter, a process of updating firmware in the touch system  100  will be described. 
       FIG. 6  is a flowchart illustrating a process of updating firmware in a touch system according to an embodiment. 
     Referring to  FIG. 6 , a first firmware, which is uploaded from the first memory  130  to the second memory  124  by the processor  122  of the touch MCU  120  and is executed, may receive update-data of the first firmware from the host  20  (S 610 ). Here, the host  20  may receive update-data of the first firmware from an external server through a wired/wireless communication module provided in an electronic device, or may receive update-data of the first firmware from an external memory (e.g., USB memory, etc.) connected to the electronic device, thereby transmitting the update-data to the touch system  100 . 
     The first firmware may temporarily store the update-data in the second memory  124  such as random access memory (RAM) (S 620 ). 
     In addition, the first firmware may store body data of the update-data in the first firmware storage area  220  of the first memory  130 , and may verify the validity of the body data (S 630 ). Here, the first firmware may divide the body data temporarily stored in the second memory  124  into a plurality of data blocks, and may sequentially store the plurality of data blocks in the first firmware storage area  220  of the first memory  130 . In addition, the first firmware may verify the validity of one data block whenever one data block is stored in the first memory  130 . Accordingly, the validity may be verified and proved for of all of the plurality of data blocks. 
     Before step S 630 , the first firmware may delete existing first firmware stored in the first firmware storage area  220 . 
     Before step S 630 , the first firmware may configure a first address to an N th  address, which belong to the range of addresses for the memory section for storing header data in the first firmware storage area  220  of the first memory  130 , as a blank section as shown in  FIG. 3 , and may then store the body data temporally stored in the second memory  124  in an (N+1) th  address of the first firmware storage area  220  and in addresses subsequent thereto. 
     Meanwhile, if the validity of the body data is proved, the first firmware may store header data in the first firmware storage area  220 , and may verify the validity of header data (S 640  and S 650 ). If the validity of the body data is not proved in step S 640 , the first firmware may delete the body data stored in the first firmware storage area  220 , and may then store again the body data, which is temporally stored in the second memory  124 , in the first firmware storage area  220 , thereby reverifying the validity of the body data. 
     If the validity of the header data is proved, the first firmware may complete the updating of the first firmware (S 660 ). If the validity of the header data is not proved in step S 650 , the first firmware may delete the header data stored in the first firmware storage area  220 , and may then store the header data, which is temporally stored in the second memory  124 , in the first firmware storage area  220  again, thereby reverifying the validity thereof. 
     In an embodiment, the first firmware may verify the validity of body data or the validity of header data using one or more of parity checking, cyclically redundancy checking (CRC), and checksum.