Tested with a Lora radio application that used three GPIO lines to send
different interrupts from the radio module to the L052. Tested with a
Jeenode Zero Rev1
While the NOLOAD variant sometimes worked with some toolchains, the
version in the generator scripts could never work, as neither the
startup code, nor gdb know how to load those sections properly.
Originally added in: eb18cc19cb
The original scripts allowed you to place variables in eeprom space for
reading only. However, the last toolchain that generated working code
with this linker script was the gcc-arm-none-eabi-4_9-2014q4 release.
Subsequent releases treat the directives differently, and can lose track
of where variables are. One known symptom is constants getting bad
addresses, so for instance, "printf("asdfad")" will end up passing the
wrong address of the string constant into the eventual _write() call.
This commit removes the problematic directives until a more fully
correct system can be found that more properly follows the linker
script rules.
Attempts to helpfully unlock PECR when required in unlock_progmem and
unlock_option_bytes actually cause a bus error due to repeated unlocks,
as per ref manual and tedious experience. The better tested eeprom helper
routines unlock/lock in chunks, but that's not applicable for flash
writing.
Fixes: cf5fb002f6
Went awol merging something :(
(Yes, dwc_otg is theoretically shared with efm and co, but at present
it's still pretty much the stm32 version)
Fixes: 422d708384
The previous implementation of copy_from_pm assumed the destination buffer
was aligned on a 16-bit boundary. On M0/M0+ cores (stm32F0*, stm32L0*)
this causes a hard fault.
This implementation is from Kuldeep Dhaka's tree; it does a 16-bit copy
only if the destination buffer is aligned, otherwise a bytewise copy.
Fixes GH issues #401, #461
The f107 ethernet peripheral is the same as in f4, and was pulled out
into lib/ethernet/mac_stm32fxx7.c in 52758bb8fd
This drops the duplicate code.
Fixes Github issue #694
The TSVREFE bit is defined to only be present on ADC1, so drop the
pointless adc argument. This has the added benefit of making the
API consistent with all other STM32 adc parts.
Use same names as adv-v2 peripheral uses. F1 is the only v1 peripheral
adc that has calibration modes at all.
Old:
adc_calibration(ADC1); // blocking call
New (blocking):
adc_calibrate(ADC1);
New (asynch):
adc_calibrate_async(ADC1);
// do stuff
adc_is_calibrating(ADC1); // false when calibration finished
Old routines are preserved but marked deprecated for now.
Extract the calibration code from the f0, and share it with the other
adc-v2 peripheral users (f0,l0,f3,l4)
Uses the same naming set of is/async naming conventions requested by the
RTOS guys instead of having blocking only calls.
Old code:
adc_calibrate_start(ADC);
adc_calibrate_wait_finish(ADC);
New code (blocking):
adc_calibrate(ADC);
New code (asynch):
adc_calibrate_async(ADC);
// do stuff
adc_is_calibrating(ADC); // will be false when it's finished.
Old code for f0 is still available, but marked deprecated.
Fixes: 57c2b00a69
There was an issue with the pllp value calculation where the masking was done
in the wrong place. The pllp value was always equivalent to 2 (the bits were
always set to 0b00) which could result in an undesired system clock frequency.
When changing the system clock, you must take care to not exceed the
legal ranges based on voltage and flash wait states.
Existing code made it possible to provide a valid clock structure, that
would run out of bounds temporarily. Some boards would crash with
various Usage faults / Bus errors due to this.
These functions have existed since the initial commit, fallout from
copying an existing file and then trying to implement functions as
needed. F3 ADC doesn't have corresponding functions for some of these,
and this dead code should never have landed. Dropping it for clarity,
and also to stop confusing doxygen.
Start providing async routines for all blocking routines, to make it
easier to use libopencm3 in some RTOS environments. This is not in
anyway intended to be complete, this just covers a single blocking
routine, rcc_wait_for_osc_ready. Documentation added to the top level,
and provided for all stm32 families.
Thoughts: should this be a "sam0" family rather than samd? (Much like Atmel's
own software package lumps all the cortex-m0+ devices in one family)
This was enough to get a basic blinky working at least.
This is not strictly required, as this part is supported by the
devices.data linker script generator tool. However, as we're still in
migration for that tool, and this is the first time we're getting proper
lm3s(qemu) support, keep it for now.
This is common code for f0234, keep renaming files as has become standard, even
if it's a suboptimal solution. This doesn't rename the header which was not
renamed for f3.
Reported-by: https://github.com/gtoonstra
Newlib and arm-non-eabi-gcc likes to use the FPU by default on
Cortex-M4F chips. AS a result, do the right thing and enable the FPU
by default.
This fixes issues where code is generated which uses the FPU and
causes the CPU to hard-fault. This change removes the responsibility
of FPU initialization from the application code.
This makes the lm4f consistent with other M4+ devices that enable the
FPU in core library startup code.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Original implementation only checked whether the user had _selected_ the
clock, not whether it had actually switched to the clock or not. For
almost all cases, this made this function either a no-op, if you _had_
selected the clock, or a blocking loop if you hadn't selected it ahead
of time.
Fixes github issue #687
This was inspired by an Arch Linux provided ARM GCC 5.3.0 bug:
It gave an
"internal compiler error: in expand_expr_addr_expr_1, at expr.c:7736"
with the array version of the desig_get_unique_id.
While I was at it, fixed:
- a potential alignment issue with casting uint8_t* buf to uint32_t*
- a funny static in the string definition that does nothing (given const)
This reverts commit aa5e108553.
This commit was not meant to land yet, it should have gone for review, and
doesn't yet include all the parts it should touch.
replace bulky hardcoded wait for set and wait for clear with a single asynch
routine. Leave the blocking routines in for compatibility at this point.
NOUP: should be added to other rcc.c files too.
Helpful if you don't like seeing:
(gdb) vecstate
HardFault: forced due to escalated or disabled configurable fault (see below)
UsageFault due to access to disabled/absent coprocessor
L4 and F3 actually have the same bits to write in the same order, but F3 hides
the name of the deep power down bit. Keep the like that for now, but there's a
standard API for enabling and disabling the regulator.
Now that the big pieces of the adc-v2 common files are in place, start
including l0 in the builds. This includes only the very very basic core v2
peripheral functions, and the very basic definitions.
The adc v2 periph has the same register map, but comes in two flavours, one
supporting injected channels, more watchdogs, per channel sampling times and
so on, and one "simple" version.
Pull up the f3 and f0 portions into the appropriate files, after comparing with
L0 and L4 reference manuals, even if those are not fully landed yet.
The f0, f30x and l0 have a very similar "v2" adc peripheral.
Start extracting out some of the common code, and fix the glaring bug in
adc_power_down that was affecting them both.
This is not intended to be a fully comprehensive extraction, just the first
easy steps.
The adc peripheral on F30x is the same as F0, L0 and L4. In the reference
manuals, the following names are used.
F3: CFGR (no CFGR2)
F0 and L0: CFGR1 and CFGR2
L4: CFGR and CFGR2
Moving to a single consistent name, that's more likely to be inline with future
part numbers makes it much easier to extract common driver code for the
peripheral.
While all bit defines are moved to the CFGR1 style, core register definitions:
ADC_CFGR(adc) and ADCx_CFGR are kept to match the original register name in the
reference manual.
Fixes Github issue #548
All defined bits are rc_w0.
The paranoid version of this would write 0 to the reserved bits (0 is the
"reset value"), but this would require knowing which flags are valid on the
actual platform, and adding the corresponding macros.
Connectivity line devices have more remaps available, and the existing code was
artificially and needlessly preventing those remaps from being set, even if
defined.
While implementing this, the existing code to handle SWJ remap was found to be
inconsistent with the reference manual and has been fixed.
Fixes github issue #369
DESIG_FLASH_SIZE is provided for all stm32 parts in desig.h, correctly defined
as 16bits. Remove the incorrect duplicate definition within the f1 flash
handling code.
Fixes github issues #621
Recent debian testing and ubuntu 15.10 releases contain a
gcc-arm-none-eabi toolchain that returns 0 for the test with -mcpu and
-fsyntax-only, despite not actually supporting cortex-m7. They then
failed hard on actual compilation steps.
Use the --help=target output instead. tested with old g-a-e 4.7 and
newer releases.
Fails when the mutex was already locked.
Implemented zyp's fix for broken mutex. If it's 1 (= failure) by default, the function works fine.
irc log for reference
```
<zyp> strex returns 1 if it fails, 0 if it's successful
<zyp> but if the mutex is already locked, line 57 skips the status update and status gets remains at the initial value which means successful, which is wrong
<zyp> changing line 54 to status = 1 should do the trick
```
As done by esden for the F4, remove typedefs and add prefixes to clock enums
This extends this to all stm32 families.
Let's not hide the fact that these variables are structs/enums.
We are filling up the namespace badly enough, we should be prefixing as
much as we can with the module names at least. As users we already run
often enough in namespace colisions we don't have to make it worse.
* CLOCK_3V3_xxx enums renamed to RCC_CLOCK_3V3_xxx
* clock enums (PLL, HSI, HSE ...) prefixed with RCC_
* scale enum of pwr module prefixed with PWR_
Let's not hide the fact that these variables are structs/enums.
We are filling up the namespace badly enough, we should be prefixing as
much as we can with the module names at least. As users we already run
often enough in namespace colisions we don't have to make it worse.
* CLOCK_3V3_xxx enums renamed to RCC_CLOCK_3V3_xxx
* clock enums (PLL, HSI, HSE ...) prefixed with RCC_
* scale enum of pwr module prefixed with PWR_
These prototypes affect functions defined by application code. Only
the implementations in libopencm3 are supposed to be weak; the
functions in application code should definitely not be. Otherwise,
you'll end up with two weak symbols being linked together, and
it's luck as to which one the linker picks.
Just the basic core common functionality gained for free by being a common
peripheral. Enough for a miniblink.
Fixes some errors in the GPIO memory map. ST's naming of AHB2 vs AHB3 is
confusing.
Values from RM0351rev1, with the correction of the duplicate TIM1_CC entry.
Only stub support so far, but this opens up the beginning of build testing.
After adding support to the f3, add missing doxygen support to the f0
equivalent. This improves things and keeps them consistent until/if they are
pulled out as common code.
Based on the f0 support, which has identical functionality, but with doxygen
added. Bits renamed as they are only HSE prediv on some targets, and makes
things more consistent with the f0.
Fixes part of github issue #560
This function was badly copied and pasted from the f4 library, where there are
two functions, rcc_set_main_pll_hsi and rcc_set_main_pll_hse which combine
source, multipliers, dividers and other pll factors.
On F3, (not all of them, but the ones we support now), the function as
implemented has nothing to do with hsi / hse, and instead is simply selecting
the PLL multiplier.
Copypasta from f4 rcc code was only modified to shift the result, but not clear
the existing settings properly. Add mask/shift definitions and use them
properly.
The filename has always been wrong, "6" is a temperature grade, but f405 and
f407 are in the same datasheet, and all have the 64k CCM. Add it to the linker
script.
Was only in the (obviously out of date) documented example and as a
declaration. No implementations. Dropping immediately, but documentation
still needs further work.
Most changes are noise from doxygen.
Readme udpated to explain newer FP_FLAGS for m7
stm32f7 library is skipped if the toolchain doesn't support it yet.
Renamed every instance of variable CFLAGS in target specific Makefiles
to TGT_CFLAGS to free up CFLAGS for user defined compiler flags.
Added information in README.md about existence and usage of CFLAGS
environment variable in build process.
Control transfers can transfer less than was requested by the host in the
wLength field. if this short transfer is a multiple of the endpoint's packet
size, a zero length packet must be sent.
Adds tests for a range of control transfer IN requests, and properly supports
this in the core. Based heavily on work by Kuldeep Dhaka.
See https://github.com/libopencm3/libopencm3/pull/505
and https://github.com/libopencm3/libopencm3/pull/194 for original discussion.
Tested with stm32f4, stm32f103 and stm32l053.
Based on previous work, add a new driver for the v2 usb peripheral found on
stm32f0 and l0 devices.
Correspondingly, add a usb gadget zero test suite for the f0. L0 device level
code isn't yet ready, but will add the test case when it moves in.
Work by Frantisek Burian, Kuldeep
Singh Dhaka, Robin Kreis, fenugrec and zyp on irc, and all those forgotten.
The breaking changes here changes in header location, and changes in driver
name passed down to the usb stack.
Changes affect: stm32f102/f103, stm32l1, and some f3 parts
* instead of the confusingly generic "usb" use the name "st_usbfs" for the USB
Full speed peripheral ST provides in a variety of their stm32 products.
Include directives should change as:
#include <libopencm3/stm32/usb.h> => <libopencm3/stm32/st_usbfs.h>
* instead of the confusingly specific "f103" name for the driver, use
"st_usbfs_v1" [BREAKING_CHANGE]
Instead of:
usbd_init(&stm32f103_usb_driver, .....) ==>
usbd_init(&st_usbfs_v1_usb_driver, .....) ==>
The purpose of these changes is to reduce some confusion around naming, but
primarily to prepare for the "v2" peripheral available on stm32f0/l0 and some
f3 devices.
Work by Frantisek Burian, Kuldeep Singh Dhaka, Robin Kreis, fenugrec and zyp
on irc, and all those forgotten.
Setting the same configuration again should act as a lightweight reset, not be
ignored. This resulted in data toggle bits not being reset and alternet
settings not being reset.
Further, completely invalid configurations were accepted, when they should have
result in a stall. (Section 9.4.7 of USB 2.0 spec)
fixes Github issue #302
Tested-by: Karl Palsson <karlp@tweak.net.au>
By adding an "eep" memory section, and a NOLOAD step into the linker
scripts, you can now let gcc allocate variables in eeprom for you.
However, as fitting for eeprom, they cannot be initialized, and will not
be loaded at any time. This simply lets you get place variables in the
eeprom space.
Example:
struct whatever __attribute__((section(".eeprom"))) blah;
struct another __attribute__((section(".eeprom"))) wop;
printf("%#x", &blah); // ==> 0x08080000
printf("%#x", &wop); // ==> 0x08080000 + sizeof(blah)
You can read directly out of these variables, but need to use the
eeprom_ routines for writing to them.
We haven't yet moved everything over to any autogenerated linker scripts, so
include more common templates instead of proliferating mountains of them in
every example.
* USB host register definitions added.
* Extracted common register and bitfield definitions
from 'otg_fs.h' and 'otg_hs.h'
into new file 'otg_common.h'.
Modified usb low-level drivers to adopt to new style of bitfields.
* Fixed typo OTG_GOTGIN -> OTG_GOTGINT (according to the datasheet)
Signed-off-by: Amir Hammad <amir.hammad@hotmail.com>
SCB.CCR.STKALIGN enables the automatic aligning of the stack pointer to 8 bytes
on interrupt entry. Per ARM recommendations, and for AAPCS compliance, this
bit should be enabled at all times. ARMv6M has this hardcoded to 1. Cortex M3
has this broken in rev 0, optional (default off) in rev 1, and optional
(default on) in rev 2 and later. M4(f) has optional (default on) for all
revisions, M7 has hardcoded to 1.
See Section 2.3.3 in ARM document IHI0046B:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0046b/IHI0046B_ABI_Advisory_1.pdf
To ensure that all parts behave correctly, we make sure that we hardcode the
feature on, for all parts. While not _required_ for anything other than rev1
cm3, inserting it into the common reset handler ensures no-one gets any
surprises.
Fixes Github issue #516
The existing rcc_clock_setup_pll only allowed HSI as the clock source, even
though the existing clock structure contains pll source variables.
Check this value, and switch to the corresponding clock source, rather than
blindly assuming that we are tryign to operate from HSI.
(probably because the Ref Manual erroneously required it).
This has a naughty side-effect in that unrelated user data in the BD would be wiped.
Replaced this call by clearing the RTC registers to their default values.
Tested with ET-STAMP-STM32 to verify RTC starts from power-on and reset with expected behaviour.
This removes the shift from the defines, and includes them in the helper
function, making the code match the documentation, and following how the
rest of the library commonly operates.
Code using the existing defines will continue to work.
Basic helpers to at least support common configurations for the f401.
Original submission specified 5 wait states, but the reference manual and other
reviewers all believe that 2ws is sufficient for these modes.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
This makes it easier to read for most people, and makes it substantially
easier to review changes in the function signatures themselves at a
later date.
The f3 adc has separate bits for end of conversion and end of sequence.
Support those fully, with the regular enable/disable irq methods, and
the flag checking methods.
Discovered in github bug: #493
Karl Palsson