Output method for memory anti-overflow protection based on 32-bit single-chip microcomputer firmware upgrade

Abstract

The invention discloses an output method based on 32-bit single-chip microcomputer firmware upgrade memory anti-overflow protection, and relates to the field of single-chip microcomputer memory anti-overflow protection, and the method specifically comprises the following operation steps: S1, environment variable configuration and management; s2, performing core execution of the Python automatic script; s3, performing anti-overflow protection on the memory; and S4, cleaning redundant files and environment variables. According to the output method based on the 32-bit single-chip microcomputer firmware upgrade memory anti-overflow protection, the file path is defined as the environment variable and stored in the independent configuration file in a centralized mode, complete separation of the path and script logic is achieved, the non-transplantable problem caused by a hard coding path is avoided, meanwhile, the adaptation cost in different environments is reduced, and the adaptation efficiency is improved. Operators do not need to modify script codes and only need to adjust configuration files to complete deployment.

Description

Technical Field

[0001] This invention relates to the field of microcontroller memory overflow protection, and particularly to an output method for memory overflow protection based on firmware upgrade of a 32-bit microcontroller. Background Technology

[0002] In the field of medical equipment, 32-bit microcontrollers, with their high-efficiency computing power and stable control performance, have become the core control unit of precision equipment such as urine analyzers. Urine analyzers require firmware to control key functions such as sample detection, data processing, and result output, and firmware upgrades are a crucial means of optimizing performance, fixing vulnerabilities, and expanding functionality throughout the device's lifecycle. Currently, firmware upgrades for 32-bit microcontrollers on the market generally rely on bootloaders. While this method offers a certain degree of reliability and compatibility, in practical applications, especially for medical equipment like urine analyzers that have extremely high requirements for stability and automation, it exposes many unavoidable problems, seriously affecting the efficiency and security of firmware upgrades, and also bringing additional costs and risks to the production and maintenance of the equipment.

[0003] First, the development and maintenance of the BootLoader program has an extremely high barrier to entry. Developing a BootLoader requires engineers to be proficient in the microcontroller's low-level hardware initialization logic, data transmission protocols (such as SPI, I2C, USART, etc.), and Flash storage control mechanisms. This not only consumes a significant amount of development time but also places stringent demands on the professional skills of technical personnel. More importantly, if the BootLoader program itself has defects (such as initialization logic errors or data verification vulnerabilities), it will directly cause the microcontroller to fail to start normally, thus causing the urine analyzer to freeze and be unable to complete sample testing, disrupting the normal diagnostic and treatment processes of medical institutions.

[0004] Secondly, in traditional firmware upgrade processes, the code merging operation relying on J-FLASH software is entirely manual, with extremely low automation. Operators must manually select the BootLoader file and the main application (APP) file, set merging parameters and output paths. Any human error at any step in this process (such as selecting the wrong file path or setting an incorrect address range) will lead to data loss, address corruption, and other problems in the output firmware file. Using such problematic files for firmware upgrades of urine analyzers can result in upgrade failure at best, and damage to the device's original control program at worst, causing malfunctions and increasing after-sales maintenance costs.

[0005] Therefore, it is necessary to propose an output method based on 32-bit microcontroller firmware upgrade memory overflow protection to solve the above problems. Summary of the Invention

[0006] The main objective of this invention is to provide an output method for preventing memory overflow during firmware upgrades based on 32-bit microcontrollers, which can effectively solve the problems in the background art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: The output method for memory overflow protection based on 32-bit microcontroller firmware upgrade includes the following steps: S1: Environment variable configuration and management. By using unified variable definitions, hard-coded paths in traditional scripts are replaced, avoiding script refactoring due to path modifications, and facilitating parameter adaptation in different environments. S2: The core execution of Python automation scripts, which calls two dedicated scripts, hexmerge.py and hex2bin.py, to complete the merging of HEX files and the format conversion from HEX to BIN files, respectively; S3: Memory overflow protection. Through a triple mechanism of hard address range constraint, active overflow detection, and non-upgrade space initialization, a full-link memory overflow protection system is built to ensure that the firmware file meets the flash storage requirements of the microcontroller. S4: Cleaning up redundant files and environment variables. Through the designed process of cleaning up redundant files and environment variables, the host computer environment is kept clean, and interference from redundant data is avoided.

