Name
Setup — Preparing the Broadcom BCM943364WCD1 for eCos Development
Overview
Given the limited available RAM memory, it is expected that the most
common development method is to use JTAG for development, either by
loading smaller applications into the on-chip SRAM, or by programming
larger applications directly into on-chip Flash. In the first case,
eCos applications should be configured for the SRAM
startup type, and in the second case for ROM
startup type.
Nevertheless, it is still possible to program a GDB stub ROM image
into on-chip Flash and download and debug via a serial UART, if pins
for the UART are available. In that case, eCos applications are
configured for RAM
startup and then downloaded and
run on the board via the debugger arm-eabi-gdb, or
via the Eclipse IDE. For serial communications, all versions run with
8 bits, no parity, and 1 stop bit at 115200 baud. This rate can be
changed in the eCos configuration used for building the GDB stub ROM
image.
HAL startup types
The following startup types may be selected for applications:
Configuration | Description |
---|---|
SRAM | Stand-alone programs running from on-chip SRAM, loaded via JTAG hardware debugger |
ROM | Stand-alone programs running from on-chip FLASH |
ROMAPP | Stand-alone programs running from an offset into the on-chip FLASH, that are started by a separate boot loader |
RAM | Programs loading via a GDB stub ROM into on-chip RAM, which rely on a debug monitor |
Further details are available later in this manual.
Programming ROM images
To program ROM startup applications into Flash, including the GDB stub ROM, a JTAG debugger that understands the STM32 flash may be used, such as the OpenOCD tool. The openocd GDB server can directly program flash based applications from the GDB load command.
For example, assuming that openocd is running on the same host as GDB, and is connected to the target board the following will program the “bootup.elf” application into the on-chip flash:
$arm-eabi-gdb install/bin/bootup.elf
GNU gdb (eCosCentric GNU tools 4.7.3g) 7.6.1 [ … GDB output elided … ] (gdb) target remote localhost:3333 hal_reset_vsr () atpath
/hal_misc.c:171 (gdb)load
Loading section .rom_vectors, size 0x14 lma 0x8000000 Loading section .text, size 0x3adc lma 0x8000018 Loading section .rodata, size 0x6c0 lma 0x8003af8 Loading section .data, size 0x6dc lma 0x80041b8 Start address 0x8000018, load size 18572 Transfer rate: 14 KB/sec, 4643 bytes/write. (gdb)
Alternatively, the openocd telnet interface can be
used to manually program the flash. By default
the openocd session provides a comand-line via
port 4444
. Consult the OpenOCD documentation for
more details if a non-default openocd configuration
is being used.
With a telnet connection established to the openocd any binary data can easily be written to the on-chip flash. e.g.
$telnet localhost 4444
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger >flash write_image test.bin 0x08000000
wrote 32518 bytes from file test.bin in 1.073942s (29.569 KiB/s)
To create a binary for flash programming the arm-eabi-objcopy command is used. This converts the, ELF format, linked application into a raw binary. For example:
$ arm-eabi-objcopy -O binary programname
programname
.bin
Rebuilding the GDB stub
Should it prove necessary to rebuild a GDB stub ROM binary, this is
done most conveniently at the command line. For
the bcm943364wcd1_evb
platform the steps needed
are:
$mkdir gdbstub_bcm943364wcd1_evb
$cd gdbstub_bcm943364wcd1_evb
$ecosconfig new bcm943364wcd1_evb stubs
[ … ecosconfig output elided … ] $ecosconfig tree
$make
At the end of the build,
the install/bin
subdirectory should contain the
file gdb_module.bin
. This may be
programmed to the board using the above procedure.
2024-12-10 | eCosPro Non-Commercial Public License |