Microcontroller ISP Activation Using Driving Codes Without Boot Delay
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for initiating in-system programming (ISP) require additional hardware or result in boot delays due to inefficient detection mechanisms, making them inflexible and time-consuming.
Innovation Solution
A method and microcontroller that utilize a set of driving codes to set an in-system-programming flag, execute a system reset, and detect the flag to initiate the ISP procedure, allowing for flexible activation without additional circuits and minimizing boot delays.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If method 1 uses additional buttons, jumpers, or test points to activate ISP, then ISP activation capability is achieved, but device complexity increases
Solution Approach 1:
The patent extracts the ISP activation function from physical hardware components (buttons, jumpers, test points) and relocates it to the software domain through driving codes. The microcontroller detects ISP activation by receiving specific code sequences through existing communication interfaces, eliminating the need for dedicated physical activation components while maintaining the capability to initiate ISP mode.
Solution Approach 2:
The patent makes existing communication interfaces (UART, SPI, I2C, etc.) serve multiple functions: they are used both for normal system operation and for detecting ISP activation requests. The same communication pins that handle data transmission also receive driving codes that trigger ISP mode, thereby eliminating the need for separate dedicated activation hardware.
2Reliability
If method 2 uses boot options in non-volatile memory to determine ISP activation, then ISP activation is determined, but flexibility to change activation decision is reduced
Solution Approach 1:
The patent transitions from a static ISP activation mechanism (fixed boot options in non-volatile memory) to a dynamic one where activation can be changed at any time by sending different driving codes. The system can switch between normal boot and ISP mode dynamically based on received codes, allowing flexible reconfiguration without hardware changes or memory reprogramming.
Solution Approach 2:
The patent changes the activation parameter from fixed memory-stored boot options to dynamically received driving codes. By modifying which codes are sent to the microcontroller, the activation state can be changed instantly, providing flexibility while maintaining reliable determination through code verification mechanisms.
3Reliability
If method 3 uses timeout mechanism to detect ISP connection request, then ISP activation is detected, but boot delay increases
Solution Approach 1:
The patent implements preliminary action by having the microcontroller continuously monitor communication interfaces for driving codes during the boot process, rather than waiting for a timeout period. The system is already in a state ready to detect ISP activation requests, so when driving codes are received, immediate action can be taken without delaying the boot sequence.
Solution Approach 2:
The patent allows the boot process to proceed rapidly by skipping the timeout waiting period. Instead of pausing to detect connection requests, the system rushes through normal boot initialization while simultaneously monitoring for driving codes, and can immediately divert to ISP mode if activation codes are detected, thereby eliminating unnecessary delays.
Data Source
AI summary
A method for driving in-system programming is provided. The method includes receiving a set of driving codes; setting an in-system-programming flag according to the set of driving codes; executing a system reset after the in-system-programming flag is set; detecting whether there is an in-system-programming flag after the system reset is finished; and executing an in-system-programming procedure when an in-system-programming flag is detected.