[0008] Preferably, step S1 specifically includes the following steps: S101: Rules for defining environment variables. In the Windows operating system environment, environment variables are defined through batch commands and script configuration files. The variable value must explicitly point to the absolute path of the file, and the folder name and file name in the path must be exactly the same as the actual storage situation to avoid the script being unable to recognize the file due to name differences; S102: Environment variable verification mechanism. The verification process is automatically executed by a script to ensure that all files corresponding to the variables meet the requirements for subsequent processing. The verification process consists of three steps: The first step is path validity verification. The script checks whether the path pointed to by the environment variable exists using a file existence detection command. The second step is file format verification. The script reads the header information of the file pointed to by the environment variable to determine whether the file is in standard HEX format. The third step is file integrity verification. The script calculates the checksum of the HEX file and compares it with the checksum stored at the end of the file. If the two are inconsistent, it means that the file has suffered data loss or corruption during transmission and storage. S103: Environment variable maintenance and adaptation, used to define environment variables centrally in a separate configuration file to separate variables from script logic.

[0009] Preferably, step S2 specifically includes the following steps: S201: HEX file merging processing, used to merge the BootLoaderHEX file and the APPHEX file into a complete HEX file, namely MERGER_HEX, according to the address allocation rules of the 32-bit microcontroller Flash of the urine analyzer. At the same time, it ensures that the two files do not overlap in the Flash address space to avoid data conflicts that may cause firmware upgrade failure. S202: HEX file to BIN file processing, used to convert the merged MERGER_HEX file and the separate APP_HEX file into BIN files, namely MERGER_BIN and APP_BIN, respectively, removing redundant format characters, reducing file size, and adapting to the programming requirements of the 32-bit microcontroller of the urine analyzer.

[0010] Preferably, step S201 also includes logging of the merging process, which is used by operators to monitor the merging progress and troubleshoot problems. The script will record detailed logs in real time during the merging process. The log content includes execution time, current operation, files involved, address range and execution result.

[0011] Preferably, step S3 specifically includes the following steps: S301: Hard constraint on address range. Throughout the entire process of merging and converting HEX files, the writable address range of the 32-bit microcontroller Flash of the urine analyzer is always used as a hard constraint. All file processing operations are strictly limited to this range to eliminate the risk of address overflow from the source. During the HEX file merging process, the "-r"08000000:0807FFFF"" parameter forces the merged MERGER_HEX file to retain only data within this address range, and any redundant data outside this range is automatically removed by the script. At the same time, dedicated address ranges are specified for APP_HEX and BOOT_HEX respectively, and the two ranges have no overlap, ensuring that the BootLoader and APP are stored independently in Flash and that data is not overwritten due to address overlap. S302: Active Overflow Detection. Through the built-in overflow detection function of the script, it actively identifies whether there is an address in the MDK output file that exceeds the Flash writable range, and checks for potential problems in advance before the file enters the merging and conversion process. S303: Non-upgrade space initialization. Before generating the BIN file, the script initializes the data in the non-upgrade space of the microcontroller Flash, clearing residual old data, redundant code, and error messages to avoid conflicts with the new firmware. The specific process of initialization is as follows: When the script generates the MERGER_BIN file, it will automatically identify the address range of the non-upgrade space, and write 0xFF, which is the default value after the microcontroller Flash is erased, to all addresses in the range, overwriting the original residual data.

[0012] Preferably, step S4 specifically includes the following steps: S401: Redundant file cleanup logic. Redundant file cleanup follows the principle of verification before deletion. Before deleting a file, the script will first confirm that the subsequent process corresponding to the target file has been completed and that the file is unnecessary to keep, so as to avoid accidentally deleting files that are still needed. S402: Environment variable cleanup logic. The purpose of cleaning up environment variables is to avoid conflicts between the variables defined in this method and the environment variables of other programs in the system, and to release system resources. The cleanup process is executed after the redundant files are cleaned up. The script uses the command "set variable name=" to clear the values ​​of each environment variable so that they no longer occupy system environment variable resources.

[0013] Compared with the prior art, the present invention provides an output method for preventing memory overflow during firmware upgrades based on 32-bit microcontrollers, which has the following beneficial effects: 1. This output method for memory overflow protection during 32-bit microcontroller firmware upgrades achieves complete separation of path and script logic by defining file paths as environment variables and storing them centrally in an independent configuration file. This avoids the non-portability issues caused by hard-coded paths and reduces adaptation costs in different environments. Operators do not need to modify the script code; they only need to adjust the configuration file to complete the deployment.

