Difference between revisions of "The ARM7 board"

Revision as of 16:11, 23 March 2009

Overview

One Member of the Concept Car's network is an ARM7 board. Due to its 32 bit architecture and higher frequency it provides a much bigger computational power than the AT90CAN128 boards. Thus it is well suited to do all the computation-intensive tasks.

Signal Flow

The AT90CAN128 actorboard offers a selection switch/jumper to choose between two different sources to generate its PWM output. By that you can select whether it uses direct input from the sensorboards or works on the preprocessed data from the ARM7 board.

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.

Board Functionality

Low Level Functionality

The AT91SAM7A2 ARM processor provides 32-bit processing power to the Concept Car. Among the low level functionalities are:

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

To enable access to these functionalities 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.

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:

/---------------\ 0x00000000
|     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  |
|               |
\---------------/ 0xffffffff

• After boot:

/---------------\ 0x00000000
|               |
| 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  |
|               |
\---------------/ 0xffffffff

• External RAM Memory Map:

/---------------\ 0x40600000
|               |     ||
|  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)
\---------------/

Bootloader

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 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 exeption. 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).

User level functionality

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.

Related Files

All of the files related to user code are placed inside the folder named "usr" inside src and include folders. The ".c" files found in src/usr are processed automatically by make and do not need any further customization in order to be integrated. If any user shall add functionality implemented in multiple C files, these files must be added to the src/usr folder. User header files (".h") must be added to include/usr. When building the application all C files inside src/usr are linked together in order to build the user application.

User Applications

Actually the primary use of the board is for Simulink models execution. The usual flow is Simulink model design, code generation and deployment on the board. For this reason the basic functionality one find when downloading the source code is a "user" main.c file already coded with Simulink model logic. In order to use simulink models there is no need to alter the basic code provided. Instead, the user is directed to 'Executing a Simulink Model' where information about running Simulink models on the board is provided.

Concerning the case where the user is interested in running applications that are not derived from a Simulink model. There are a few things that should be noted. Since the basic structure of the board user code is designed to run Simulink models, the user must first change the main.c file, which can be found inside src/usr. The basic idea is an endless loop. Since the user application should never return, inside the main function in main.c there should be an endless loop calling the user logic every time it is necessary. From this point on, the user is free to create any logic and divide the code in any number of files. As stated above, the files added to src/usr are automatically compiled and linked together with the main.c file. All of the functions provided inside src/base are available to the user. They provide access to the board functionalities.