Prácticas de enseñanza ante la diversidad en los procesos de formación

Flash programming using the vehicle network bus has gained momentum lately; in fact it is in full motion, and has solid footing in the industry today. The idea is to download the entire module application code into the microcontroller’s fl ash mem-ory by utilizing the network communication bus.

Well! How the network could function if there are no program instructions stored in the microcontroller memory?

– A blank microcontroller with no program instructions in the memory could not function at all!

– So, what is the solution?

Table 1.2 Automotive modules programmable memory types

Memory Programming Erasable Automotive use Technology

Flash Electrical Electrical High 1 fl oating-gate transistor/cell EEPROM Electrical Electrical High 2 Transistors/cell

EPROM Electrical UV Light Rare 1 Transistor/cell PROM Fusible link No Very Low 1 Transistor/cell

ROM Masked No Rare 1 Transistor/cell

1.28 Vehicle Programming

How about a microcontroller that has already been loaded with a tiny program stored in its memory locations?

Yes—it is called a bootstrap loader! Bootstrap loader is a small piece of code required to instruct the instruction execution unit of a typical computing engine to execute the series of tasks that assists the computer to ‘boot’. The word ‘boot’ is used to defi ne the operational phase of a computer when it performs the task of load-ing the operatload-ing software. Your personal computer or laptop boots the operatload-ing system from the hard disk, or CD-ROM after invoking a short program stored in the non-volatile memory or stored in the hard drive boot-sector.

In the early days of computers, the external ‘bootloader’ was used to load the monitor program, kernel or a device driver in the form of a binary code; read through the paper-tape reader into the computer memory (the paper tape had been used to store the binary code; quite interesting isn’t it?) There had been other ways as well like magnetic tape, magnetic drum or magnetic memory. The technology of mag-netic tape, drum memory, magmag-netic memory, and magmag-netic amplifi ers had been core building blocks of many ‘miracles’ of systems in the early days of computing.

1.28.1 Embedded Systems Booting

In today’s world of embedded systems; different type of booting methods are employed. An I ² C bus boot, SPI bus boot, Ethernet bus boot, CAN bus boot, USB bus boot, UART bus boot, so on and so forth. The automotive industry, however has preference over CAN-bus-boot as the accepted candidate to perform variety of tasks related to modules re-programming. The CAN bus boot thus far has proved out-standing success over the past so many years.

It is important to understand that the boot-code and module application-code are two separate and distinctively isolated programs stored at two separate address- space in the microcontroller’s memory. The boot-code remains completely inert, untouchable and write-protected while module performs its routine operational tasks. The boot-code never gets executed until the ‘reset vector’ is modifi ed. The modifi cation to the reset vector requires control instructions to be issued to the mod-ule by an external device via a proper handshake (a computer or a hand-held device).

Furthermore it is to clarify that “booting” has a slightly different meaning in computer industry compared to embedded systems of automotive industry.

In the computer industry, booting is executed to attain a high-level of operational intelligence from a low-level of machine-level intelligence like for example loading the operational software, operating software, kernel, monitor or some form of a driver into the memory storage area. However in the realm of automotive computing it means loading utility software, which helps to download the new code through serial means and eventually programs new or updated operational software in the module memory.

In short, we can re-defi ne a two stage booting fl ow for a vehicle module:

• Boot to establish contact with the external device defi ned as primary bootloader

• Boot to write program code in the fl ash memory defi ned as secondary bootloader

41

1.28.2 Primary and Secondary Boot Methods

Primary bootloader (PBL) and the secondary bootloader (SBL) are two important executable codes required to work through the process of vehicle module program-ming. The primary bootloader hereby referred as CAN bootloader establishes the communication to the external tool. In short it is a network device-driver meant for a particular processor’s communication node. Accordingly, when the primary boot-loader is executed; it uses the module communication channel to download a sec-ondary program called the secsec-ondary-bootloader. The secsec-ondary-bootloader is an another short-program comprises of tasks related to memory read, write, erase, and verify operations in order to self-program the module fl ash memory application code. Both bootloader are depended upon the type of microcontroller, its instruction- set, and memory address space.