[0014] 2. This output method for memory overflow protection during firmware upgrades based on 32-bit microcontrollers integrates the entire process of environment variable verification, HEX file merging, HEX to BIN file conversion, memory overflow detection, and redundancy cleanup without manual intervention. This reduces human error and significantly shortens firmware file generation time. Detailed log recording ensures process traceability and rapid problem troubleshooting.

[0015] 3. This output method for preventing memory overflow during firmware upgrades based on 32-bit microcontrollers constructs a triple protection mechanism consisting of hard address range constraints, active overflow detection, and initialization of non-upgrade space. This eliminates risks such as address overflow, data conflicts, and residual data interference from the source, ensuring that the output firmware file fully complies with the storage requirements of 32-bit microcontroller Flash and that the upgrade process is safe and stable.

[0016] 4. This output method based on 32-bit microcontroller firmware upgrade memory overflow protection is implemented solely through a host computer script. It does not require modification of the microcontroller's BootLoader or APP code, thus avoiding the introduction of new vulnerabilities due to code modification. At the same time, it is compatible with the existing hardware architecture of urine analyzers and can be deployed without replacing hardware, lowering the application threshold. Attached Figure Description

[0017] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0018] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0019] like Figure 1 As shown, the output method for memory overflow protection during firmware upgrade of a 32-bit microcontroller includes the following steps: S1: Environment variable configuration and management. This replaces hard-coded paths in traditional scripts with unified variable definitions, avoiding script refactoring due to path modifications and facilitating parameter adaptation in different environments. Specifically, it includes the following steps: S101: Rules for defining environment variables. In the Windows operating system environment, environment variables are defined through batch commands and script configuration files. The variable value must explicitly point to the absolute path of the file, and the folder name and file name in the path must be exactly the same as the actual storage situation to avoid the script being unable to recognize the file due to name differences. Taking the definition of APP_HEX as an example, its value is set to "C:\Users\gd32_urine\USER\OBJ\UrineAnalyzer.hex". The setting of this path follows the following logic: First, "C:\Users\gd32_urine" is the dedicated user directory for the microcontroller development project of the urine analyzer, avoiding confusion with files from other projects; second, "USER\OBJ" is the default output folder of the MDK compilation software. After MDK compiles the APP code, it will automatically store the generated HEX file in this directory, eliminating the need to manually move the file and reducing human intervention; finally, "UrineAnalyzer.hex" is the fixed name of the APP file. This name corresponds to the device model of the urine analyzer, making it easy for operators to quickly identify the purpose of the file and avoiding confusion with firmware files from other devices. Similarly, the path to BOOT_HEX is defined as "C:\Users\gd32_urine\IAP_Bootloader\OBJ\IAP.hex", where "IAP_Bootloader\OBJ" is the compilation output directory of the BootLoader program, and "IAP.hex" is the fixed name of the BootLoader file; the path to MERGER_HEX is defined as "C:\Users\gd32_urine\USER\OBJ\urine_merge.hex", storing the merged HEX file in the same output directory as the APP file. Recording facilitates subsequent unified management and conversion; the path of APP_BIN is defined as "C:\Users\gd32_urine_analyzer_firmware\gd32_urine\USER\OBJ\ECG_APP.bin", and the path of MERGER_BIN is defined as "C:\Users\gd32_urine\USER\OBJ\urine_merge.bin". Both follow the principle of "being in the same directory as the corresponding HEX file" to ensure that the script can quickly locate the input file when converting the format, and at the same time, it is convenient for operators to find the output BIN file; S102: Environment variable verification mechanism. The script automatically executes the verification process to ensure that all files corresponding to the variables meet the requirements for subsequent processing. The verification process consists of three steps: The first step is path validity verification. The script checks whether the path pointed to by the environment variable exists using a file existence check command. For example, for APP_HEX, the script will check whether "C:\Users\gd32_urine\USER\OBJ\UrineAnalyzer.hex" exists. If it does not exist, the script will immediately output an error message (such as "Error: The file pointed to by APP_HEX does not exist. Please check if the path is correct. Path: C:\Users\gd32_urine\USER\OBJ\UrineAnalyzer.hex") and stop subsequent operations to avoid the merging and conversion steps having no input files available due to missing files. The second step is file format verification. The script will read... The script retrieves the header information of the file pointed to by the environment variable to determine if the file is in standard HEX format. For example, it checks if the file starts with ":" (the standard start character for HEX files). If a non-HEX format file is detected (e.g., a TXT file is mistakenly set as APP_HEX), the script will output "Error: The file pointed to by APP_HEX is not in standard HEX format. Please replace it with the correct file." This prevents incorrectly formatted files from entering subsequent processes, which could lead to merging or conversion failures. The third step is file integrity verification. The script calculates the checksum of the HEX file and compares it with the checksum stored at the end of the file. If the two are inconsistent, it indicates that data loss or corruption occurred during transmission or storage. The script will output "Error: The integrity verification of the file pointed to by APP_HEX failed. The file may be corrupted. Please retrieve the file again." This ensures that the HEX file data entering subsequent processes is complete and avoids microcontroller malfunctions after firmware upgrades due to file corruption. S103: Environment variable maintenance and adaptation, used to define environment variables centrally in an independent configuration file (such as "firmware_config.bat"), to separate variables from script logic, greatly reducing maintenance difficulty and adaptation costs in different environments. When deploying this method on multiple computers in the production workshop, operators do not need to modify the core script code, but only need to modify the environment variable values ​​in the configuration file according to the actual file storage path of each computer. For example, the storage path of the urine analyzer APP file on the computer in workshop A is "C:\Users\gd32_urine1\USER\OBJ\UrineAnalyzer.hex", and the storage path on the computer in workshop B is "C:\Users\gd32_urine2\USER\OBJ\UrineAnalyzer.hex". In this case, you only need to modify the value of APP_HEX to the corresponding path in the "firmware_config.bat" of both computers. The core scripts (such as the merge script and the conversion script) can directly call the variables in the configuration file without any modification. This "configuration and logic separation" design not only avoids the code non-portability problem caused by hard-coded paths, but also reduces the risk of introducing errors due to modifying the script code. At the same time, it is convenient to update variables uniformly in the future (such as when changing the output directory, you only need to modify the MERGER_HEX path in all configuration files in batches, without modifying the script on each computer).

