If $(OPENCM3_DIR)/lib/libopencm3_*.a exists, it will be linked in.
If we do that, we should also add it to the deps.
That way a newer *.a will result in a relink.
To use this, you should add a dependency to $(LIBDEPS) where you are
using $(LDFLAGS) and $(LDLIBS) now.
eg, old (wouldn't relink if the library changed)
$(PROJECT).elf: $(OBJS) $(LDSCRIPT)
@printf " LD\t$@\n"
$(Q)$(LD) $(TGT_LDFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@
new (will relink when the library changes)
$(PROJECT).elf: $(OBJS) $(LDSCRIPT) $(LIBDEPS)
@printf " LD\t$@\n"
$(Q)$(LD) $(TGT_LDFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@
Tested-by: Karl Palsson <karlp@tweak.net.au>
Originally tracked via: https://github.com/libopencm3/libopencm3/pull/887
LPUART1 needs BRR to be 256 times the normal value.
Doing this with 64 bit math would work, but that pulls in quite a lot of
code for every platform, even if they don't have LPUART.
A little bit of maths, thanks to zyp on irc, lets us keep it in 32bit,
provided people don't try and use > 16MBaud on LPUARTs
Originally tracked via https://github.com/libopencm3/libopencm3/pull/888
We extracted code out to the common files, but they weren't being
linked. This didn't matter in the past, as they were empty.
Fixes: 46d4103c stm32: flash: move wait_for_last to f2/f4 explicitly.
Fixes: https://github.com/libopencm3/libopencm3/issues/953
Just a small typo I came across while trying to get MCO to work on my board.
The define is not used in any other files as far as I can tell, but of
course applications might break if they use the misspelt variant.
flash_clear_pgperr_flag is a name used on f247, which is actually most
analogous to the SIZERR bit on l4, (it's a parallelism error)
the bit being cleared originally in this function, PROGERR is a new bit,
and should have it's own name.
Add a function to handle the previously unhandled size/parallelism flag,
and rename the existing one to properly reflect it's new name.
This shows what is _actually_ different for f7. A couple of option
bits, and a renaming of bit 7 of the status register, from Program
Sequence Error to Erase Sequence Error.
We keep the separate implementation of wait_for_last_operation, to meet
the "suggestions" of the reference manual to insert a DSB instruction.
Keeping the renamed bit/functions also requires us to keep separate
implementations of the flag clearing functions
Move the last few register defines back to their relevant headers, add
doxygen and groups. While these registers _were_ "common" they were the
_only_ common things, so it's simpler for future work (merging f7 with
f2/4) to move them back separately.
F3's flash interface is actually quite different, don't try and force
sharing code that isn't really related. The "PGERR" is a very different
bit than the parallelism error that f2/4/7 have.
l4 is pages, not sectors, so update apis to be consistent. (other
families use page/sector as defined in the reference manual)
Make sure that pages on the second bank can also be erased. Use the
same style in use for f2/4/7 for sector numbers across banks.
Comments were not consistent, and this serves no purpose. There's no
reason to explicitly lock the flash first before unlocking. These bits
are simply set when the keys are written.
All the "f" type flash parts have an EOP flag, even if it's in different
bit positions. Add a header for this common functionality, and move
it's implementation to the existing common file.
Turns out, there's lots of common code for flash. Pull up prefetch
on/off to start with, as there's only a single bit name different.
Pull up the definitions of common API functions too, starting with
flash_set_ws. Even if the implementations are different, things that
meant to be the same, should be defined centrally.
The sector list is numerically contiguous, but the bits to write are not
contiguous. Good job ST.
Fixes: https://github.com/libopencm3/libopencm3/pull/934
Don't see any reason to make public definitions of these sorts of magic
numbers, they're completely internal to sector addressing.
- Change .power_save to .voltage_scale, a pwr_vos_scale enum
- Enable pwr clock before setting VOS scale
- Fix flash wait states
- Make flash_set_ws more robust
... since Clang doesn't infer the function type on '#pragma weak x = y'-style
declarations, and instead leaves it as "<overloaded function type>", thus
leading to a type conflict when assigning the ISRs to the interrupt vector.
This has no impact on normal use, but it makes it more compatible, nd
that's always a good thing.
Before (vector_nvic.c generated)
...
#pragma weak usart1_isr = blocking_handler
...
After:
...
void usart1_isr(void) __attribute__((weak, alias("blocking_handler")));
...
According to: https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/ARM-Function-Attributes.html
"Only basic asm statements can safely be included in naked functions (see Basic
Asm). While using extended asm or a mixture of basic asm and C code may appear
to work, they cannot be depended upon to work reliably and are not supported."
The reference manual is incorrect, the data sheet is correct.
There is 320K of ram (up to address 0x20050000). This has been
tested on the STM32F469I-disco board.
The LTDC include file was defined with combined bit
semantics and bit position. As a result instead of
LTDC_GCR_VSPOL which is the bit which defines vertical
sync polarity, this had been defined to be
LTDC_GCR_VSPOL_LOW (0) and LTDC_GCR_VSPOL_HIGH (non zero).
This sort of define makes it impossible to know ahead of
time what operation would set or reset the bit (some are
negative logic, others are postive logic, so affirmative
defines could mean either "set the bit" or "reset the bit"
I've added the non-semantic bit define so that it is clear
in my code if the bit is being set or reset.
Discussion took place at https://github.com/libopencm3/libopencm3/pull/889
We didn't actually mark it deprecated very well, but it was
non-functional, and simply a poorly implemented wrapper for
rcc_periph_reset_pulse() anyway.
It's now been obsoleted in the examples for more than a year, and it's
time to kill it outright.
Fixes: https://github.com/libopencm3/libopencm3/issues/709
Karl Palsson