Patent Application
20060271728
The invention relates to a low area architecture for embedded flash programming memories in microcontrollers. More particularly, but not exclusively, the invention relates to a low area architecture for programming a flash memory embedded in a microcontroller comprising a microcontroller core, an embedded flash memory portion, an input/output port and an interface between the core and the memory portion.
The following description relates to this specific field of application to make the illustration easier to understand.
Microcontrollers with embedded flash memories are widely used in applications from home appliances to automotive. The embedded flash memory is very useful in system programming. The application developer can update program code inside the embedded flash memory in the microcontroller, without removing it from the board, through a serial link connection with the programmer (i.e., the PC). The application developer can quickly modify the application program until it properly works.
In
Even if not explicitly shown in
Through the above-mentioned six pins, the microcontroller embedded flash memory can be programmed. The boot program stored in the RON is used to configure the ports of the system during the start-up phase and to load the RAM memory. When the microcontroller is powered on, and before using it for any applications, a user needs to program the embedded flash memory with program codes, which allows the microcontroller to operate as needed.
In particular, after connecting the ports as shown in
When in the ISP mode, the microcontroller executes the boot program located in the embedded ROM to configure the I/O port of the serial link (ISPDATA, ISPCLK) and to load the bootstrap program in the RAM. Then the microcontroller CORE fetches, decodes and executes the bootstrap program code from the RAM and reads data through the serial link to program the flash memory.
When the microcontroller is in the ISP mode, the boot ROM is executed through the ISPDATA to read and load the bootstrap program in the RAM. Then the control jumps to the RAM to execute the bootstrap program. The bootstrap program reads data through the serial link and programs the flash memory and the option bytes.
As previously mentioned, in this system architecture the CORE is switched on to fetch, decode and execute the bootstrap program from the RAM, and a dedicated nonstandard serial link/protocol interface is needed for this task. For example, in the prior art document “Atmega32: 8-bit AVR Microcontroller with 32K Bytes In-System Programmable Flash”, in the name of Atmel Corporation, at page 218, a block diagram representing a device architecture is schematically represented. The device comprises input/output ports and four additional pins TDI, TDO, TCK and TMS linked to a TAP controller that is in communication with the core.
According to this approach, the core is involved both in a normal mode execution and in a programming mode execution. In this way, it is not possible to use the core in the normal mode execution, such as for executing code on a first memory, while the TAP controller is executing in the programming mode, such as on second memory or on an additional device, for example. This is a drawback for increasing system performance.
In view of the foregoing background, an object of the present invention is to simplify the above-described embedded flash memory programming system. More particularly, the object is to reduce the configuration complexity of the start-up phase due to the need of interfacing the microcontroller with the embedded memory portions for reading the ROM, for transferring the boot program in the RAM and for the subsequent execution of the program.
Another object is to provide an architecture for embedded flash programming not based on a ROM and structured to at least reduce internal switch noise when switching off the CORE during a programming phase, and to reduce flash memory programming time avoiding downloading code in the RAM through boot ROM execution.
According to one embodiment, the system architecture is free from the ROM to improve not only the performance but also for addressing the testing problems related to the ROM and to achieve a system full scan test. Also, the manufacturer may not need to previously store a boot program in the ROM or in a dedicated part of the flash.
According to a more specific aspect, a standard serial link protocol is used to interface the microcontroller instead of a nonstandard protocol, as it will be clear in the following more detailed description.
The features and advantages of the invention will be apparent from the following description of an embodiment thereof, given by way of a non-limitative example with reference to the accompanying drawings.
A microcontroller 10 with an embedded flash memory 1 is schematically shown in
In particular, on the left side of
The I2C peripheral 2 is connected through the DATA_BUS 3 to the ISP controller 4 and to a multiplexer 5. The memory interface 6 is connected to the ISP controller 4 through a mem_address line connection 7 and to the CORE 8 through a mem_addr_core line connection 11.
A ROM is not required to set up the microcontroller, and as a consequence, transferring the boot program from the ROM to the RAM is not requested for subsequent execution.
The register file 9 is connected to the MUX 5 and to the memory interface 6 while the flash memory 1 is connected to the MUX 5 and the memory interface 6.
After connecting the ports as in
When in the ISP mode, the digital ISP controller 4 configures the I/O ports. After that, the digital ISP controller 4 manages the standard I2C 2 serial links SDA and SCL, and waits for command from a programmer.
In this way, no ROM is needed and no bootstrap program is downloaded and executed in the RAM by the CORE 8. Program code execution by the CORE 8 is replaced, in this architecture, with commands executed by the digital ISP controller 4, as shown schematically in
In the following TABLE 1 the commands received by the I2C interface 2 and sent to the ISP 4 controller through the common DATA_BUS 3 are reported.
This table thus reports the commands for the digital ISP controller 4. Then the ISP controller 4 decodes these commands, sends address (mem_address), data (DATA_BUS) and read/write signals (rd, wr, wen, csn) to the memory interface to program the flash memory and option bytes, as shown in
The ISP controller 4 provides address and read/write signals for the register file 9 and memory 6 only in the ISP mode. While in the normal mode, they are provided by the CORE 8 (through mem_addr_core, wen_core, csn_core, rd_core and wr_core link). For this purpose, a MUX stage is present inside the memory interface to select, depending on the microcontroller mode, if the CORE 8 or the ISP controller 4 are generating flash and register file addresses.
If the microcontroller is in the ISP mode, the ISP controller 4 generates a flash_address directed to the flash memory 1, an RF_address directed to the register file 9, read/write signals wen_RF and csn_RF are also directed to the register file 9 and prg and erase signals are directed to the flash memory 1.
If the microcontroller 10 runs in the normal mode, the CORE 8 is responsible for generating and addressing the addresses described above. The same happens not only for addresses but also for data in the MUX of
The other input of the MUX is data coming from the register files 9 that need to be swapped on flash during a BlockWrite command when the ISP controller first loads the 64 bytes in the register files, then swaps them on flash.
The ISP controller 4 is responsible to manage the MUX selector signal. In conclusion, we can see that in the ISP mode the CORE 8 does not need to fetch, decode and execute a bootstrap program from the RAM. So it can be switched off, thus reducing internal noise.
Advantageously, the ISP controller 4 is independent of the CORE 8, and the low area architecture supports a contemporary execution of the ISP controller in the programming mode and the CORE 8 in the normal mode.
Moreover, the ISP controller 4 is connected to a standard input/output port comprising only two pins so that no additional peripheral intended to be used in the programming mode and requiring additional pins are needed.
| Number | Date | Country | Kind |
|---|---|---|---|
| 05011710.0 | May 2005 | EP | regional |
