By default D0 - D3 pins are used for the bit-banged SPI com channel between mbed target and the FPGA-test-shield.
For some reason, if pins were used as GPIOs and then reconfigured to I2C pins the I2C com does not work on NRF52840.
This commit modifies i2c_configure_twi_instance() function and adds proper initialization of the I2C pins.
While testing it has been found that all tests are skipped in the FPGA uart test on the NRF52840 target.
This is caused by the following change:
https://github.com/ARMmbed/mbed-os/pull/12379 - Add STDIO UART as restricted for FPGA testing for all targets
NRF targets have MUXed pins and mainly do not provide pin-maps. There are only dummy pin-maps for testing.
These pin-maps hold only pins and do not specify the peripheral or function of the pin (always 0). Because of that if we restrict STDIO uart peripheral (0) all FPGA uart test cases will be skipped.
To fix this we will remove this restriction for NRF52840. Restriction for testing the USBTX, USBRX pins is sufficient in this case.
It is required by Mbed HAL API to generate TxIrq interrupt when TXD register is empty (also after enabling TxIrq interrupt):
f73a62afbf/hal/serial_api.h (L144-L147)
The driver uses DMA to perform uart transfer and TxIrq is generated after the transfer is finished.
While enabling TxIrq we will check if TXD reg is empty and manually trigger the interrupt.
Acording to the description in `gpio_irq_hal_api.h` file `gpio_irq_init()` should return 0 on success.
Currently, it returns 1 causing the FPGA test to fail.
Major changes:
- Dependency to FileHandle removed from base classes
- AT_CellularDevice owns the default FileHandle and shares it with AT -classes
- Hang-up -detection moved as CellularContext::configure_hup(). Cannot be configured via CellularDevice any more.
Result on NRF52840_DK + BG96:
GCC:
Total Static RAM memory (data + bss): 29360(+296) bytes
Total Flash memory (text + data): 130660(-832) bytes
ARM:
Total Static RAM memory (data + bss): 261554(+8) bytes
Total Flash memory (text + data): 127573(-1193) bytes
IAR:
Total Static RAM memory (data + bss): 25479(+296) bytes
Total Flash memory (text + data): 102418(-527) bytes
RAM increase is because now ATHandler is no longer created with new -operator but is now member of AT_CellularDevice,
so image tool is able to count it. Actually total RAM consumption has decreased due to removed variables.
DEBUG_NRF_USER gets defined for build profiles (develop, debug)
which do not define NDEBUG (see nrf_assert.h). Therefore the definition
of the function should also be visible if DEBUG_NRF_USER is defined.
All targets must implement soft_- and hard_power_on/off() functions which are practically same what onboard_modem_api offered.
These were seen as a duplicate features and therefore we removed this.
All targets involved have been updated to reflect the changes
i2c_byte_write implementation was broken.
Data sending was inside addressing block
Changed from:
i2c_byte_write
{
if (start) {
if (read_address)
start read;
esle
start write;
write byte;
}
}
to:
i2c_byte_write
{
if (start) {
// if first call after start
// address for reading or writing
if (read_address)
start read;
esle
start write;
} else {
// send data byte
write byte;
}
}
ARM Compiler 6.13 testing revealed linker errors pointing out
conflicting use of `__user_setup_stackheap` and
`__user_initial_stackheap` in some targets. Remove the unwanted
`__user_initial_stackheap` from the targets - the setup is
centralised in the common platform code.
Looking into this, a number of other issues were highlighted
* Almost all targets had `__initial_sp` hardcoded in assembler,
rather than getting it from the scatter file. This was behind
issue #11313. Fix this generally.
* A few targets' `__initial_sp` values did not match the scatter
file layout, in some cases meaning they were overlapping heap
space. They now all use the area reserved in the scatter file.
If any problems are seen, then there is an error in the
scatter file.
* A number of targets were reserving unneeded space for heap and
stack in their startup assembler, on top of the space reserved in
the scatter file, so wasting a few K. A couple were using that
space for the stack, rather than the space in the scatter file.
To clarify expected behaviour:
* Each scatter file contains empty regions `ARM_LIB_HEAP` and
`ARM_LIB_STACK` to reserve space. `ARM_LIB_STACK` is sized
by the macro `MBED_BOOT_STACK_SIZE`, which is set by the tools.
`ARM_LIB_HEAP` is generally the space left over after static
RAM and stack.
* The address of the end of `ARM_LIB_STACK` is written into the
vector table and on reset the CPU sets MSP to that address.
* The common platform code in Mbed OS provides `__user_setup_stackheap`
for the ARM library. The ARM library calls this during startup, and
it calls `__mbed_user_setup_stackheap`.
* The default weak definition of `__mbed_user_setup_stackheap` does not
modify SP, so we remain on the boot stack, and the heap is set to
the region described by `ARM_LIB_HEAP`. If `ARM_LIB_HEAP` doesn't
exist, then the heap is the space from the end of the used data in
`RW_IRAM1` to the start of `ARM_LIB_STACK`.
* Targets can override `__mbed_user_setup_stackheap` if they want.
Currently only Renesas (ARMv7-A class) devices do.
* If microlib is in use, then it doesn't call `__user_setup_stackheap`.
Instead it just finds and uses `ARM_LIB_STACK` and `ARM_LIB_HEAP`
itself.
* The following v14.2 files are removed from nrfx/legacy:
nrf_drv_clock.h
nrf_drv_common.h
nrf_drv_gpiote.h
nrf_drv_spi.h
nrf_drv_twi.h
nrf_drv_uarth.h
* Remove unneeded references to "nrfx_glue.h" and "nrf_drv_common.h"
* Remove the definition of PACKED from app_util_platform.h (already defined
in mbed_toolchain.h)
* Update all scatterfiles to define MBED_RAM_START and MBED_RAM_SIZE. These
get defined in mbed_lib.json when building with a SoftDevice but were missing
when no SoftDevice is brought in.
* Remove SDK 14.2 SoftDevice files.
* Add missing header file to qspi_api.c.
- Adjust memory for SoftDevice
- Enable PRIO=5 for interrupt priority check
- Change NRF_SD_BLE_API_VERSION to 6
- Add handle and buffer for advertising and scanning
- Remove guard for phy update
- Change scatter files and mbed_lib.json for PR #8607
* Update TARGET_NRF5x/README.md to improve "Changing SoftDevice" section
and added section on NRF52840 CryptoCell310 Support
* Update the file list in TARGET_SDK_15_0/TARGET_SOFTDEVICE_COMMON/README.md
* Add missing CR-LF to Nordic-provided SDK file
* Rename a header file in the TARGET_SOFTDEVICE_S112 tree
This reverts commit 3d2fa535a71b7bad08c6a91a31d74f4492c8948c.
This was a breaking change for the "MBR" and "NONE" builds.
After testing it was also determined that copying the vector
table a second time wasn't required for the "FULL" build.
- Add MBR, NONE and OTA SoftDevice build options for S132 and S140
- Add S112 SoftDevice (single build option)
- Some folder restructuring in TARGET_SOFTDEVICE_COMMON was required
The 15.0 SDK doesn't support the nRF51 so it must continue to use the legacy
NRF drivers. Thus the original common_rtc.c, gpio_api.c and us_ticker.c are
restored and placed under TARGET_NRF5x/TARGET_NRF51.
Likewise the modified common_rtc.c, gpio_api.c and us_ticker.c are moved to
TARGET_NRF5x/TARGET_NRF52 so they are excluded from nRF51 builds.
Ensure that vector table gets initialized properly. The table that we
initialize in startup_nrf52840.S gets wiped out as the section is
declared as noinit. Fix this by implementing the weak function mbed_sdk_init
that inits the vector table.
When the SoftDevice (SD) is enabled we need to set the app_offset
to 0x26000 to make room for the SoftDevice. If we let the build
tools self-manage this, MBED_APP_START is coming out at 0x25000
which is not correct for the Nordic 15.0 SDK.
The app_offset value is translated to MBED_APP_START by the build
infrastructure. We were hard coding MBED_APP_START in the scatter
and ld files as a temporary measure while testing. This now sets
it properly if the SD is being brought in.
- Added legacy nrf_drv_rng.c as there is no merit in fully adopting nrfx_rng.c
- Added nrf_queue library component
- Removed apply_old_config.h (unused for some time now)
- Updated sdk_config.h for queue and RNG support for nRF52832
- Brought back RNG into targets.json for nRF52832
Note: nRF52840 still uses CryptoCell 310 for TRNG
- Use new NRFX header file
- Fix nRF52832 linker script/ld files (hardcoded addresses for now)
- Temporarily remove DEVICE_TRNG for nRF52832 (which broke the build)
- Improve serial_putc() fix so we don't rely on "extra" functions
- Missed some NRFX defines that needed to changed
- Set PWM base clock to 125kHz (needs to be reverted back to 1 MHz)
- Updated sdk_config.h for nRF52_DK builds
- Brought in updates from PR7779 (fix for nRF52 PWM issues)
Also addressed:
- removed dependency on legacy config (excluded apply_old_config.h)
- removed legacy pwm and saadc headers
- Arm Compiler 5 linking issue (a band-aid for now... needs to
be properly addressed for peripheral sharing)
- added missing header in SoftDevice file
- top level files ported from TARGET_NORDIC/TARGET_NRF5x/
Also addressed:
- fixed linking issue for gcc
- added support for nRF52-DK builds, but reverted to using nRF52840 sdk_config.h (must be updated)
- introduced "RTC" to targets.json (might need to be removed eventually)
Reimplement atomic code in inline assembly. This can improve
optimisation, and avoids potential architectural problems with using
LDREX/STREX intrinsics.
API further extended:
* Bitwise operations (fetch_and/fetch_or/fetch_xor)
* fetch_add and fetch_sub (like incr/decr, but returning old value -
aligning with C++11)
* compare_exchange_weak
* Explicit memory order specification
* Basic freestanding template overloads for C++
This gives our existing C implementation essentially all the functionality
needed by C++11.
An actual Atomic<T> template based upon these C functions could follow.