- 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.
ticker_insert_event() can crash on KLXX (and probably other platforms) if an event is inserted with a timestamp before the current real time.
The problem is easy to trigger: you just need to set up a Ticker object, and then disable interrupts for slightly longer than the Ticker object's interval. It's generally bad practice to disable interrupts for too long, but there are some cases where it's unavoidable, and anyway it would be better for the core library function not to crash. The case where I had an unavoidably long interrupts-off interval was writing flash with the FTFA. The FTFA hardware prohibits flash reads while an FTFA command is in progress, so interrupts must be disabled for the whole duration of each command to ensure that there are no instruction fetches from flash-resident ISRs in the course of the execution. An FTFA "erase sector" command takes a fairly long time (milliseconds), and I have a fairly high frequency Ticker (1ms).
The problem and the fix are pretty straightforward. ticker_insert_event() searches the linked list to figure out where to insert the new event, looking for a spot earlier than any event currently queued. If the event is in the past, it'll usually end up at the head of the list. When the routine sees that the new event belongs at the head of the list, it calls data->interface->set_interrupt() to schedule the interrupt for the event, since it's the new soonest event. The KLXX version of us_ticker_set_interrupt() then looks to see if the event is in the past, which we've stipulated that it is, so rather than actually setting the interrupt, it simply calls the handler directly. The first thing the Ticker interrupt handler does is re-schedule itself, so we re-enter ticker_insert_event() at this point. This is where the problem comes in: we didn't finish updating the linked list before we called set_interrupt() and thus before we recursed back into ticker_insert_event(). We set the head of the list to the new event but we didn't set the new event's 'next' pointer.
The fix is simply to finish updating the list before we call set_interrupt(), which we can do by moving the obj->next initialization ahead of the head pointer update.
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
mbed_lwip_socket_recv() takes one netbuf at a time from the netconn API,
and it holds a partially-read netbuf if necessary in order to present as
a stream for TCP.
This held netbuf was not being freed when the socket was closed.
This patch fixes the declaration of the DIR type and related functions
so that they can be called from C code. This is necessary when enabling
functionality that uses the filesystem in mbed TLS.
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.
When constructing a toolchain for export, we currently set the
`build_dir` to the `export_dir`. When exporting offline, the
`export_dir` is always set to the root of the project. The toolchains
ignore their `build_dir` when scanning for sorces, so when the exporters
use the toolchains to scan for their resources, they get nothing.
In this patch we set the `build_dir` of the toolchain that the exports
use to nothing. A path of nothing should not match anything, and will
therefore not ignore everything when scanning for resources.
Should follow same path as FileHandle, although this is less used
and there is currently no route to introduce a hook for a customized
DirHandle in retarget.
As identified by @hasnainvirk, @kjbracey-arm, the FileHandle and
FileBase serve two separate functions and their integration is
limiting for certain use cases.
FileLike is actually the redundant class here, but the multiple
inheritance it provides is used as a hack by the retargeting code
to get at the FileHandle implementation bound to the FileBase name.
It may make more sense for the FileBase to inherit from FileHandle,
(with perhaps a different name), but rather than explore the
possibility, this will just restore the previous hierarchy.