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]