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>
This is a special case since targets do not provide by default GPIO pin-maps.
This extension is required for FPGA GPIO tests - if some pins have limitations (e.g. fixed pull-up) we need to skip these pins while testing.
To do that we were adding a dummy pin-map with commented out pins that can't be tested because of the limitations.
This solution is redundant and the proposition is to provide a list of restricted gpio pins if required (by default weak implementation is provided with an empty list).
This mechanism will be backward compatible, so the old method with dummy gpio pinmap will also work. The switch from dummy pin-maps to pinmap_gpio_restricted_pins() will be performed in separate commits/PRs.