[0020] S2: The core execution of the Python automation script, which calls two dedicated scripts, hexmerge.py and hex2bin.py, to complete the merging of HEX files and the format conversion from HEX to BIN files, respectively. Specifically, it includes the following steps: S201: HEX file merging processing, used to merge the BootLoaderHEX file and the APPHEX file into a single complete HEX file, namely MERGER_HEX, according to the address allocation rules of the 32-bit microcontroller Flash of the urine analyzer. This ensures that the two files do not overlap in the Flash address space, avoiding data conflicts that could lead to firmware upgrade failures. Specifically, this includes: The method calls and sets parameters for the merge script. It calls the Python 2.7 interpreter to execute the `hexmerge.py` script. The reason for choosing Python 2.7 is that in the current research and production environment of urine analyzers, some supporting tools (such as MDK plugins and Flash programming tools) are still developed based on Python 2.7. Choosing this version ensures the script's compatibility with the existing toolchain and avoids script execution errors due to version incompatibility. The complete format of the command is: "C:\Python27\python.exe C:\Python27\Scripts\hexmerge.py -o %MERGER_HEX% -r "08000000:0807FFFF" --overlap=error %APP_HEX%:08004000:0807FFFF %BOOT_HEX%:08000000:08003FFF". In this command, each parameter performs a specific function, and the parameter settings strictly match the Flash address allocation logic of the 32-bit microcontroller of the urine analyzer. “C:\Python27\python.exe”: Explicitly specifies the path to the Python 2.7 interpreter, ensuring that the script calls the correct interpreter and avoiding interpreter errors caused by having multiple Python versions installed on the system; “C:\Python27\Scripts\hexmerge.py”: Specifies the path to the hexmerge.py script, which is a utility script specifically for merging HEX files. It supports custom address ranges, overlap handling strategies, and other functions, and can meet the merging accuracy requirements of this method. "-o%MERGER_HEX%": The "-o" parameter specifies the path to the output file after merging. "%MERGER_HEX%" is an environment variable defined earlier. The script will automatically read the value of this variable and store the merged HEX file in the preset path. There is no need to manually enter the output path, reducing manual operation. "-r"08000000:0807FFFF"": The "-r" parameter specifies the effective memory address range of the merged file. This range is completely consistent with the writable address range of the 32-bit microcontroller Flash of the urine analyzer (0x08000000 to 0x0807FFFF). The script will automatically remove all data outside this range to ensure that the merged file contains only valid data that can be stored in the microcontroller Flash, avoiding invalid data occupying storage space or causing address overflow. "--overlap=error": This parameter is a key protection mechanism to prevent address overlap. During the merging process, the script will detect whether there is any overlap between the address ranges of APP_HEX and BOOT_HEX in real time. If an overlap is detected (e.g., the address range of APP_HEX is mistakenly set to 08003000:0807FFFF, which overlaps with the address range of BOOT_HEX 08000000:08003FFF), the script will stop execution immediately and output detailed overlap information (e.g., "Error: APP_HEX and BOOT_HEX are found to overlap in the address range 08003000:08003FFF. Please adjust the address range and re-execute"). This avoids address conflicts in the merged file and prevents new data from overwriting old data during firmware upgrades, which could cause the BootLoader or APP to malfunction. "%APP_HEX%:08004000:0807FFFF": Specifies the APP_HEX file and its corresponding Flash address range. The range 0x08004000 to 0x0807FFFF is the dedicated address space allocated to the APP by the 32-bit microcontroller of the urine analyzer. This space is large enough to meet the functional requirements of the APP (such as sample detection algorithms, data processing modules, result display control, etc.) and is completely isolated from the address space of the BootLoader. "%BOOT_HEX%:08000000:08003FFF": Specifies the BOOT_HEX file and its corresponding Flash address range. 0x08000000 to 0x08003FFF is the BootLoader's dedicated address space, which is located at the beginning address of the Flash. This ensures that the BootLoader program is executed first after the microcontroller is powered on, to complete hardware initialization, upgrade detection and other operations, and then jumps to the APP address space to execute the main program. It also includes logging of the merge process, which is used by operators to monitor the merge progress and troubleshoot problems. The script will record detailed logs in real time during the merge process. The log content includes execution time, current operation, files involved, address range and execution result. S202: HEX file to BIN file conversion, used to convert the merged MERGER_HEX file and the individual APP_HEX file into BIN files, namely MERGER_BIN and APP_BIN, respectively. Redundant format characters are removed, reducing file size and adapting to the programming requirements of 32-bit microcontrollers in urine analyzers. Specifically, it includes: The conversion script is invoked and its parameters are set: The Python 2.7 interpreter is invoked to execute the hex2bin.py script, which is specifically designed for converting HEX files to BIN files. It supports conversion within a specified address range, ensuring that the converted BIN file contains only valid data within the target address range. The conversion command for APP_HEX files is: "C:\Python27\python.exe C:\Python27\Scripts\hex2bin.py -r "08004000:0807FFFF"%APP_HEX%%APP_BIN%"; the conversion command for MERGER_HEX files is: "C:\Python27\python.exe C:\Python27\Scripts\hex2bin.py -r "08000000:0807FFFF"%MERGER_HEX%%MERGER_BIN%"; The parameter settings for both commands are logically consistent and maintain the same address range as when merging HEX files, ensuring data consistency and accuracy. "C:\Python27\python.exe" and "C:\Python27\Scripts\hex2bin.py": These specify the paths to the Python 2.7 interpreter and the hex2bin.py script, respectively, ensuring compatibility with the merged script's calling logic. "-r"08004000:0807FFFF"" (APP_HEX conversion) and "-r"08000000:0807FFFF"" (MERGER_HEX conversion): The "-r" parameter specifies the address range for conversion. This range is exactly the same as the address range used when merging HEX files. The script will only extract data within this range for conversion and remove invalid data outside the range to ensure that the size of the converted BIN file is minimized, while avoiding memory usage issues caused by invalid data entering Flash. "%APP_HEX%" and "%MERGER_HEX%": These are the paths to the HEX files that are entered. They are accessed through environment variables and do not need to be entered manually, ensuring the accuracy of the paths. "%APP_BIN%" and "%MERGER_BIN%" are the output BIN file paths, respectively. They are also called through environment variables to ensure that the output file is stored in the preset path for easy subsequent flashing operations. It also includes verification and logging of the conversion process. To ensure the accuracy of the converted BIN file data and its usability for firmware upgrades, the script performs dual verification after conversion: First, file size verification. The script calculates the theoretical file size based on the address range being converted (e.g., if the address range for APP_HEX is 08004000:0807FFFF, and the address span is 0x7C000 (i.e., 507904 bytes), then the theoretical BIN file size should be 507904 bytes), and compares it with the actual generated APP_BIN file size. If the two are inconsistent, it indicates that data loss occurred during the conversion process, and the script will output "Error: APP_BIN file too large". The script performs a second check: First, it reads data from a specified address range in the HEX file and compares it with the corresponding offset data in the converted BIN file (e.g., data at address 08004000 in the HEX file corresponds to byte 0 of the BIN file). If inconsistencies are found, the script outputs "Error: APP_BIN file data is inconsistent with APP_HEX file data. HEX data at address 08004000 is 0x12, BIN data is 0x34. Please re-execute the conversion." This ensures that the BIN file data and HEX file data are completely consistent. At the same time, the conversion process will also generate detailed logs. The log files are named in the format "hex2bin_log_YYYYMMDD_HHMMSS.txt" (e.g., "hex2bin_log_20240520_094000.txt") and stored in the directory of the corresponding BIN file. The log content includes execution time, input and output file paths, conversion address range, file size, verification results, etc.

