The "Callback_big" greentea test has six test cases that require
a minimum above 36kb ROM to build all test cases. LPC1114 target
has only 32KB ROM memory, so the limit 6th test case to include
or exclude based on the target minimum ROM size.
Note:
In LPC1114 target, callback_big test has ROM overflow build issue
for both Mbed CLI1 and CLI2.
Mbed CLI 2 generates TARGET_ARM_FM macro as a string in mbed_config.cmake
under the MBED_TARGET_DEFINITIONS list. Fix the "if defined" check for
TARGET_ARM_FM by searching for the TARGET_ARM_FM string in the
MBED_TARGET_DEFINITIONS list. This allows us to skip or include the test from CMake.
QSPIF was disabled on CYW9P62S1_43012EVB_01 because its S25FS512S
flash chip has multiple configurations but our SFDP parser did not
support this scenario. Now having added support for this, we can
enable QSPIF (the component label for QSPIFBlockDevice) and QSPI
(the label for Quad-SPI communication).
A Sector Map Parameter Table contains a sequence of the following
descriptors:
* (Optional) configuration detection command descriptors, one for
each command to run to determine the current configuration. This
exists only if the flash layout is configurable.
* Sector map descriptors, one for each possible configuration. On
a flash device with a non-configurable layout, there is only one
such descriptor.
Previously we only supported the non-configurable case with a single
descriptor. This commit adds support for multiple configurations.
Add a test case to verify that the quirk on `CR1NV` and `CR3NV`
registers get applied by `QSPIFBlockDevice` when the flash device
is S25FS512S.
`QSPIFBlockDevice` depends on the SFDP functions and the `QSPI` class,
but we can't use gMock on them because:
* SFDP functions are global functions, whereas gMock only supports
mocking class member functions.
* A mocked class is injected into the test subject, but passing a
preexisting `QSPI` instance into `QSPIFBlockDevice` is not possible
(unless we resort to pointers). For details, see comments in
test_QSPIFBlockDevice.cpp.
So fakes of the `QSPI` class and any SFDP functions involved are
defined in test_QSPIFBlockDevice.cpp.
The entire flash chip S25FS512S consists of uniform 256KB sectors.
Additionally, it has three configurations:
* 0x01: Eight 4KB sectors (32KB in total) overlaying the start of
the first 256KB sector
* 0x03: Eight 4KB sectors (32KB in total) overlaying the end of the
last 256KB sector
* 0x05: No overlaying sectors
The active configuration is determined from bit fields of two
registers, CR1NV and CR3NV.
Mbed OS does not currently support partially overlaying sectors,
meaning that with eight 4KB sectors overlay a 256KB sectors, the
remaining 224KB (== 256KB - 8 * 4KB) of the big sector can't be
correctly handled. Supporting such scenario would involve a large
amount of rewriting in Mbed OS's BlockDevice, SFDP and their tests,
and may increase the code size.
So, this commit applies a quirk to always report configuration 0x05
(no overlaying sectors). Even if 0x01 or 0x03 is the real configuration,
they are compatible with the 0x05 configuration because 256KB sectors
exist in all cases.
Note: This quirk does *not* change actual configurations on hardware,
because registers CR1NV and CR3NV are one-time configurable (OTP) -
each bit field has a factory value of 0 and can be changed to 1 by the
user but not back to 0. So QSPIFBlockDevice avoids changing them.
Cypress S25FS512S's SFDP table suggests that bit-1 of the register
CR3NV on 25FS512S should equal 1. But it is a known issue that the
value is actually 0 on hardware. So if we query the value of CR3NV
during configuration detection, we can't find a configuration that
matches the SFDP data. This issue has been discussed in the Linux MTD
(Memory Technology Devices) mailing list:
https://linux-mtd.infradead.narkive.com/ylHK6CyT/spi-nor-fs512s-incorrect-cr3nv-1-value
This commit adds a quirk to report bit-1 of CR3NV as 1.
Note: In Mbed OS, vendor-specific quirks can only be handled in block
devices. The SFDP functions assume data from hardware to be correct.
So this quirk is in the block device.
In Mbed OS, each library has an `include/<library>/` subdirectory
containing headers. The recommended way to include a header is
`#include "<library>/<header>.h"` to avoid potential conflicts with
any external modules that have same names of headers.
This is not enforced yet, and both include/ and include/<component>/
are in a library's include paths, to avoid breaking preexisting
Mbed projects that don't follow the recommendation. But code within
Mbed OS should follow it at least.
This allows the entire QSPI class to be mocked/faked for unit testing
purpose, without dependencies from the real implementation such as
`qspi_free()` from the HAL.
The second byte of the sector map descriptor is the configuration ID.
On a device with non-configurable layout, the only available map
descriptor's configuration ID must be 0x00 as required by the
JESD216D standard. This value is important, because we will check
each descriptor's configuration ID when we support multiple
configurations.
Note: The test data is fake - when we modified real data of a
configurable device to become non-configurable for test purpose, we
forgot to change this field.
The SFDP functions parse SFDP data which is fetched by a callback
called `sfdp_reader` provided by {SPIF,QSPIF,OSPIF}BlockDevice.
Currently, this callback interface only takes a read address and an RX
buffer to store output data. This has been enough, because other SPI
parameters are always the same when fetching the SFDP table only -
they are just hardcoded in each reader.
But in the future we will add support for flash devices with multiple
configurations (in a subsequent commit), and to detect which
configuration is enabled, we will need to send detection commands
which require device-dependent SPI parameters:
* address size
* instruction
* dummy cycles
This commit
* turns the above SPI parameters from predefined/hardcoded values
into parameters of the callback
* lets the SFDP functions pass the above parameters to the callback
(Note: To read the SFDP table itself, those values are constants
defined by the standard, not tied to any particular device, so they
can be known to the SFDP functions)
* updates the callbacks implemented by {SPIF,QSPIF,OSPIF}BlockDevice
* updates the mock callback for unit tests and expectations
When passing an allocation size directly to `std::make_unique`,
`std::nothrow` is unavailable, so any failed allocation results in
an exception which we cannot catch because Mbed OS is compiled with
`-fno-exceptions`. To fix this, chain `std::make_unique` with
`new (std::nothrow)`, and the allocated `unique_ptr` retains the
`nullptr` property.
Macro MBED_ALIGN expands in C to _Alignas which can't be used in the
type declaration. This patch moves it to the first type definition
which makes this code compile properly in CPP and C.
The test case for multithreaded erase/program/read allocates a few
Thread objects from the heap and starts them. It has a few problems:
* To check that there will be enough heap to start a new thread, the
test case tries to allocate a dummy buffer of the thread's heap size
and then frees it, before starting the thread. Then the thread will
allocate its own stack. Such check is not reliable, because threads
that are already running also perform additional allocation (when
running `test_thread_job()`) and may take away the memory we just
checked.
* When deleting all threads in a loop, the loop boundary misses the
last thread if the last thread object was allocated but not started
(i.e. due to failed thread stack allocation check).
To fix the issues
* Start a thread without any allocation test. Following the preceding
commit "rtos: Thread: Make stack allocation failure runtime catchable",
`Thread::start()` now returns `osErrorNoMemory` if stack allocation
fails which we can handle.
* Store pointers to all threads in a zero-initialized array, and
free all elements at the end of the test.
When a Thread object's stack memory is not provided, its `start()`
member function dynamically allocates its stack from the heap. If
allocation fails, there is no way to catch it because
* `std::nothrow` is missing after the `new` keyword. As Mbed OS
is built with `-fno-exceptions` (C++ exceptions disabled), failed
allocation results in an unrecoverable fault.
* The attempted `nullptr` check, which doesn't work anyway due to
the first point, is an assertion instead of error returning.
Assertions should be used as a development tool to ensure code
behaves correctly. But out-of-memory is a completely valid runtime
situation.
This commit adds the missing `std::nothrow`, and makes `Thread::start()`
return `osErrorNoMemory` if allocation fails so the caller can handle
it.
Note: A case when a thread should never fail due to lack of memory
is the main thread. But the main thread's stack is a pre-allocated
array in the static memory, passed to the `Thread()` constructor
during thread creation, so it's not impacted by this change.
Jaeden Amero
Rajkumar Kanagaraj
Martin Kojtal
Lingkai Dong
Jerome Coutant
mateusz.kalinowski
Saheer