Reasons to remove TRNG support:
1. M252 just has 32KiB SRAM and cannot afford mbedtls application.
2. Implementing TRNG HAL with PRNG H/W has security concern.
Without free-up of peripheral pins, peripheral pins of the same peripheral may
share by multiple ports after port iteration, and this peripheral may fail with
pin interference.
In Nuvoton, only new-design chips support GPIO input pull-high/pull-low modes.
Targets not supporting this feature are listed below:
- NUMAKER_PFM_NANO130
- NUMAKER_PFM_NUC472
- NUMAKER_PFM_M453
Fix logic error on replying NACK at the end of transfer.
This is also to fix FPGA CI test mbed_hal_fpga_ci_test_shield-i2c/
i2c - test single byte read i2c API.
Better IP initialization sequence:
1. Configure IP pins
2. Select IP clock source and then enable it
3. Reset the IP (SYS_ResetModule)
NOTE1: IP reset takes effect regardless of IP clock. So it doesn't matter if
IP clock enable is before IP reset.
NOTE2: Non-configured pins may disturb IP's state, so IP pinout first and then
IP reset.
NOTE3: IP reset at the end of IP initialization sequence can cover unexpected
situation.
On Nuvoton targets, lp_ticker_set_interrupt(...) needs around 3 lp-ticker
ticks to take effect. It may miss when current tick and match tick are very
close (see hal/LowPowerTickerWrapper.cpp). Enlarge LPTICKER_DELAY_TICKS to
4 from 3 to address this boundary case.
Without this override, mpu hal will require 5 mpu regions which exceed 4 mpu
regions supported by M252 (see hal/mpu/mbed_mpu_v8m.c). In this scenario,
we will hit assert error but we actually meet stack overrun first due to just
0x400 bytes for emitting error message. The issue doesn’t occur on other
targets such as M487 because it has 8 mpu regions.
All current PSoC 6 targets support the same QSPI frequency and minimum
program size. So specify a single entry rather than duplicating for
each device.
This fixes the stack overflow error during the basic USB tests.
Update the ctrl_buf member of the USBTester and USBEndpointTester test
classes to be allocated on the heap. This saves 2 KB of a main stack.
The test floods the device with UDP requests (it skips the 100 ms delay to simulate instant timeout). ESP8266 starts responding with "busy p..." message. It needs more time to process the data and recover for subsequent tests.
Remove some (Cypress-proprietary) BSP interfaces and hardware initialization
from the BSPs which is better implemented by a library or application firmware.
Move some remaining functionality from common to the individual targets.
Don't malloc during wifi initialization, as that could cause double allocation in some cases.
The thread stack will be allocated by cy_rtos_thread_start if necessary.
When moving to the second heap region due to overflowing the first
region, the `_sbrk` implementation assumed the allocation would fit in
the second region, and didn't check for that overflowing too.
Problem revealed in `stats_heap` test with GCC 8 on K64F - the allocation
attempt for 1GiB crashed, as `_sbrk` indicated 1GiB was available at the
start of the second region.
second region.
Presumably older versions of newlib fault that allocation attempt before
passing to `_sbrk`.
While there, adjust the code to not use a separate static `bool`, saving
RAM. We can track with just one pointer, as order of the two regions is
fixed, and already relied on by newlib.
We get this compiler warning;
Compile [ 7.9%]: AT_CellularDevice.cpp
[Warning] AT_CellularDevice.cpp@206,18: variable 'err' set but not used [-Wunused-but-set-variable]
Due to the fact, that the code that would actually use this variable
is behind trace flags. Based on review feedback from Antti Kauppila and
Kimmo Väisänen, adding same flagging also for that.
- Reason being - the operation needs to be within the locks.
_ongoing_tx_msg was incorrectly initialized before _mlme_confirmation.
Fixes following build warning:
[Warning] LoRaMac.h@691,26: 'LoRaMac::_ongoing_tx_msg' will be initialized after [-Wreorder]
[Warning] LoRaMac.h@689,28: 'loramac_mlme_confirm_t LoRaMac::_mlme_confirmation' [-Wreorder]
[Warning] LoRaMac.cpp@68,1: when initialized here [-Wreorder]