[0021] S3: Memory overflow protection. Through a triple mechanism of hard address range constraints, proactive overflow detection, and non-upgrade space initialization, a full-link memory overflow protection system is constructed to ensure that the firmware file meets the microcontroller's Flash storage requirements. Specifically, it includes the following steps: S301: Hard constraint on address range. Throughout the entire process of merging and converting HEX files, the writable address range of the 32-bit microcontroller Flash of the urine analyzer (08000000:0807FFFF) is always used as a hard constraint. All file processing operations are strictly limited to this range to eliminate the risk of address overflow from the source. During the HEX file merging process, the "-r"08000000:0807FFFF"" parameter forces the merged MERGER_HEX file to retain only data within this address range, and any redundant data outside this range is automatically removed by the script. At the same time, dedicated address ranges (08004000:0807FFFF and 08000000:08003FFF) are specified for APP_HEX and BOOT_HEX respectively, and the two ranges have no overlap, ensuring that the BootLoader and APP are stored independently in Flash and that data is not overwritten due to address overlap. In the HEX to BIN file conversion stage, the "-r" parameter of the conversion script is completely consistent with the address range of the merging stage, further ensuring that the converted BIN file only contains data within the Flash writable range, avoiding invalid data from entering the burning process. This hard constraint on the address range of the entire "merge-conversion" process is equivalent to setting up an "address firewall" for the firmware file. Any data exceeding the Flash capacity cannot enter the final BIN file, fundamentally avoiding firmware upgrade failures caused by address overflow. S302: Active Overflow Detection. The script proactively identifies whether the MDK output files (APP_HEX, BOOT_HEX) have addresses exceeding the Flash writable range using its built-in overflow detection function. This proactively checks for potential issues before the files enter the merging and conversion process. Specifically, the script reads the address information of all data records in the HEX file, extracts the maximum address value, and compares it with the maximum address in the Flash writable range (0807FFFF). If the maximum address value exceeds 0807FFFF, it is determined to be an "address overflow." Simultaneously, the script calculates the code size of APP_HEX and BOOT_HEX (i.e., the number of bytes corresponding to the address range span) and compares it with the size of their respective allocated address spaces. If the code size exceeds the allocated space, it is determined to be a "volume overflow." For example, if the maximum address value of APP_HEX is 08080000 (exceeding 0807FFFF), the script will output "Error: APP_HEX file has an address overflow, the maximum address 08080000 exceeds the Flash writable range (08004000:0807FFFF), please optimize the APP code size or expand the Flash capacity"; if the code size of APP_HEX is 512000 bytes, and the size corresponding to its allocated address space (08004000:0807FFFF) is 507904 bytes, the script will output "Error: APP_HEX file has a size overflow, the code size of 512000 bytes exceeds the allocated space of 507904 bytes, please simplify the code"; Overflow detection is performed after environment variable verification and before file merging. If an overflow problem is detected, the script will immediately stop subsequent operations, output detailed overflow information, and guide operators to solve the problem by optimizing the code (such as deleting redundant functional modules, simplifying algorithms), adjusting address allocation, or expanding Flash capacity, so as to prevent files with overflow risks from entering the subsequent process and further ensure the security of firmware files. S303: Non-upgrade space initialization. Before generating the BIN file, the script initializes the data in the non-upgrade space of the microcontroller Flash, clearing residual old data, redundant code, and error messages to avoid conflicts with the new firmware. The definition of non-upgrade space is: the space outside the BootLoader address space (08000000:0807FFFF) and APP address space (08004000:0807FFFF) in the Flash writable range (08000000:08003FFF) (if it exists), as well as the space outside the Flash writable range that may contain residual data. In the application scenario of 32-bit microcontrollers in urine analyzers, non-upgrade space is usually the reserved area in Flash that has not been allocated to the BootLoader and APP, or the area containing residual data after previous firmware upgrades. The specific initialization process is as follows: When generating the MERGER_BIN file, the script will automatically identify the address range of the non-upgrade space and write 0xFF to all addresses within this range, which is the default value after the microcontroller's Flash is erased, overwriting the original residual data. For example, if the Flash writable range is 08000000:0808FFFF (exceeding the 0807FFFF set by this method), then the non-upgrade space is 08080000:0808FFFF. The script will write 0xFF to the offset area corresponding to this address range in the MERGER_BIN file to ensure that there is no old data residue in this area.

