The SAM4E-EK motherboard platform HAL package is loaded automatically when eCos is configured for a suitable target, e.g. sam4e_ek. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.
The SAM4E_EK board platform HAL package supports three separate startup types:
This is the default startup type. It is used to build applications that are loaded via a JTAG interface. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x20000000 and entered at 0x20000408. eCos startup code will perform all necessary hardware initialization.
This startup type can be used for finished applications which will be programmed into internal flash at location 0x00400000. Data and BSS will be put into SRAM starting from 0x20000000. The application will be self-contained with no dependencies on services provided by other software. The program expects to boot from reset with flash mapped at location zero. It will then transfer control to the 0x00400000 region. eCos startup code will perform all necessary hardware initialization.
This startup type can be used when a board has a GDB stub ROM resident in internal flash. It enables eCos application development without the necessity for a JTAG debugger, providing arm-eabi-gdb connectivity via UART0 (DBGU). The stub is programmed into the on-chip flash memory at 0x00400000 and uses SRAM at location 0x20000000. arm-eabi-gdb is then used to load RAM startup applications into memory from 0x20001000 and debug them. It is assumed that the hardware has already been initialized by the stub ROM. By default the application will use the eCos virtual vectors mechanism to obtain services from the ROM, including diagnostic output.
RedBoot and Virtual Vectors
If the application is intended to act as a ROM monitor, providing
services for other applications, then the configuration option
CYGSEM_HAL_ROM_MONITOR should be set. Typically
this option is set only when building GDB Stubs.
If the application is supposed to make use of services provided by
a ROM monitor, via the eCos virtual vector mechanism, then the
should be set. By default this option is enabled when building for
a RAM startup, disabled otherwise. It can be manually disabled for
a RAM startup, making the application self-contained, as a testing
step before switching to ROM startup.
If the application does not rely on a ROM monitor for diagnostic services then the serial port will be claimed for HAL diagnostic output.
UART Serial Driver
The SAM4E_EK board uses the SAM's internal UART serial support. The HAL diagnostic interface, used for both polled diagnostic output and GDB stub communication, is only expected to be available to be used on the UART0 (DBGU) port. This is because only UART0 is actually routed to an external RS232 connector.
As well as the polled HAL diagnostic interface, there is also a
CYGPKG_IO_SERIAL_ARM_AT91 package which
contains all the code necessary to support interrupt-driven
operation with greater functionality.
It is not recommended to use the interrupt-driven serial driver with a port at the same time as using that port for HAL diagnostic I/O.
This driver is not active until the
CYGPKG_IO_SERIAL_DEVICES configuration option
within the generic serial driver support package
CYGPKG_IO_SERIAL is enabled in the
configuration. By default this will only enable support in the
driver for the UART0 port (the same as the HAL diagnostic
interface), but the default configuration can be modified to
enable support for other serial ports.
USART1 is disabled by default since it requires pins and clocks to be configured and PA23 to be pulled low and a jumper to be changed to support RS232. The option CYGHWR_HAL_CORTEXM_SAM4E_EK_USART1 enables the hardware to be configured; the user must change JP11 to the 2-3 position in order to enable access to USART1 via J5.
An SPI bus driver is available for the SAM in the package "Atmel
AT91 SPI device driver"
The only SPI device instantiated by default is for an external AT25DF321A NOR flash.
Consult the generic SPI driver API documentation in the eCosPro Reference Manual for further details on SPI support in eCosPro, along with the configuration options in the AT91 SPI device driver.
Support for SAM I²C (TWI) busses is provided by the "Atmel
TWI (I2C) device driver" package
CYGPKG_DEVS_I2C_ATMEL_TWI). The SAM variant
HAL causes the two buses to be instantiated. These have been
tested using external I²C devices. The only on-board I²C
device, the QTouch controller, is not supported.
The AT91SAM4E-EK board uses the AT91SAM4E's internal EMAC ethernet
device attached to an external Micrel KSZ8051MNL PHY. The
CYGPKG_DEVS_ETH_ARM_AT91 package contains all
the code necessary to support this device and the platform HAL
package contains definitions that customize the driver to the
board. This driver is not active until the generic Ethernet
included in the configuration.
Both the standard and direct (lwIP only) device drivers are
supported. The standard driver is enabled by default; the direct
driver can be enabled by setting
The SAM4E has dual CAN devices for CAN support. Device support is
via the Atmel SAM CAN Driver
The board has two external CAN sockets, J13 and J14, which are RJ12 female sockets.
Consult the generic Chapter 82 documentation for further details on use of the CAN API, CAN configuration and device drivers.
The SAM4E's on-chip Flash may be programmed and managed using the
Flash driver located in the "FLASH memory support for Atmel AT91 IAP"
CYGPKG_DEVS_FLASH_AT91IAP) package. This driver
is enabled automatically if the generic "Flash device drivers"
CYGPKG_IO_FLASH) package is included in the
eCos configuration. The driver will configure itself automatically for
the size and parameters of the specific SAM variant present on the
A number of aspects of Flash driver behaviour can be configured within that driver, such as program/erase parallelism and program burst size. Consult the driver and Part XVI in eCos® and eCosPro® Reference Manual documentation for more details.
ADC support is provided by the
Atmel AFEC ADC Driver
By default AFEC0 AD4 is connected to BNC C2 (jumper JP40 pins 1-2
connected). The jumper JP40 can be changed to select AFEC1 AD0 as
the ADC input channel (NOTE: For JP40 2-3 the link J37-6 *MUST* be
CYGPKG_HAL_CORTEXM_SAM4E_EK_AFE_CN2_JP40 must be
set to reflect the state of the jumper.