ECU implementing Controlboard

From ConceptCar
Jump to: navigation, search

The Controlboard is implemented over an AT91SAM7A2 board. It was presented in Section Electronic System in the Data Processing level of the Figure 1.3.

Control board overview

As stated above, the Controlboard has bigger computational power than the other Sensor and Actorboards and it is responsible for the vehicle intelligence, executing computation-intensive tasks, allowing the implementation of more complex applications as driver assistance systems.

The board does not have direct access to any sensors or actuators, but relies on the other boards to provide sensory input and apply actuator settings.

The current firmware of this ECU offers an elegant and quick solution to load external executables via a bootloader from an SD-Card. Through a half-automated process executables can be created from Simulink™ models. The process, tools and further information are presented in details in Chapter 2.

Table 1.7 presents the CAN messages the Controlboard emits. The "CAN-IDs" column presents the integer representing the ID of the message. Column "Semantics" describes the type (or meaning) of the message. Column "Interval" describes the interval in which the message is sent. Finally, the column "Conversion" holds a formula that is used for converting the message content which is usually a float value to the integer data that is packed into the message.

Table 1.7: Controlboard's CAN messages
CAN ID Semantics Interval Conversion
0x122 Throttle value for engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. Simulink Model’s step time
Error creating thumbnail: Unable to save thumbnail to destination
0x125 Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. Simulink Model’s step time
Error creating thumbnail: Unable to save thumbnail to destination

The following Sections describe the Controlboard in details, its hardware, signals, platform software, run-time environment and bootloader. Those details are very important to understand the next steps, where the process to develop applications to the Concept Car is described.

Hardware description

The AT91SAM7A2 board is based on the ARM7TDMI embedded processor with a 32-bit RISC architecture, 16-bit instruction set and low power consumption. It is composed by an on-chip 16K bytes internal SRAM, 2 UART interfaces, SPI Interface, 4 Channel 16-bit PWM (Pulse Width Modulation), 4 CAN Controllers, Timer Counter, LEDs (Light-Emitting Diode), GPIO (General Purpose Input/Output), ADC (Analog-to-Digital Converter), Buttons, Ethernet, Buzzer and several others resources described in [reference AT91SAM7A2]. Figure 1.6 shows the AT91SAM7A2 board.

Figure 1.6. AT91SAM7A2 board that implements the Control Board

Signal Flow

As mentioned above, the AT90CAN128 Actor Board can operate based on two different sources to generate its PWM output. For that, the board offers a selection switch/jumper to choose between those models. By that one can select whether it uses direct input from the Sensor Boards or works based on the pre-processed data from the ARM7 board.

Software description

The ARM7 board itself is not intended to directly access sensors or actors, it should merely process data from the CAN bus and produce control messages for the Actor Board.

To enable access to all functionalities and components of the board C source code is provided. The source code eases the task of accessing board peripherals and makes software development a bit easier. Besides the resources listed above there is also code for dealing with interrupts, timers, SD Cards and so on.

The software of the board consists of a bootloader and of the application software.

Platform software and run-time environment

The platform software is the basic software provided to access the board’s resources. The AT91SAM7A2 board provides basic software for the following hardware resources:

  • SPI
  • CAN
  • LED
  • GPIO
  • ADC
  • Buttons
  • Ethernet
  • Buzzer



The bootloader is the boards’ base software and is responsible for two main tasks: deal with low level configuration of the platform (PLL setup, AMC, GIC, peripherals, etc.), load the user application from SD Card into the main memory.

The bootloader is located on the external ash memory. It scans for a SD card and checks if it finds an appropriate filesystem with the specific application file on it. If the file is found on the card, it will be copied to the external SRAM and will be executed from there. There is no multi-tasking operating system with syscalls or similar.

The basic steps during bootloader execution are listed below:

  • Setup memory map
  • Setup interrupt vectors in internal RAM
  • Setup execution modes stack
  • Setup PLL
  • Initialize its data section
  • Configure peripherals
  • Load user application from SD Card
  • Branch to user application

The user application is loaded into the RAM starting from RAM address 0x00000000. This address is mapped to address 0x40600000 on the ARM processor. After loading the application to 0x40600000 the bootloader configures the Stack Pointer (SP) to point to address 0x40808ffc, which is the top of user application stack. Between application and stack more than 1MB is available. The bootloader also configures the interrupt mode stacks the processor uses when handling an interrupt or exception. This stack begins at address 0x409ffffc and extends until 0x409ffd08 with a size of 0xfc for each mode (Interrupt, Fast interrupt, Abort exception (data abort and prefetch abort) and Undefined exception).

The complete memory map before and after the boot is presented in the following.

Memory map

The board has a 4MB RAM memory accessed by the ARM processor. The access to this memory is configured by the ARM's AMC, which defines the address range for the external memory. Below a description of the current memory map is shown, for further details on the memory map please check the datasheet.

  • Before boot
|     FLASH     |
|               | Low level code initially here (Bootloader: basic low level setup)
|      1MB      |
|_______________| 0x000fffff
|               | 0x00100000
|   Reserved    |
|               | 
|_______________| 0x002fffff
|               | 0x00300000
| Internal RAM  | 
|     16kB      | 
|_______________| 0x003fffff
|               | 0x00400000
|   Reserved    | 
|               | 
|_______________| 0xffdfffff
|               | 0xffe00000
|  Peripherals  |
|               |
  • After boot:
|               |
| Internal RAM  | Reset and other vectors (data abort, fetch abort, irq, firq)
|     16kB      | 
|_______________| 0x000fffff
|               | 0x00100000
|   Reserved    |
|_ _ _     _ _ _| 0x002fffff
|               | 0x00300000
|   Reserved    | 
|_______________| 0x3fffffff
|               | 0x40000000
|   Flash 1MB   |
| External RAM  | 
|      4MB      | User application code, loaded by bootloader (subdivided into memory regions described below)
|               |
|_______________| 0x7fffffff
|               | 0x80000000
|   Reserved    | 
|_______________| 0xffdfffff
|               | 0xffe00000
|  Peripherals  |
|               |
  • External RAM Memory Map:
|               |     ||
|  Application  |     \/
|               | User application code gets loaded here
|_ _ _     _ _ _| 
|               |
|  Application  |     /\ 
|     Stack     |     ||
|_ _ _     _ _ _| 0x40808ffc
|               | 0x40809000
|               | 
|     FREE      | 
|_ _ _     _ _ _|
|               | 
| ARM SVR MODE  |     /\
|     STACK     |     ||
|_ _ _     _ _ _| 0x409ff000 (Supervisor mode stack)
|               |
|  UNDEF STACK  | 0x409ffd08 (Undefined exception stack)
|  ABORT STACK  | 0x409ffe04
|  IRQ STACK    | 0x409fff00
|  FIRQ STACK   | 0x409ffffc (Last valid address on external memory)

User level

The user level code is responsible for executing more complex tasks and should not concern about low level details. For this reason there are peripheral access functions in order to provide simple communication to peripherals from user code. Any customization can be done on the user part and there are only a few restrictions on modifying user code. Actually the primary use of the board is for Simulink models execution but also other applications that are not derived from a Simulink model can be executed.

The application development and deployment process is explained in detail in Chapter 3.