Serial implementation uses different vector handlers for sync/async calls respectively. The issue can be reproduced with the following flow:
1. Register sync mode callback with Serial.attach().
2. Sync call with Serial.putc()/getc().
3. Change to async call with Serial.write()/read().
4. Change back to sync call with Serial.putc()/getc().
Now, vector handller is still for async mode, not for sync mode.
To fix it:
1. Introduce internal function serial_enable_interrupt() for both sync/async vector handler enable/disable.
Original HAL function serial_irq_set() is reduced to call it for sync mode vector handler enable/disable.
2. Introduce internal function serial_rollback_interrupt() to roll back sync mode vector handler at end of async transfer.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
When attempting to perform a test build of various mbed-os targets with
GCC configured to build -std=gnu++11, all of the targets built
successfully except for this one. It gave errors like this:
../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp: In function 'emac_interface_t* wifi_emac_get_interface()':
../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp:331:38: error: use of deleted function 'emac_interface::emac_interface()'
_intf = new emac_interface_t();
^
In file included from ../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp:9:0:
../mbed-os/hal/emac_api.h:150:16: note: 'emac_interface::emac_interface()' is implicitly deleted because the default definition would be ill-formed:
typedef struct emac_interface {
^
../mbed-os/hal/emac_api.h:150:16: error: uninitialized const member in 'struct emac_interface'
../mbed-os/hal/emac_api.h:151:32: note: 'const emac_interface_ops_t emac_interface::ops' should be initialized
const emac_interface_ops_t ops;
This commit contains a proposed change which fixes this issue by not
using the new operator to allocate the emac_interface_t structure but
instead using the malloc() function since the construction is being
handled explicitly in the subsequent lines of the
wifi_emac_get_interface() function anyway.
I also added code which only completes the initialization of the _intf
object if its allocation succeeds and just returns NULL otherwise.
I see no deallocation of the _intf object occurring so no change from
delete to free() needed to be made.
Revert HRM1017 file source deletion
Added in small comment next to additions
Added mapping to BTN-labelled switches
Added mapping to USER_BUTTON-labelled switches
Undo incorrect mapping to SWIO pin in NORDIC target
Before this patch, many warnings like below were generated
during compilation with ArmCC
[Warning] lwip_ethernet.h@57,0: #3135-D: attribute does not apply to any entity
This happens here as ``--gnu`` option of ArmCC is being used, which
enables the GNU compiler extensions that the ARM compiler supports.
This is solve by adding a extra check on __CCARM .
The USB ISTR register consists of a mix of bits that are
write-zero-to-clear and read only bits. As such, to clear a bit in
the ISTR, you should simply write the bitwise-NOT of the bit to clear.
Previously, the __HAL_PCD_CLEAR_FLAG() macro would do a bitwise-AND
with the ISTR register contents to clear a bit, but this could result
in another bit being inadvertently cleared if it is set by hardware
between the read and the write of the ISTR register.
Similarly, the USB endpoint registers have two bits that are
write-zero-to-clear, USB_EP_CTR_RX and USB_EP_CTR_TX, but the
PCD_CLEAR_RX_EP_CTR() and PCD_CLEAR_TX_EP_CTR() macros wrote back the
last read value for one of these bits when clearing the other bit.
This could result in inadvertent clearing of one of these bits if it
were set by the hardware between the read and the write. These macros
have now both been adjusted to always write one to the bit not being
cleared to prevent inadvertent clears.
HAL driver: Add changes from needad for nrf52840 support
us_ticker, spi, sleep, serial, pwmout, pinmap, object, i2c, gpio, analogin
Add compatibility patches for:
- SoftDevice headers renamed (redirec by a few h files)
- sdk configuration (redirect by sdk_config.h files)
- renaming of func in softdevice handler module
Modifying the code for mbed ci shield test -> analogin_api.c, W7500x_adc.c, gpio_irq_api.c, W7500x_gpio.c
Modifying the code for fix bug -> W7500x_uart.c(register control driver problem), W7500x_uart.h, pinmap.c(pullup, pulldown problem)
This patch enable the LWIP feature for the LPC4088 and LPC4088_DM boards.
The lwIP stack support already this hardware.
See: ./features/FEATURE_LWIP/lwip-interface/lwip-eth/arch/TARGET_NXP/lpc17_emac.c
If one of the CC channel pins is enabled, `pwmout_all_inactive` it
means a channel is active so it should return `true`.
This commit also contains some cleanup in `pwm_init`.
* Update i2c driver to tackle multiple I2C object instances on different pins
* Update pinmap to enable the extra peripherals of EFx32xG12 over EFx32xG1
Due to limitation in the mbed website backend (board names need to be <= 19 characters), we are shortening the CLI target names from THUNDERBOARD to TB.
@screamerbg
This removes the duplicate header files from the build. We were getting
lucky on most invocations of `mbed compile` in that these headers were
searched for after some others, but not when exporting to uvision.
If I2C slave support is included, then the I2C error handler would
always reset the I2C address, resulting in incorrectly changing the
I2C state to listen for a controller configured as I2C master. This
change conditionalizes the address setting to only occur if the
controller was in slave mode when the error occurred.
- move ovf handler at the begining of rtc handler for mitigate the case (mitigate issue for exexution from rtc handler)
- add repeating of operation of set a timestamp in cas that rtc overflow occured during the operation.
- bad number of pin from nRF52840 ,
- bad type of mask of gpio for nRF52940
- typo (object.h)
- revert abort func. to spi_master driver
- update twi_master driver to the newest (e8527f65e90eee6a4dd48ca55d3fc051a556320a master SDK nRF5)
- Remove ble_advertising.h/c - it was unused, redundant code
- includes for SD header ble.h were changed to headers\ble.h in order to distingusch form feature-ble BLE.h
- btle_init() introduced PM for disable <B>privacy</B> for API 3 and further.
- temporary removed or mocked real implemantation of whitelist-ing support functionalities:
btle_security.createWhitelistFromBondTable , gap::startAdvertising, gat::startRadioScan, gap::stopAdvertising
Gap::generateStackWhitelist, Gap::getStackWhiteIdentityList-(mock)
- Characteristic Descriptor Discoverer - aligned to the apply SD API
- long uuid service's read spupport
- add BLE features support to sdk configurations file
- publicate sdk's id_manager.ah() function.
- cutted out f. app_error_handler for mbed-os
- removed PACKED definition form app_util_platform (redefined by mbed-os)
- Gap::setAddress - allign to new SD API using peer manager
- extend Gap::getPermittedTxPowerValues for nRF52840
- corected scater & startup file for IAR EW
- fix warnings caused by port_api.c, ble_radio_notification.c, nrf_drv_spi.c (for IAR it was error), serial_api.c
+ mbed RTx setings for nRF52840
fix build of test for NRF52840
+ few sdk's missing filess
- few sdk's unvanted files
corect mbed HAL implementation to changes made in sdk v13
using
.\targets\TARGET_NORDIC\TARGET_NRF5_SDK13\porting_tools\sdk_update.py
and
.\targets\TARGET_NORDIC\TARGET_NRF5_SDK13\porting_tools\replace_headers.py
files .\targets\TARGET_NORDIC\TARGET_NRF5_SDK13\TARGET_MCU_NRF52832\sdk\softdevice\s132\headers\nrf_ble*.h
renamed to .\targets\TARGET_NORDIC\TARGET_NRF5_SDK13\TARGET_MCU_NRF52832\sdk\softdevice\s132\headers\ble*.h
by hand.
As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
* Off by one error in the linker scripts reserved one word too little for the vector table
* Re-apply uvisor changes to emlib. To allow uvisor to run, we should make accesses to the romtable through uvisor's secure read gateway
* Copypasta in target name (EFM32PG12, not EFR32PG12)
* Copypasta in the pin definitions (thanks @akselsm)
* Forgot to update PortName for extra ports on MG/PG12
Targets NUCLEO_F429ZI and UBLOX_EVK_ODIN_W2 have 192K RAM.
Heap size in PR #3871 was increased from 48K to 96K as tls-client
example failed with 48K heap. But this resulted in compilation failures
in mbed-client that requires 71K for global/static data.
Hence this PR reduces heap to 64K that minimum required by tls-client
to work. This also meets mbed-client data segment requirements.
In targets.json, add lf_clock_rc_calib_timer_interval and
lf_clock_rc_calib_mode_config setting which are essential when using BLE
In mbed_overrides.c, create valuables instead of doing printf, those
valuables are intended to be used for debugging in runtime.
Currently, there is the issue in register setting into serial_format().
The issue is that parameter for baudrate setting is initialed zero in this function.
In baudrate is less 9600bps, the issue occurs. In baudrate is over 9600, not occurs. When call serial_baud() before serial_format(), baudrate override and set with an incorrect value.
Therefore, I fixed register setting not to set the parameter of baudrate setting in serial_format().
In case the selected frequency is higher than the requested one, it is
better to send a debug warning rather than an blocking error.
In case of such warning, user may need to redefine the clock tree setting
at higher level (reducing peripheral's input clocks during init phase).
Up to now, speed was set for outputs and alternate, but this is
also valid for input configuration.
By default, let's configure high speed.
This is done firts, because speed for some families like F1 is mixed
with Input/Output mode settings, so can be later over-ridden if needed.
By default the number of pstorage pages is set 1 and all addresses are
calculated in the pstorage module accordingly. Nordic recommends
changing this macro to whatever number is suitable for the app (see
https://devzone.nordicsemi.com/question/53066/what-will-be-the-starting-
address-of-pstorage-page-how-we-can-change-it/?answer=53085#post-id-5308
5) which is not quite elegant given that pstorage_platform.h is part of
the mbed-os repo. With this modification you can e.g. define
PSTORAGE_NUM_OF_PAGES on the command line, however note that you should
rebuild mbed-os with this setting as it affects pstorage_platform.c.
This patch will prevent building bootloader builds on targets that have
not yet had their linker scripts/scatter files changed to allow for the
ROM space shrinking expected by bootloader builds. At the point of this
patch, bootloader linker script modifications are only supported by the
NUCLEO_F429ZI, K64F, KL46Z, and Odin.