[0022] S4: Cleaning up redundant files and environment variables. Through a designed process for cleaning up redundant files and environment variables, a cleanup environment for the host computer is ensured, avoiding interference from redundant data. This includes the following steps: S401: Redundant file cleanup logic. Redundant file cleanup follows the principle of verification before deletion. Before deleting a file, the script will first confirm that the subsequent process corresponding to the target file has been completed and that the file is unnecessary to keep, so as to avoid accidentally deleting files that are still needed. The specific cleanup steps are as follows: First, verify whether the MERGER_BIN file was successfully generated. The script checks for file existence and size to confirm that the MERGER_BIN exists and its size matches the theoretical value. If the check passes, it means that the MERGER_HEX has been successfully converted to MERGER_BIN, and the MERGER_HEX is no longer needed. The script then executes the command "del%MERGER_HEX%" to delete the MERGER_HEX. If the check fails (e.g., the MERGER_BIN was not generated or its size is abnormal), the script will retain the MERGER_HEX and output "Warning: MERGER_BIN generation is abnormal. MERGER_HEX will not be deleted for now. It is recommended to check the conversion log." This facilitates subsequent analysis of the conversion failure by the operator using M... The first step is to test ERGER_HEX. The second step is to determine whether to delete APP_BIN based on the actual upgrade requirements. If the urine analyzer firmware upgrade only requires MERGER_BIN (the complete firmware including the BootLoader and APP), then after confirming successful MERGER_BIN generation, execute the command "del%APP_BIN%" to delete APP_BIN. If only the APP needs to be upgraded (using only APP_BIN), then retain APP_BIN and do not perform the deletion operation. The third step is to clean up temporary files other than log files, such as cache files and error report files (non-log files) generated during script execution, ensuring that the directories containing MERGER_BIN and APP_BIN only contain core firmware files and log files for easy access and management by operators. During the cleanup process, the script will record detailed cleanup logs. S402: Environment variable cleanup logic. The purpose of cleaning up environment variables is to avoid conflicts between the variables defined in this method (APP_HEX, BOOT_HEX, MERGER_HEX, APP_BIN, MERGER_BIN) and the environment variables of other programs in the system, and to release system resources. The cleanup process is executed after the redundant files are cleaned up. The script uses the command "set variable name=" to clear the values ​​of each environment variable so that they no longer occupy system environment variable resources. After the cleanup is complete, the script will perform environment variable verification. It will use commands such as "echo %APP_HEX%" to confirm that the values ​​of each variable are empty. If there are any variables that have not been cleared, the script will output "Warning: APP_HEX environment variable has not been cleared, which may pose a risk of conflict. Please clean it manually" and prompt the operator to manually delete the residual variables through the system's "Environment Variables" settings interface to ensure that there is no redundancy in the system environment variables.

