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.
ARCH_MAX board uses 0x01 as PHY address, different from other NUCLEO STM32 boards. To faciliate change of PHY address of customized boards, a configuration entry eth-phyaddr was added and can be overriden as needed in mbed_app.json by adding "stm32-emac.eth-phyaddr": X. Macro ETH_ARCH_PHY_ADDRESS was also renamed to ETH_PHY_ADDRESS, because it is not only used by ARCH_MAX board but also other boards.
Moved the existing BufferedBlockDevice to features/storage unittests and switched it to gmock.
Added gmock-based unit tests to all other BlockDevice classes.
SlicingBlockDevice test left as a module test.
Align with mainline BSP and fix relevant bugs:
1. Align with SPI module naming
(1) Remove SPI5
(2) Degrade QSPI0 to SPI4 so that it can use for standard SPI
2. Fix some code lacking GPIO H
3. Implement __PC(...) by following BSP instead of with MBED_CALLER_ADDR()
4. Add SCU_IRQHandler(). Change printf(...) with interrupt-safe error(...)
5. Other minor alignment change
Incorrect addresses only cause error return values instead of assertion.
ExhaustibleBlockDevice has working get/set_erase_cycle functions and an
array preventing programming without erase.
Fixed MBRBlockDevice partitioning function.
When reading a data block, the returned error codes from the I2C subsystem
are different from normal single byte operations. We have to verify that
the read-function for multiple bytes does return zero, because it
returns "readBytes != expectedLength".
Additionally, sync before trying to read from the eeprom as slow devices
may not yet be ready to return data, especially with low-priced ones
used with fast controllers.
1.Testing with Verizon and AT&T SIMs, PDP type is automatically set to IPV4V6.
2. Testing with AT&T IoT SIM, PDP type automatically sets to IP. It will connect
but not communicate. Setting a subsequent APN to IPV4V6 with the same APN communicates.
At these locations, psa_key_attribute variables are used without
initialisation. The function getting it (psa_get_key_attributes),
is freeing attributes->domain_parameters, which can contain random
address from the stack.
Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>