Moved "stm32l1xx_hal_conf.h" to target folder. This file is part of
STM32CubeL1, and this is the way it is done for the 95 examples supplied
with STM32CubeL1. This file should be part of project(target) folder,
not API. On mbed, this has been done for TARGET_STM32F4 and
TARGET_STM32F7 targets (in ../targets/cmsis/TARGET_STM folder). All
targets in these two folders already have the "stm32l1xx_hal_conf.h"
file in the target folder.
Root cause: you cannot use a C-enum name in a #if compare, becaudse the preprocessor will replace all enum names with 0 (so all checks on HFXO/LFXO checked out regardless of the define).
The warning message is shown as below.
Compile: Thread.cpp
[Warning] Thread.cpp@45: In constructor 'rtos::Thread::Thread(void (*)(const void*), void*, osPriority, uint32_t, unsigned char*)':
comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-off-by: Jun-Ru Chang <jrjang@gmail.com>
Since some Nordic platforms don't use an external clock source, they
need to be built with the TARGET_NRF_LFCLK_RC flag. If they don't,
SystemInit will wait indefinitely for an external clock to start.
This patch adds a 1s timeout to the external oscillator initialisation,
and falls back to using the internal RC one if no LFCLKSTARTED event was
received in this interval.
For most applications, this won't matter. When building for the wrong
Nordic target, pin numbers will be mixed up as well and the application
will break later on.
But on targets that can only be updated using FOTA and don't have an
interface chip, this patch avoid ending up with a bricked device after a
slight mistake. Indeed, BLE DFU service is portable across all boards
and will run even with a mixed-up target setup, allowing the user to
re-install the right application.
An example scenario is transferring an application on a standalone
NRF51 chip, after spending some time prototyping on an mKIT, which tends
to happen a bit too often...
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
This patch clears the EVENT_COMPARE register even when we're not
expecting to get a COMPARE interrupt.
Here is a scenario where we get an unwelcome interrupt, and where it
currently results in a deadlock:
* A Ticker T1 runs at 500ms
* Its handler registers a Timeout T2 at 20µs. Since LF clock runs at
32.768kHz, this will be rounded up to a multiple of 30.5µs (actually
61µs, to ensure we're in the next tick window)
T1 T2 T1' T2'
-------|---|---------------------------------|---|--------->
: : :
<---> n * 30.5µs :
<--------------- 500ms --------------->
* When the ticker API handles T1, it calls us_ticker_set_interrupt a
first time for T1', and then for registering T2.
* Since T2 period is less than one RTC tick (30.5µs), there is a high
chance it will go past *while* we're still in this first handler.
* So ticker_irq_handler also handles T2 as well, and removes it from the
queue.
* us_ticker_set_interrupt is called for T1' before returning from
ticker_irq_handler
The problem resides in the fact that us_ticker_set_interrupt takes more
than 2 RTC ticks to execute: while inside the handler, T2 interrupt will
fire.
* Because of this pending interrupt, RTC1_IRQHandler will be called
right away, but since we removed T2 from the queue, the handler is
waiting for T1' instead, and will not clear EVENT_COMPARE until we
reach the T1' tick, in about 500ms.
* This results in a lock and main isn't executed anymore.
With this patch, we avoid being stuck in RTC1_IRQHandler while waiting
for T1'.
Note: even when T2 isn't handled in the same loop as T1, we may get a
spurious interrupt, because us_ticker_set_interrupt will be called twice
for T2... and will register T2+m the second time, while T2 interrupt is
fired in the background.
That case isn't as harmful, since RTC1_IRQHandler will be waiting for
T2+m, which is only one or two ticks further, and then it won't be
called again before T1'.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Martin Kojtal
David H
Steven Cooreman
Jun-Ru Chang
Przemek Wirkus
Austin Blackstone
bcostm
Devan Lai
tomoyuki yamanaka
Kevin Gillespie
Jean-Philippe Brucker
sarahmarshy
unknown
Martin Simpson