[0023] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. An output method for preventing memory overflow during firmware upgrades of 32-bit microcontrollers, characterized in that: The following steps are included: S1: Environment variable configuration and management. By using unified variable definitions, hard-coded paths in traditional scripts are replaced, avoiding script refactoring due to path modifications, and facilitating parameter adaptation in different environments. S2: The core execution of Python automation scripts, which calls two dedicated scripts, hexmerge.py and hex2bin.py, to complete the merging of HEX files and the format conversion from HEX to BIN files, respectively; S3: Memory overflow protection. Through a triple mechanism of hard address range constraint, active overflow detection, and non-upgrade space initialization, a full-link memory overflow protection system is built to ensure that the firmware file meets the flash storage requirements of the microcontroller. S4: Cleaning up redundant files and environment variables. Through the designed process of cleaning up redundant files and environment variables, the host computer environment is kept clean, and interference from redundant data is avoided.

2. The output method for preventing memory overflow during firmware upgrade based on a 32-bit microcontroller as described in claim 1, characterized in that: S1 specifically includes the following steps: S101: Rules for defining environment variables. In the Windows operating system environment, environment variables are defined through batch commands and script configuration files. The variable value must explicitly point to the absolute path of the file, and the folder name and file name in the path must be exactly the same as the actual storage situation to avoid the script being unable to recognize the file due to name differences; S102: Environment variable verification mechanism. The verification process is automatically executed by a script to ensure that all files corresponding to the variables meet the requirements for subsequent processing. The verification process consists of three steps: The first step is path validity verification. The script checks whether the path pointed to by the environment variable exists using a file existence detection command. The second step is file format verification. The script reads the header information of the file pointed to by the environment variable to determine whether the file is in standard HEX format. The third step is file integrity verification. The script calculates the checksum of the HEX file and compares it with the checksum stored at the end of the file. If the two are inconsistent, it means that the file has suffered data loss or corruption during transmission and storage. S103: Environment variable maintenance and adaptation, used to define environment variables centrally in a separate configuration file to separate variables from script logic.

