The nRF RTC driver, which is used a system clock driver due to the lack
of SysTick hardware on the SoC, was using too much CPU time in its
_timer_idle_exit() implementation due to the use of 64-bit arithmetical
operations. This was causing the ISR wrapper to add excessive latency to
critical interrupts, causing BLE controller asserts.
This patch addresses the issue by using exclusively RTC ticks instead of
OS ticks, thus avoiding the necessity to convert during
_timer_idle_exit() calls, which are the most critical to interrupt
latency.
In addition the driver is now able to detect setting tick events in the
past due to it being interrupted by a higher priority context, and will
reschedule and trigger the ISR at the same time.
Change-id: I56a3be96b9fdd554c3650012d647af2f0415eb8a
Signed-off-by: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Adds extern "C" { } blocks to header files so that they can be
safely used by C++ applications.
Change-Id: I767a04635b38d8ef7a02e8c7da3a5c99b0bc7709
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
There are static initializer macros available for most kernel objects
which we should use whenever possible.
Change-Id: I496f4d05d26801eddd21fae53bdd4fcdc3246fe3
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This adds H7 function implementation and test based on sample data
from Core Specification 5.0 Vol 3. Part H. Appendix D.8.
Jira: ZEP-1431
Change-Id: I49d44ee7a352d1092f6379829d747c7e0ec5e83c
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
RFCOMM channel range is 1 - 30, 0 and 31 shall not be used since
the corresponding DLCIs are reserved in GSM.
Change-Id: I63ff188e06007208b629a3e3bc22681c0bad239b
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Reduce the time limit for active clock startup and increase
the CPU usage time limit before hard real-time radio
transmit/receive.
Due to isr_wrapper overhead in ARM architectures, more time
was used before hard real-time radio transmission or
reception which was detected by controller implementation
and the controller aborted the radio transactions.
This commit permits more CPU utilization by the controller
before hard real-time radio transactions start.
Change-Id: Id976add80c70cabc753c43dfac6f6603588458d9
Signed-off-by: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>
On CPUs like nRF51 which run at 16MHz, certain BLE control
procedure PDU processing take more CPU time than permitted
inside tIFS (150us). Current implementation of Data Length
Update procedure does not span over multiple connection
interval (unlike Encryption Setup, which is another control
procedure processing that would consume more CPU time)
hence taking more CPU time inside tIFS on nRF51.
During the radio ISR, the active clock and packet timer are
active and it is used to profile the CPU time taken which
is used to decide on whether there is sufficient time in
the current radio event to process the control packet.
This commit also fixes a potential bug that would cause
disconnection due to MIC failure on encrypted connections
that performed Data Length Update. Controller used to NACK
the request/response PDU if it was not in a state to resize
the receive buffers but did not reset the CCM counter. This
is now fixed by the change done to NACK control PDU based
on available CPU time in radio ISR.
Change-id: Id58322ad76a0dbc284738cdd9a7c0437c9e8c423
Signed-off-by: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>
"next" is more relevant since its used to save next pointer
Change-Id: Ic0a8d543944681ba4291c5aa06125f565ab6115c
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
The function is not particularly small, and is used from several
places, so remove the inline declaration. This also prepares the way
for the possibility of having an application callback for letting the
application choose whether it's fine with the proposed parameters, and
thereby influence the response we send to the remote device.
Change-Id: I5848b179318b6fb6ee37fcbd479a919204f559f1
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that all logging methods use printk as a backend the respective
Kconfig options should declare the right dependencies.
Change-Id: I65c759db0ec7ba6333b76d8d20aea0e374fd4947
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Moved all libc Kconfigs to where the code is and remove the default
Kconfig for selecting the minimal libc. Minimal libc is now the default
if nothing else is configured in.
Removed the options for extended libc, this obviously was restricting
features in the minimal libc without a good reason, most of the
functions are available directly when using newlib, so there is no
reason why we need to restrict those in minimal libc.
Jira: ZEP-1440
Change-Id: If0a3adf4314e2ebdf0e139dee3eb4f47ce07aa89
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
For very constrained systems, like bootloaders.
Only the main thread is available, so a main() function must be
provided. Kernel objects where pending is in play will not behave as
expected, since the main thread cannot pend, it being the only thread in
the system. Usage of objects should be limited to using K_NO_WAIT as the
timeout parameter, effectively polling on the object.
Change-Id: Iae0261daa98bff388dc482797cde69f94e2e95cc
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
- does not pull in printk(), for potential footprint gain
- does not pull in k_thread_abort(), for single-threaded systems
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Change-Id: Ibc6a198b81a6cd73117d1e85aa05b92a4501a34d
A thread cannot have a coop priority in this case. It turns out a
priority is not needed when a thread is not inserted in the ready queue,
which is the case with the dummy thread.
The comment was also out-of-date, since it referred to a nanokernel
concept.
Change-Id: Id117501164bd72383d53f3df13030cf95dadc38b
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Some kernel operations, like scheduler locking can be optmized out,
since coop threads lock the scheduler by their very nature. Also, the
interrupt exit path for all architecture does not have to do any
rescheduling, again by the nature of non-preemptible threads.
Change-Id: I270e926df3ce46e11d77270330f2f4b463971763
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
nano_cpu_idle/nano_cpu_atomic_idle were not ported to the unified
kernel, and only the old APIs were available. There was no real impact
since, in the unified kernel, only the idle thread should really be
doing power management. However, with a single-threaded kernel, these
functions can be useful again.
The kernel internals now make use of these APIs instead of the legacy
ones.
Change-Id: Ie8a6396ba378d3ddda27b8dd32fa4711bf53eb36
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The numbers of timeouts that expire on a given tick is arbitrary. When
handling them, interrupts were locked, which prevented higher-priority
interrupts from preempting the system clock timer handler.
Instead of looping on the list of timeouts, which needs interrupts being
locked since it can be manipulated at interrupt level, timeouts are
dequeued one by one, unlocking interrupts between each, and put on a
local 'expired' queue that is drained subsequently, with interrupts
unlocked. This scheme uses the fact that no timeout can be prepended
onto the timeout queue while expired timeouts are getting removed from
it, since adding a timeout of 0 is prohibited.
Timer handlers now run with interrupts unlocked: the previous behaviour
added potentially horrible non-determinism to the handling of timeouts.
Change-Id: I709085134029ea2ad73e167dc915b956114e14c2
Signed-off-by: Benjamin Walsh <walsh.benj@gmail.com>
The format string passed to printk is trusted, and this is just sample
code anyway.
Change-Id: I267e1e3a9b6720c4216624bf0c2590ce42c6c681
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Not a functional bug per-se since they resolve to the same thing, but a
conceptual error nonetheless.
Change-Id: Ia11f6bd272cabe8da21d59e3378b8348f034e814
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
These tick computation can take a significant amount of time, and there
is no reason to do them with interrupts locked.
Change-Id: I2d8803ec6025b827e9450fa493084bbf8be98bad
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Use _INACTIVE instead of hardcoding -1.
_EXPIRED is defined as -2 and will be used for an improvement so that
interrupts are not locked for a non-deterministic amount of time while
handling expired timeouts.
_abort_timeout/_abort_thread_timeout return _INACTIVE instead of -1 if
the timeout has already been disabled.
Change-Id: If99226ff316a62c27b2a2e4e874388c3c44a8aeb
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The way the ready thread cache was implemented caused it to not always
be "hot", i.e. there could be some misses, which happened when the
cached thread was taken out of the ready queue. When that happened, it
was not replaced immediately, since doing so could mean that the
replacement might not run because the flow could be interrupted and
another thread could take its place. This was the more conservative
approach that insured that moving a thread to the cache would never be
wasted.
However, this caused two problems:
1. The cache could not be refilled until another thread context-switched
in, since there was no thread in the cache to compare priorities
against.
2. Interrupt exit code would always have to call into C to find what
thread to run when the current thread was not coop and did not have the
scheduler locked. Furthermore, it was possible for this code path to
encounter a cold cache and then it had to find out what thread to run
the long way.
To fix this, filling the cache is now more aggressive, i.e. the next
thread to put in the cache is found even in the case the current cached
thread is context-switched out. This ensures the interrupt exit code is
much faster on the slow path. In addition, since finding the next thread
to run is now always "get it from the cache", which is a simple fetch
from memory (_kernel.ready_q.cache), there is no need to call the more
complex C code.
On the ARM FRDM K64F board, this improvement is seen:
Before:
1- Measure time to switch from ISR back to interrupted task
switching time is 215 tcs = 1791 nsec
2- Measure time from ISR to executing a different task (rescheduled)
switch time is 315 tcs = 2625 nsec
After:
1- Measure time to switch from ISR back to interrupted task
switching time is 130 tcs = 1083 nsec
2- Measure time from ISR to executing a different task (rescheduled)
switch time is 225 tcs = 1875 nsec
These are the most dramatic improvements, but most of the numbers
generated by the latency_measure test are improved.
Fixes ZEP-1401.
Change-Id: I2eaac147048b1ec71a93bd0a285e743a39533973
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The Cortex-M3/4 kernel was reserving priorities 0 and 1 for itself, but
was not registering any exception on priority 0. Only reserve priority 0
and use it for SVC and fault exceptions instead of priority 1.
Change-Id: Iff2405e27fd4bed4e49ab90ec2ae984f2c0a83a6
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
There are now three flags that decide how many priorities are reserved
by the kernel, each one requiring one priority level: Zero Latency
Interrupts, BASEPRI locking (for SVC usage) and faults that are not at
priority -1, so that taking them in an ISR actually triggers the fault
synchronously.
Change-Id: I7f4d760c9110051aeb82dcfd8cd68026a9b74b54
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Cortex-M0/M0+ do not have other faults than the hard fault at priority
-1, so they do not need to reserve a priority to allow exceptions to
trigger during handling of ISRs.
Change-Id: I479e439f7bcac70b4b2b787bcd744a4c65437e80
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
This allows using it in _EXC_PRIO() instead of hardcoding 2 and 3.
Change-Id: I3549be54602643e06823ba63beb6a6992f39f776
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Use it to flag which CPUs can do zero latency interrupts, which depend
on being able to lock up to a specific interrupt priority.
Change-Id: I09f71366ea1d05486e38c513a09abc270884879f
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Fixes this:
error: ‘zero_addr’ defined but not used [-Werror=unused-const-variable=]
...
Change-Id: I5b0baf597e62f3206e15638a63e129503b76b048
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is a left-over that should have been renamed to the new
net_buf_alloc_debug function name.
Change-Id: Iefcbd2eefab5614b1b80214cb0927f3db77d592e
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When going into DEEP_SLEEP mode, the ARC core now saves
its context. This includes:
- All core registers
- Stack pointer
- Program counter (restored by jumping to the restore code)
The arc reset code now checks if the GPS0 bit 2 is set.
This is similar to the behavior of the x86 core done by
the QMSI bootloader which is setting GPS0 bit 1 in order
to call the restore path instead of cold boot path.
The sample has been adapted in order to support the ARC.
Jira: ZEP-1222
Change-Id: I375f03b16b8a5fd1f07ead55cf7e4947d6290c9f
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
When going into DEEP_SLEEP state, the ARC timer
needs to be restored.
This implements the function to restore the timer
after sleep.
As the time spent during sleep is not currently known,
the timer is expired to reschedule the application task.
Jira: ZEP-1224
Change-Id: I22a30d0fd79f177cf166b9a29dc78d68f7d7fbad
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
In order to resume the ARC from deep sleep,
the interrupts need to be restored.
The FIRQ stack needs to be saved and restored
when performing sleep operations.
During early initialization, the sp in the 2nd register bank
is made to refer to _firq_stack.
This allows for the FIRQ handler to use its own stack.
Fast Interrupts cannot be used after sleep if this information
is not restored.
This patch adds the suspend and resume functions.
Jira: ZEP-1223
Change-Id: Ic81980f05aee6c1f7b8c46c743f2648c65b29486
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
Move interrupt initialization for the ARC to its own
device. The init function for the arc will be only
doing platform specific operations
Jira: ZEP-1288
Change-Id: Icb04c3622890021c65cd24cecf6cafee6c37caf9
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
Following commit fc21a76db6
Some more fixes are needed.
Change-Id: I19c2c979d44be5edfd76041d3cf4507860795c78
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Using a LIFO instead of a FIFO has the potential benefit that more
recently in-use buffers may be "cache-hot" and therefore accessed
faster than least recently used (which is what we get with a FIFO).
Change-Id: I59bb083ca2e00d0d404406540f7db216742a27cf
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Since the user data size is now stored in the pool there's very little
value in storing it as well per-buffer.
Change-Id: I17a99123b232423c52a2179b4eccd813728d51b1
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
