This change is required to fully remove gpio pin-maps which were already added for FPGA testing.
One use case of adding gpio pinmap was that pin-map must have the specific format - must be ended with NC pin. Functions that deal with pin-maps loops through the pin-map until NC pin is encountered.
Also, our FPGA testing utility function to find pins for testing does that. When gpio pinmaps are fully removed we will have one generic gpio pinmap which provides Arduino pins: D0, D1, D2, etc. (only Arduino form factor is supported at the moment).
In some cases may happen that an arduino pin is not connected (e.g. KW24D: D4 == NC). As a result we will have NC not only at the end, but also in the middle of the gpio pin-map.
In this case find_ports() function will finish processing pin-map to early (when first NC is encountered).
The proposition is to change the find_ports() FPGA testing utility function to loop through form factor pins (instead pin-map) and then check if the pin is not NC and is available on the specific pin-map before using it for testing.
This is a minor optimisation to the mcr20a-rf-driver code:
Note that function parameter is pointer. The code is more readable when 'NULL' instead of using '0'.
When dealing with EEPROMs without a 16 bit adressing, the current
implementation does not work, as it writes a 16 bit address to the chip.
This may cause undefined behaviour.
This change adds a new constructor argument to enable this new eight-bit
mode. It defaults to false to not break existing code.
This constructor argument should actually never be necessary to manually
set, except when dealing with cheap devices.
This is a minor optimisation to the mcr20a-rf-driver code:
1. The function parameter is 'uint8_t *byteArray', (byteArray == NULL) instead of using (byteArray == 0). The code is more readable.
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.
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.
Substantiation for this is that the STDIO UART peripheral is used by Mbed, so it should never be tested.
Also solve the potential problem with accidenty skipped peripherals in FPGA testing. Currently, we have a one `pinmap_restricted_peripherals()` function for all interfaces (UART, I2C, SPI, etc.).
The problem can be encountered if different interfaces have the same peripheral ids (e.g. `UART_0` = 0, `SPI_0` = 0). In this case, if `UART_0` is on the restricted list, then SPI tests will be also skipped for `SPI_0`.
The good news is that usually, the peripheral ids are the base addresses of the peripheral's register set, but we can't rely on this. It is also good that `pinmap_restricted_peripherals()` at this moment is only required for STDIO UART (Nuvoton and STM).
To solve this issue we will change name of `pinmap_restricted_peripherals()` to `pinmap_uart_restricted_peripherals()`, make STDIO UART restricted by default for all targets and update FPGA test utilily functions to use `pinmap_uart_restricted_peripherals()` to skip only uart peripherals.
In the future if needed we can consider to add support to restrict peripherals of other interfaces(SPI, I2C, etc).
This far all SFDP Sector Map Table related data has been found in small
pieces inside SPIFBlockDevice. Purpose was to consolidate the data
under one SFDP structure where all the information gathered from
SFDP tables is stored.
More generic version of a function used for parsing a Sector Map Table
was taken into use to avoid duplicate code. The implementation taken
into use is the one which got split from QSPIFBlockDevice and resides
now under the SFDP module.
This far all SFDP Sector Map Table related data has been found in small
pieces inside QSPIFBlockDevice. Purpose was to consolidate the data
under one SFDP structure where all the information gathered from
SFDP tables is stored.
Parsing a Sector Map Table was made more generic so that later it can be
moved under SFDP module. Once that is done it can be shared with
SPIFBlockDevice to avoid code duplication.
Add a "used" attribute to SVCHandler_main/tfm_pendsv_do_schedule to fix ARMC6 build with
the "-flto" flag.
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
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.
Separates SFDP header retrieval and moves it as a part of the earlier
introduced SFDP file.
Purpose is to abstract away differences between SPIF and QSPIF devices
when it comes to fetching the SFDP headers from a device.
Veijo Pesonen
Martin Kojtal
Stephan Brunner
Przemyslaw Stekiel
Anna Bridge
Gabor Abonyi
Arto Kinnunen
David Lin
jeromecoutant
Michal Paszta
Maciej Bocianski
Mahesh Mahadevan
Pawel Zarembski
Kevin Bracey
Marcin Tomczyk
Rajkumar Kanagaraj
Kimmo Vaisanen
Andrew Chong
Hugues Kamba