Name

Configuration — Platform-specific Configuration Options

Overview

The Broadcom BCM943364WCD1 module platform HAL package is loaded automatically when eCos is configured for the bcm943364wcd1 or bcm943364wcd1_evb targets. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

Startup

The Broadcom BCM943364WCD1 module platform HAL package supports four separate startup types:

SRAM
This is the startup type 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 hal_virtual_vector_table_end and entered at that address. Memory below hal_virtual_vector_table_end is set aside for vector tables. eCos startup code will perform all necessary hardware initialization.
ROM
This startup type can be used for finished applications which will be programmed into internal Flash ROM at location 0x08000000. Data and BSS will be put into internal SRAM starting from hal_virtual_vector_table_end. The application will be self-contained with no dependencies on services provided by other software. The program expects to boot from reset with ROM mapped at location zero. It will then transfer control to the 0x08000000 region. eCos startup code will perform all necessary hardware initialization.
ROMAPP
This startup type can be used for finished applications which will be programmed into internal Flash ROM at the CYGIMP_BOOTUP_RESERVED configured offset. This is a variation of the ROM startup type for applications that are started by a smaller boot loader application. eCos startup code will perform all necessary hardware initialization.
RAM
This is the startup type which is used if relying on a GDB stub ROM image programmed into internal Flash to download and run applications into SRAM via arm-eabi-gdb and a serial UART. RAM from 0x20000000 to 0x20001000 is reserved for the GDB stub, but then the RAM startup application may be loaded into memory from 0x20001000 and debugged using GDB. It is assumed that the hardware has already been initialized by the GDB stub ROM. By default the application will use the eCos virtual vectors mechanism to obtain services from the GDB stub ROM, including diagnostic output.

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 the GDB stub ROM (or RedBoot).

If the application is supposed to make use of services provided by a ROM monitor, via the eCos virtual vector mechanism, then the configuration option CYGSEM_HAL_USE_ROM_MONITOR should be set. By default this option is enabled when building for a RAM startup, and 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 BCM943364WCD1 module uses the STM32'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 USART1 port (counting the first UART as UART1).

As well as the polled HAL diagnostic interface, there is also a CYGPKG_IO_SERIAL_CORTEXM_STM32 package which contains all the code necessary to support interrupt-driven operation with greater functionality. All three UARTs can be supported by this driver. For the BCM943364WCD1 module however the available I/O pins impose a limit on the available functionality.

[Note]Note

It is not recommended to use this 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 USART1 port (the same as the HAL diagnostic interface), but the default configuration can be modified to enable support for other serial ports. Note that in this package, serial port numbering starts at 0, rather than 1. So for example, to enable the serial driver for ports USART1 and USART2, enable the configuration options “ST STM32 serial port 0 driver” (CYGPKG_IO_SERIAL_CORTEXM_STM32_SERIAL0) and “ST STM32 serial port 1 driver” (CYGPKG_IO_SERIAL_CORTEXM_STM32_SERIAL1).

SPI Driver

An SPI bus driver is available for the STM32 in the package “ST STM32 SPI driver” (CYGPKG_DEVS_SPI_CORTEXM_STM32).

For the base BCM943364WCD1 module SPI bus 1 and bus 2 are configured for off-module SPI connections.

When targetting the BCM9WCD9EVAL1 based bcm943364wcd1_evb platform then the SPI1 flash memory device m25pxx_spi_device is enumerated.

To disable support for both the above SPI devices, the platform HAL contains an option “SPI devices” (CYGPKG_HAL_CORTEXM_STM32_BCM943364WCD1_SPI) which can be disabled. No other SPI devices are instantiated.

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 STM32 SPI device driver.

Flash Driver

The STM32's on-chip Flash may be programmed and managed using the Flash driver located in the “STM32 Flash memory support” (CYGPKG_DEVS_FLASH_STM32) 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 STM32 variant present on the BCM943364WCD1 module.

A number of other aspects of Flash driver behaviour can be configured within that driver, such as program/erase parallelism and program burst size. Consult the driver for more details.