An odd bug (c0951c9) in the NCS36510 ticker code caused the timer/ticker
classes to become desynchronized. Updated the handling to not assume the
timers are perfectly in synch. This will increase the event's tolerance of
less robust platforms.
The NCS36510 is limited to 16bit timers. Construction of larger
intervals is performed in software by counting the number of 16bit
intervals that pass.
Either this counting takes a bit of time, or there is a math error
somewhere (maybe a long critical section?), because there is a
roughly ~1us delay between when the interrupt occurs and the ticker
progresses onto the next 16bit interval. This is normally a completely
reasonable error, except that the error accumulates. After a while,
the equeue tests find themselves with tens of milliseconds of error.
To make matters worse, this error is random because of other interrupts
occuring in the system, making the exact issue quite a bit difficult
to track down.
This fix drops the software counter in favor of just recalculating
the next delay interval from the target time and value of the running
timer. The running timer used to calculate the current tick is left to
overflow in hardware and doesn't have this drift.
The zipping function of the exporters would unconditionally add all
files scanned by scan resources to a zip, including all of the files
associated with each feature. This would conflict with
`build_api.scan_resources` adding all of the files to the resources
object that correspond to the enabled features. To resolve this
difference in behavior, I made the zipping function oblivious to
features and had the upper level function, which has access to the
target configuration, do the proper merging.
In case of prescaler_rank was 0, a -1 index was being used,
which resulted in initialization of the Init.BaudRatePrescaler with
random values.
Now let's better check index and avoid -1 operation, so that prescaler_rank
can be only from 0 to "last_index".
In sendto(), memory allocation failures were mistakenly being treated as
would blocks (assumption was that the device might be able to recover).
However, that put the blocking socket into deep sleep and there was no mechanism to wake it up
ever again. Somehow that got slipped through testing. Fixed in this amenment
MBED_CONF_PLATFORM_STDIO_CONVERT_NEWLINES was not used in mbed_error_vfprintf causing wrong behavior when the option was selected (no new line is some terminals like putty).
As a result of major overhaul in Nanostack generally for socket API and especially
for TCP, the adaptation layer for mbed-OS is being upgraded.
Previously, as nanostack was not able to provide receive queue, adaptation layer had been
faking it. Now with Stream Socket by default Nanostack provides 2K receive queue and 2K send queue.
Receive queue size can be changed using setsockopt(). Batre metal nanostack would not provide with any
receive queues with Datagram Socket, however in this adaptation layer we introduce a 2K receive queue size
for the Datagram Socket as well.
Layer state machine handling is polished to ensure robustness.
::socket_connect() will can return 2 new error codes now. NSAPI_ERROR_ALREADY (like posix EALREADY) in case
if the connection is in progress or NSAPI_ERROR_IS_CONNECTED (like posix EISCONN) if already connected.
NSAPI_ERROR_WOULDBLOCK is now mapped directly to nanostack NS_WOULDBLOCK.
NanostackLockGaurd class is introduced which enables us to claim and release mutex using RAII style.
Add MBED_APP_START and MBED_APP_SIZE to the Odin's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Add MBED_APP_START and MBED_APP_SIZE to the stm32f429's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Add MBED_APP_START and MBED_APP_SIZE to the K64F's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Before, `make_gcc_arm` would export a makefile with both linker flags in
the `$(LD)` make variable and the `$(LD_FLAGS)` make variable. This only
affected GCC based makefiles, as the `$(LD)` make variable would only
contain the linker for both ARMC5 and IAR. This patch enforces the
`$(LD)` behavior of ARMC5 and IAR on all of the compilers by truncating
`$(LD)` to just the command
For toolchains that do not implicitly run the C pre-processor on their
linker scripts the toolchain is expected to define a `preproc`
attribute. The Makefiles then pick up on this attribute and add another
rule for pre-processing the linker script automatically.
This allows us to define parts of the linker script outside of the
linker script itself. In particular, we are interested in restricting
ROM to a subsection.
Christopher Haster
Indrek Ardel
Liviu Ionescu
ccli8
Jimmy Brisson
Amanda Butler
Sam Grove
adustm
Laurent MEUNIER
Hasnain Virk
0xc0170
Mika Leppänen
YarivCol
Seppo Takalo
Russ Butler
jeromecoutant
Martin Kojtal