Development of microcontrollers

How is microcontroller system development carried out?

Generally, the development flow steps are as follows.
  (1) System design
  (2) Parts procurement
  (3) Prototype hardware development
  (4) Program development
  (5) Operation verification and debugging, using in-circuit emulators, simulators, evaluation boards, etc.
  (6) ROM programming
  (7) Operation verification using actual chip
  (8) Development of mass-production board version
  (9) Ordering of mask ROM
  (10) Operation verification of mask-ROM versions

At step (1), a microcontroller version is selected to suit the system requirements, the operation modes are defined for the microcontroller's internal functions, external connections and addresses are assigned, the processing flow is created, and so on.

Some of the development work at steps (3) and (4) are performed concurrently, by dividing tasks among hardware and software.
At step (3), the board's hardware is designed and components (other than the microcontroller) are mounted. Since the product is still just a prototype at this stage, parts are socket-mounted and wires are either wrapped or soldered.

At step (4), a computer (PC, etc.) is used to create programs (for programming the product).
The programming language that is used is typically C language, or assembly language for certain CPU architectures.
After the programs are completed, they are sent to an assembler if they are in assembly language or to a C compiler if they are in C language, where they are converted to machine language.
Some C compilers convert the program in C to assembly language once, and then assemble it to machine language.
If there are numerous separate machine-language programs, a linker is used to associate (link) them.



At step (5), an IE (in-circuit emulator) and computer may be connected and used to execute programs deployed in the IE instead of using the microcontroller in the target system.
If any problems occur, a simulator or debugger is used to debug the logic and programs.
A socket adapter may be needed in cases where the microcontroller's planned package does not fit the IE's adapter.



At step (6), either a PROM programmer is used for a PROM (internal or external) device or a flash programmer is used for a flash memory device to write ROM code that has been converted from machine language programs created using a computer.



At step (7), the programmed ROM and the microcontroller under development are both mounted onto the target board and program operations are checked.
At step (8), a PCB (printed circuit board) version is created.

At step (9), mask-ROM versions for mass production are created.
In these mask-ROM versions, not only are the programs available but other functions also can be set via mask options.
For description of how these versions are ordered, see "ROM code ordering" (Japanese).
Finally, at step (10), the microcontroller from step (9) is mounted along with other required devices onto the PCB board from step (8), and a final round of operation checks is performed.

How are microprocessor instructions configured?

Instructions that directly define microprocessor operations at register level are described in assembly language. Assembly language consists of mnemonics that define the basic operation and operands that specify the internal register or an address (memory, I/O) to be accessed.
In C language, microprocessor instructions are not defined directly, but rather conceptually, i.e., as a mathematical expression, transfer operation, or judgment. Associations between C language and the microprocessor instruction set are made by a C compiler. Consequently, the code generation efficiency differs depending on the C compiler used.
The machine language generated by the C compiler or assembler is the instruction code, which is in a format that can be directly executed by the microprocessor.



Even with a microprocessor in which access between internal registers is described using a 1-byte instruction code, the instruction code will be at least two bytes when a memory or I/O address value is described for the transfer destination (dst) or source (src). The first byte is called the opcode (operation code) and when the microprocessor reads this code, the operation is known as an opcode fetch. The microprocessor analyzes the fetched opcode, identifies how many bytes long the instruction is, and determines whether there is any code remaining (i.e., whether to fetch more code before executing the instruction).

What is ROMization? Why is it needed?

Application programs used in microcontrollers are ultimately written to some kind of on-chip ROM (mask ROM, flash memory, etc.), and the microcontrollers are then embedded in the application system.
Consequently, it is not enough simply to create and compile C-language programs.
Besides just placing programs and fixed data into on-chip ROM, other items such as data to support variables that have initial values must be programmed.
For example, variables that have initial values must be placed in RAM when starting an application program so that they can be referenced or modified as necessary.
However, the contents of RAM become undefined when the power is supplied to the microcontroller.
Consequently, before starting an application program, initial values must be set for certain variables.
This processing is called ROMization, which means storing initial value data in ROM so that it can be copied to the corresponding RAM at startup.



ROMization is a standard feature in 78K Series products, but it must be specified as an option in V850 Series products.
Also, code (using the to _rcopy function) to copy data from ROM to RAM must be included in the application program.

Is ROMization necessary when debugging a flash memory version?

Yes, ROMization is also necessary for debugging flash memory version.

Is it OK to skip ROMization when using an emulator to debug, and to implement ROMization when ordering the ROM instead?

No, ROMization should occur at the debugging stage where the emulator is used.
If it is not included then, there is a chance that, during the debugging process, variables with initial values may lose their initial values after operating the program again from a reset.
(With an emulator, even variables that have initial values are directly downloaded to RAM as objects, which is when their initial values are stored in RAM. However, when a variable is modified while debugging, the modified value remains. When the program is reset or re-executed (retried) in this event, the program operation changes since the modified value replaces the original initial value. Only when these new initial values have already been ROMized they can be copied and used as the correct values.)

I was told to use Intel HEX format when ordering ROM code. What is Intel HEX format?

Intel HEX (hexadecimal) format is a format used when dealing with objects (machine-language code). In this format, each byte is converted to a two-digit hexadecimal value by ASCII code.
Each record (line of code) can represent up to 255 bytes of data, and this conversion is repeated for the required amount of data. A detailed example of this format is shown below.

":" indicates the start of a record.
The next two hexadecimal digits (10) indicate the record's data length (the number of data).
The next four hexadecimal digits (0000) indicate the data's address.
The next two hexadecimal digits (10) indicate the record type (in this case, it shows the type is a data record).
("00" indicates data record, "01" indicates end record, and "02" indicates segment record.)
This section contains the actual data. The data values here are "00", "01", "02", and so on up to "0E" and "0F."
These last two hexadecimal digits are used for error checking (checksum). This checks whether or not the lower eight bits are "00" in the sum obtained by adding the hexadecimal values starting from the data length value.

Finally, a carriage return code is appended to the end of each line to complete it as a record.
The second line is an end record with the data length = "00" and the record type = "01."

\

The above type of record can indicate only 16-bit addresses (64-Kbyte address spaces).
A segment record (record type 02) can be used to specify larger addresses.
In the example below, a segment record has been inserted before the first line of code that was shown in the above example.
Segment values specified in a segment record are multiplied by 16 and added to the following record's address specification.
In this case, "1000 (H)" () is specified as a segment value, so it means that the following data is stored to the address range from 10000H to 1000FH.

Can any code be used for ROM ordering as long as it is in Intel HEX format?

No, other restrictions apply for checking the mask ROM processing.
For example, there are no restrictions on the sequence of record addresses in Intel HEX format, but for mask ROM processing the addresses must be consecutive and in ascending order.
Other detailed checks are also performed, so the required options should be specified and code should be run through an object converter at the ROM ordering stage.