3. The output method for preventing memory overflow during firmware upgrade based on a 32-bit microcontroller as described in claim 1, characterized in that: S2 specifically includes the following steps: S201: HEX file merging processing, used to merge the BootLoaderHEX file and the APPHEX file into a complete HEX file, namely MERGER_HEX, according to the address allocation rules of the 32-bit microcontroller Flash of the urine analyzer. At the same time, it ensures that the two files do not overlap in the Flash address space to avoid data conflicts that may cause firmware upgrade failure. S202: HEX file to BIN file processing, used to convert the merged MERGER_HEX file and the separate APP_HEX file into BIN files, namely MERGER_BIN and APP_BIN, respectively, removing redundant format characters, reducing file size, and adapting to the programming requirements of the 32-bit microcontroller of the urine analyzer.

4. The output method for preventing memory overflow during firmware upgrade based on a 32-bit microcontroller as described in claim 3, characterized in that: S201 also includes logging of the merging process, which is used by operators to monitor the merging progress and troubleshoot problems. The script will record detailed logs in real time during the merging process. The log content includes execution time, current operation, files involved, address range and execution result.

5. The output method for preventing memory overflow during firmware upgrade based on a 32-bit microcontroller as described in claim 1, characterized in that: S3 specifically includes the following steps: S301: Hard constraint on address range. Throughout the entire process of merging and converting HEX files, the writable address range of the 32-bit microcontroller Flash of the urine analyzer is always used as a hard constraint. All file processing operations are strictly limited to this range to eliminate the risk of address overflow from the source. During the HEX file merging process, the "-r"08000000:0807FFFF"" parameter forces the merged MERGER_HEX file to retain only data within this address range, and any redundant data outside this range is automatically removed by the script. At the same time, dedicated address ranges are specified for APP_HEX and BOOT_HEX respectively, and the two ranges have no overlap, ensuring that the BootLoader and APP are stored independently in Flash and that data is not overwritten due to address overlap. S302: Active Overflow Detection. Through the built-in overflow detection function of the script, it actively identifies whether there is an address in the MDK output file that exceeds the Flash writable range, and checks for potential problems in advance before the file enters the merging and conversion process. S303: Non-upgrade space initialization. Before generating the BIN file, the script initializes the data in the non-upgrade space of the microcontroller Flash, clearing residual old data, redundant code, and error messages to avoid conflicts with the new firmware. The specific process of initialization is as follows: When the script generates the MERGER_BIN file, it will automatically identify the address range of the non-upgrade space, and write 0xFF, which is the default value after the microcontroller Flash is erased, to all addresses in the range, overwriting the original residual data.

6. The output method for preventing memory overflow during firmware upgrade based on a 32-bit microcontroller as described in claim 1, characterized in that: S4 specifically includes the following steps: S401: Redundant file cleanup logic. Redundant file cleanup follows the principle of verification before deletion. Before deleting a file, the script will first confirm that the subsequent process corresponding to the target file has been completed and that the file is unnecessary to keep, so as to avoid accidentally deleting files that are still needed. S402: Environment variable cleanup logic. The purpose of cleaning up environment variables is to avoid conflicts between the variables defined in this method and the environment variables of other programs in the system, and to release system resources. The cleanup process is executed after the redundant files are cleaned up. The script uses the command "set variable name=" to clear the values ​​of each environment variable so that they no longer occupy system environment variable resources.

Images