Pin layout and header files for the STM32 H103 prototype board from
Olimex featuring an STM32F103RBT6 chip. This commit contains all
necessary changes to compile with BOARD=olimex_stm32_h103.
Signed-off-by: David Kiliani <mail@davidkiliani.de>
Add new common.inc, which is common_rom.inc with some
DEFINED(_FLASH_BUILD) usages thrown in to allow for RAM builds. It
also uses a new REGION_RODATA region alias for read-only data.
Move section .USER_FLASH to REGION_RODATA. This means it lives in RAM
under RAM builds. Although this might be surprising, not doing so
would make RAM builds useless.
Modify the individual board linker scripts to properly set
REGION_RODATA and _FLASH_BUILD before calling out to common.inc.
Delete common_rom.inc, common_ram.inc, common_header.inc, in favor of
common.inc. This should fix RAM builds on all boards.
Comment the Makefile more verbosely. It's been causing confusion on
the forums.
Add target-config.mk, this contains build configuration depending on
the BOARD and MEMORY_TARGET variables. Its contents were cluttering
up the Makefile and making it harder to read.
Specify _lm_heap_start and _lm_heap_end in Maple Native's linker
scripts to point respectively to beginning and end of FSMC-mapped
external SRAM chip addresses.
- common_header.inc: Declare EXTERN symbols _lm_heap_start and
_lm_heap_end.
- common_rom.inc: Check for _lm_heap_start and _lm_heap_end. If they
are defined, preserve their values. Otherwise, _lm_heap_start is
starts after .bss, and _lm_heap_end is the end of SRAM.
This allows existing linker scripts to continue using the old heap
scheme, but allows for customizability elsewhere.
- syscalls.c: Respect the addresses of _lm_heap_start and _lm_heap_end
as the boundaries of the heap in _sbrk().
Use region aliases in common_ram.inc, common_rom.inc. These are
provided by the individual board scripts which include these. Note
that the aliases have horrible names. We'll need to fix that up.
The linker scripts share an initial section. Factor this out into a
new file common_header.inc, and have the main linker scripts include
this file. Apart from eliminating a redundancy, this will make it
easier to add new linker scripts in the future.
Doxygen refuses to trust us when we \def something that it doesn't
notice as a #define. To work around this, we put
__DOXYGEN_PREDEFINED_HACK into our Doxyfile's PREDEFINED, so that
documentation may be inserted for #defines which we know will exist.
libmaple/dma.c defines DMA interrupts __irq_dma_channel[1-7],
consistent with what is specified by support/ld/names.inc. However,
names.inc is inconsistent with what support/ld/libcs3_stm32_src/
expects. Specifically, it contradicts the files
- support/ld/libcs3_stm32_src/stm32_isrs.S
- support/ld/libcs3_stm32_src/stm32_vector_table.S
Which use the names __irq_dma1_channel[1-7].
Change names.inc and dma.c to use the correct IRQ names.
The original names.inc/libcs3_stm32_src inconsistency was introduced
in 43d6921658, but dma.c had the correct
names until ec3cf2903f, where they were
renamed for consistency with names.inc. At that point, DMA interrupts
stopped working. (This was documented in the commit message).
Thanks to forum user robodude666 for tracking this down.
The documentation covers topics not specifically relevant to libmaple,
so it doesn't make sense for it to be part of the libmaple source
distribution.
Delete the docs/ tree, and prepare libmaple for use with the new
leaflabs-docs repo, which will contain the docs from now on.
* README: update to reflect this change
* support/doxygen/Doxyfile: This is the old docs/Doxyfile
* Makefile: Add a doxygen target
* wirish/comm/HardwareSerial.h: fix reference to docs/. The comment
informing maintainers that the HardwareSerial interface is
documented by hand refers to the docs/ tree, which no longer exists.
Update it to refer to the separate leaflabs-docs repository.
* support/scripts/copy-to-ide: No longer build the documentation
1) Reset, halt, and unprotect the the flash before writing to it.
This fixes a bug in which every other flash attempt would fail.
2) Maple R5 and below have NRST and JTNRST erroneously tied together,
resulting in a full TAP and system reset when a reset is asserted.
This prevents the 'reset halt' command from working.
This can be fixed hard-hack style by cutting the trace out of JTNRST.
Users of the Leaf Maple JTAG adapter will also need to cut the trace
between TRST and SRST.
3) Assuming you have a functioning 'reset halt' setup (see 2),
the 'make debug' command now halts the chip and waits for a gdb
connection before proceeding execution.
Redirect thread-mode execution to a fail routine which throbs the LED to
indicate a hard fault. Because the fail routine runs in thread mode
with interrupts on, USB auto-reset should now work. Test by executing
some bogus instruction (e.g. *(volatile int*)0xf34fdaa = 0;) and check
that the auto-reset continues to work.
The USB reset scheme on OS X is unreliable. Adding a little bit of sleep
seems to make it much more reliable. This will probably do until we get
a chance to rewrite the USB stack and redo the whole auto-reset
scheme...
