When a ticker is scheduled to run so fast that it is pending again
before the previous event has been processed then this next event
is processed (recursively) by calling into us_ticker_irq_handle().
This can lead to a stack overflow.
This patch prevents this recursion by replacing the call to
us_ticker_irq_handler() with a call to set the interrupt to pending
again. This allows the next timer event to be processed without
making the stack deeper.
Add a delay after switching to the FEE clock mode so the FLL has a
chance to acquire a better lock. This fixes a bug where the first byte
sent over the UART is corrupt.
UART_IT_TC was enabled instead of UART_IT_TXE
This was causing an issue because UART_IT_TXE (and not UART_IT_TC) was disabled by same function.
Consequently if a transfer was ongoing when serial_irq_set() was called to disable IRQ, UART_IT_TC would still trigger (once).
Side effect is maybe speed: I guess using UART_IT_TC prevented implementation of continuous transfer.
This commit is focused on solving an issue observed with TARGET_STM32F4. It doesn't presume it should or shouldn't be done for other targets.
My previous commit, c6d2c81, broke Keil builds and maybe even IAR.
I need to learn how to read C code :) I thought I was masking off the
O_BINARY bit only for GCC builds but it turns out that my update was
in the fall-through case for all toolchains. This commit now places
the O_BINARY masking operation into a GCC specific #ifdef clause.
Testing:
I tested the same fopen("/local/out.txt","rb") code as before but this
time I built it with the online compiler and GCC_ARM. I tested the
resulting binaries on mbed-LPC11U24 and mbed-LPC1768 boards.
Thanks to @neilt6 for catching & reporting this!
Fixes issue #1562 reported by @justbuchanan.
When building code with GCC-ARM / newlib, attempting to use the
b (binary) mode in a fopen() call would fail. newlib would parse
this option and pass it down to the LocalFileSystem open call which
didn't like the unexpected O_BINARY flag in openmode.
The openmode_to_posix() function in retarget.cpp would never set the
O_BINARY flag for the other toolchains but for GCC it would just pass
down whatever newlib placed there. This commit masks out the O_BINARY
bit so that it never gets passed down to the file system drivers, just
as occurs for the other supported toolchains.
Test case:
FILE *fp = fopen("/local/out.txt", "rb");
I tested that code on mbed LPC1768 and LPC11U24 boards while using
GCC_ARM as the toolchain. It failed on both platforms previous to
this change and succeeded there after.
dbestm
Russ Butler
Martin Kojtal
ducky64
bcostm
Russ Butler
Mike Fiore
tomoyuki yamanaka
Arnaud RICHARD
sunsmilearm
Xiao Sun
Adam Green
neilt6
adustm
Toyomasa Watarai