Browse Prior Art Database

Interactive Flash Programming Operations

IP.com Disclosure Number: IPCOM000195065D
Publication Date: 2010-Apr-20
Document File: 3 page(s) / 187K

Publishing Venue

The IP.com Prior Art Database

Abstract

This paper describes a software design for executing flash operations takink advantage of the ability to read/write memory on certain hardware while it is in running mode. The design for erase/program algorithms is similar to a state machine. A small applet will be loaded on target's RAM and executed. Based on current applet state (ready, wait, program, erase, etc…), a flash programmer engine will know what to do next.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Interactive Flash Programming Operations

Abstract

This paper describes a software design for executing flash operations takink advantage of the ability to read/write memory on certain hardware while it is in running mode. The design for erase/program algorithms is similar to a state machine. A small applet will be loaded on target’s RAM and executed. Based on current applet state (ready, wait, program, erase, etc…), a flash programmer engine will know what to do next.

   

Introduction

Usual operations with flash memories like programming or erasing requires significant effort to support different architecture depending on the flash memory type and the processor that controls a hardware device. To limit this fast expanding matrix of cpu and flash device, the operations are incorporated into flash algorithms designed independent from the cpu that are compiled and executed directly on the device.

The flash algorithm in order to be executed needs to be loaded into the device RAM memory and only commanded from an additional tool. Cost effective architectures sometimes do not have enough space in RAM for the code of the algorithm to fit, some of them having only 52 bytes of RAM.

For these architectures is needed a way to reduce the memory footprint of the algorithm and the way it is organized to minimize the memory/register access interaction and the run control coded in the debug probe firmware.

A solution is to implement flash programmer operations like a software state machine resident in the device’s external RAM. In this way the algorithm will consists in only few states with no break, continue, end logic that fragments the communication between the device and the debug probe controller.

The effects obtained are the reduced size of the flash programming algorithms and an increase in speed for the operations executed.

System architecture

The architecture for implementing operations with an external device which flash memory needs to be accessed consists in a hardware architecture for infrastructure and a software protocol for logical execution.

The hardware architecture is based on a host PC, a debugger probe with serial communication and the device to be erased, programmed.

The software protocol is based the communication from a flash programmer engine that runs on the host computer with the device using the debugger probe firmware.

Figure 1 : Flow diagram - Flash Programming Engine is writing the data buffer with target in running mode, increasing speed for program/erase operations


Flash Programmer engine

The flash programmer engine is a command line based plugin that implements all the logic behind the flash operations.

Its first operation is to load on target’s RAM the algorithm specific for an operation ( e.g. erase algorithm, program algorithm, etc…). Then it resumes the target letting the algorithm to reach the Idle state which means that it waits for data buffer to be filled. Once the data is written the engine will send a c...