LED support was dropped from the BU images due to a lack
of proper abstraction for LED definitions between CC and
CC3D HW variants in the CopterControl board family.
Use the new LED abstraction to hide board revision details
from the BU image so it can once again flash some LEDs.
CC and CC3D boards share the same FW image. This is accomplished
by checking the BOARD_REVISION field in the board_info_blob
that is stored in the BL partition in flash as we init the FW.
Make sure that the BU image only writes a BL image that has
the same BOARD_TYPE and BOARD_REVISION fields in the embedded
image as the ones currently in flash on the board.
This ensures that we never write a CC3D BL image onto a CC board
and vice versa. This check should prevent "bricking" a board.
hardware revision it cannot know which pios_led_cfg_ structure to use.
Possibly this should be abstracted further into board_hw_defs to create
functions like board_init_led.
Also the BU should probably compare the hw_revision of the original and new
bootloader to make sure the user doesn't break their board.
Bootloader updaters were all broken due to recent
changes in LED configuration handling. Removing
LED support from the BU loads allows them to build
again, but they provide no feedback about when they're
finished writing flash.
Board specific HW configuration is now collected in a single .c
file for each board. This HW configuration is #include'd into
the FW, BL and BU builds for each board.
These new .c files are found in:
flight/board_hw_defs/<board_name>/board_hw_defs.c
Parts of this information were previously duplicated between
the BL and FW builds. This commit cleans up the duplication.
Using a #include on a .c file is a bit ugly but it allows us
to ensure that all of the symbols in the board_hw_defs.c file
are *ONLY* used in the PIOS_Board_Init() function for each
software build.
The USE_BOOTLOADER compile flag was only being used
to determine where the ISR vector table was located.
Provide this explicitly from the linker since it knows
exactly where it is putting the ISR vector table.
- New macros for fw, bl and bu rules in top-level make
- Per-board info factored into make/board/*/board-info.mk
- Per-board info now shared btw. fw, bl and blupd for each board
- BOARD_TYPE, BOARD_REVISION, BOOTLOADER_VERSION, HW_TYPE
- MCU, CHIP, BOARD, MODEL, MODEL_SUFFIX
- START_OF_BL_CODE, START_OF_FW_CODE
- blupd_* goals renamed to bu_*
- all_blupd goal renamed to all_bu
- firmware goals renamed to fw_*, board name goals are preserved
- bu_*_program now writes updater to correct address for all boards
- BL updater firmware builds now produce .opf format including
version info blob.
- BL updater firmware name now includes board name.
- INS makefile brought up to date w.r.t. linker scripts
This change is made up of a number of tightly coupled
changes:
- Deprecate the use of the USE_BOOTLOADER command-line
option. It is now hard-coded in each Makefile.
Overriding it on the command line is not allowed.
- Split apart the memory declaration and the section
declaration in all linker files (*_memory.ld and
*_sections.ld).
- Describe the split between bootloader and app sections
of flash in each board's _memory.ld file.
- Change program target to selectively erase flash so
that the installed bootloader is preserved across even
JTAG programming operations.
- All elf files are built with debug symbols and are not
stripped. This should help debugging with gdb. The
images programmed on the boards are all .bin files now
which do not include symbols.
New targets:
- make blupd_all_clean
- make blupd_all
- make blupd_openpilot
- make blupd_ahrs
- make blupd_coptercontrol
- make blupd_pipxtreme
These targets are also included in the 'all_flight' target.
firmware include and delete all the extra foss-jtag config files. There is now
a legacy file for the revA board a second for AHRS that changes the port
Led(LED1 different color on each board) Sequence:
1-Power On
2-Led ON for 3 seconds (you can disconnect during this time - safety measure)
3-Led flashes very quickly while the board is being programed (because the program is stored in memory this is very fast and looks like a led glitch)
4-If all good - LED flashes 3 times with a 1sec period and turns off - you may now reboot.
4-If an error ocurred - LED will keep flashing with a 500ms period until power off
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2804 ebee16cc-31ac-478f-84a7-5cbb03baadba