The primary bootloader is always stored in the microcontroller’s “protected boot-sector’ memory in order to safeguard it from an accidental eraser. Nevertheless, whenever it is desired to execute the tiny program, it would fi rst access the network channel to communicate with the external intelligent device, completes the handshake, reads the secondary bootloader, and stores it in a temporary location of module random access memory. Once the secondary bootloader gets completely loaded into the random access memory, it is activated to assist performing fl ash memory read, write, and erase operations—consequently downloading the entire software code into the module memory from the external device through the CAN commu-nication channel.

Needless to say when this capability is achieved then the external device or test equipment can download the entire software code into the module memory with ease of operation. Such an incredible feature could have a profound impact at the following locations:

• Module manufacturing assembly line

• Vehicle manufacturing assembly line

• Vehicle service centers

• Module test and upgrade centers

• Research and development facilities

• Warranty and repair service centers

• In-vehicle software upgrading

Irrespective of fl ash programming locations, the external device or computer must have to access the module fl ash memory by means of a network physical layer.

The physical layer is the CAN interface between the module and the external device.

The module must keep optimum intelligence to send and receive digital data through the physical layer. At the other end, the test station must be able to initiate dialog between the corresponding modules. Once the handshake is established, the test station could then download the object fi le into the module memory. A zoom view of ‘A’ module is shown here, which is connected to end-of-line tester. The test sta-tion connects through the vehicle, diagnostics port connecter as shown in Fig. 1.22 .

1.28 Vehicle Programming

The sequence of operation depicted in Fig. 1.22 listed below:

• External tester send command to stop operational code execution

• External tester send command to execute PBL program

• PBL execution loads the SBL into the microcontrollers RAM space

• PBL and SBL functions together to begin Flash memory blocks access

• PBL and SBL fi nishes the erase/write operations to all blocks

• External tester send command to reset the module

• Module begins operational code execution

1.28.3 Vehicle Modules Programming

The vehicle module programming for an urgently needed software patch, or an extremely important software upgrade or bug fi xes to an existing software has caught serious attention by vehicle OEM’s and suppliers. It had cost time, money and delayed deliveries due to an urgently needed upgrade to the vehicles parked at the outside lot of vehicle assembly plants. The method of programing by physi-cal connection to the OBD II connector requires 100’s of laptops and work force

Protected Memory Space

Secondary bootloader Code

RAM Space

Flash Memory Space

CAN Physical Layer Rx Tx OBD II

Connector

Object File CAN

Interface Test Station or EOL

Microcontroller Interrupt Vectors Primary bootloader Code

Reset Vector Application Code

Operational Mode Programming

Mode

Fig. 1.22 Module connected to the external device to get the software download

43

to re- program vehicles. This mode of manual vehicle programming operation is not so, clearly defi ned, and does not have strong business case for a permanent solution. Alternately, OEM’s are positioning themselves to add Wi-Fi connectiv-ity to the vehicles in order to re-fl ash the module through the internet and get it fi xed for a long haul.

In short, the modules installed in vehicles, programmed by the following methods:

• Direct physical access to the module CAN bus through the OBD II Connector

• Direct physical access to the module through the USB bus if available

• Wi-Fi installed gadgets installed on to the OBDII connector

• Wi-Fi installed vehicles

1.28.4 Generalized Programming Procedure

The generalized programming method of direct physical access defi ned as a typical programming procedure to download data into the module:

• Invoke software user interface to talk to the vehicle communication bus

• Establish communication with the vehicle bus.

• Establish communication with the module needed to be programmed

• Select software download menu

• Select module identifi cation and enter security code

• Select appropriate secondary bootloader

• Select the applicable object code fi le

• Initiate programming sequence

• Request to enter in the programming mode

• Request to access fl ash memory blocks

• Erase the memory blocks that needed reprogramming

• Re-fl ash the memory blocks, and continue until fi nish

• Prepare checksum, or cyclic redundancy check and store results

• Request to terminate programming mode

• Initiate module reset to execute the new code by entering in operational mode (Fig. 1.23 )