Unspecified error.

Definition at line 42 of file Driver_Common.h.

Driver is busy.

Definition at line 43 of file Driver_Common.h.

Parameter error.

Definition at line 46 of file Driver_Common.h.

Start of driver specific errors.

Definition at line 47 of file Driver_Common.h.

Timeout occurred.

Definition at line 44 of file Driver_Common.h.

Operation not supported.

Definition at line 45 of file Driver_Common.h.

Operation succeeded.

Definition at line 41 of file Driver_Common.h.

Data is retained across processor deep-sleep.

Definition at line 115 of file Driver_Storage.h.

Data is retained across processor sleep.

Definition at line 114 of file Driver_Storage.h.

Data is battery-backed. Device can be powered off.

Definition at line 116 of file Driver_Storage.h.

Data is retained in non-volatile memory.

Definition at line 117 of file Driver_Storage.h.

Values for encoding data-retention levels for storage blocks.

Please ensure that the maximum of the following retention types doesn't exceed 16; we encode this in a 4-bit field within ARM_STORAGE_INFO::retention_level.Data is retained only during device activity.

Definition at line 113 of file Driver_Storage.h.

Part (or all) of the range provided to Erase() isn't erasable.

Definition at line 47 of file Driver_Storage.h.

Part (or all) of the range provided to ProgramData() isn't programmable.

Definition at line 48 of file Driver_Storage.h.

Part (or all) of the range to Erase() or ProgramData() is protected.

Definition at line 49 of file Driver_Storage.h.

Runtime or sanity-check failure.

Definition at line 50 of file Driver_Storage.h.

Invalid address within the processor's memory address space.

Refer to memory-mapped storage, i.e. < ARM_DRIVER_STORAGE::ResolveAddress().

Definition at line 43 of file Driver_Storage.h.

Invalid address (relative to a storage controller's.

address space). A storage block may never start at this address.

Definition at line 40 of file Driver_Storage.h.

Infinite or unknown endurance for reprogramming.

Definition at line 141 of file Driver_Storage.h.

re-programmable based on erase. Supports multiple writes.

Definition at line 105 of file Driver_Storage.h.

Values for encoding storage memory-types with respect to programmability.

Please ensure that the maximum of the following memory types doesn't exceed 16; we encode this in a 4-bit field within ARM_STORAGE_INFO::programmability.

Definition at line 102 of file Driver_Storage.h.

Read-only memory.

Definition at line 103 of file Driver_Storage.h.

write-once-read-only-memory (WORM).

Definition at line 104 of file Driver_Storage.h.

The check for a valid ARM_STORAGE_BLOCK.

Definition at line 94 of file Driver_Storage.h.

Analogin hal structure.

analogin_s is declared in the target's hal

Definition at line 34 of file analogin_api.h.

This is the set of operations constituting the Storage driver.

Their implementation is platform-specific, and needs to be supplied by the porting effort.

Some APIs within ARM_DRIVER_STORAGE will always operate synchronously: GetVersion, GetCapabilities, GetStatus, GetInfo, ResolveAddress, GetNextBlock, and GetBlock. This means that control returns to the caller with a relevant status code only after the completion of the operation (or the discovery of a failure condition).

The remainder of the APIs: Initialize, Uninitialize, PowerControl, ReadData, ProgramData, Erase, EraseAll, can function asynchronously if the underlying controller supports it–i.e. if ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. In the case of asynchronous operation, the invocation returns early (with ARM_DRIVER_OK) and results in a completion callback later. If ARM_STORAGE_CAPABILITIES::asynchronous_ops is not set, then all such APIs execute synchronously, and control returns to the caller with a status code only after the completion of the operation (or the discovery of a failure condition).

If ARM_STORAGE_CAPABILITIES::asynchronous_ops is set, a storage driver may still choose to execute asynchronous operations in a synchronous manner. If so, the driver returns a positive value to indicate successful synchronous completion (or an error code in case of failure) and no further invocation of completion callback should be expected. The expected return value for synchronous completion of such asynchronous operations varies depending on the operation. For operations involving data access, it often equals the amount of data transferred or affected. For non data-transfer operations, such as EraseAll or Initialize, it is usually 1.

Here's a code snippet to suggest how asynchronous APIs might be used by callers to handle both synchronous and asynchronous execution by the underlying storage driver:

Driver Version.

General power states.

A storage block is a range of memory with uniform attributes.

Storage blocks combine to make up the address map of a storage controller.

Attributes of the storage range within a storage block.

Declaration of the callback-type for command completion.

Parameters

[in]	status	A code to indicate the status of the completed operation. For data transfer operations, the status field is overloaded in case of success to return the count of items successfully transferred; this can be done safely because error codes are negative values.
[in]	operation	The command op-code. This value isn't essential for the callback in the presence of the command instance-id, but it is expected that this information could be a quick and useful filter.

Definition at line 242 of file Driver_Storage.h.

Storage Driver API Capabilities.

This data structure is designed to fit within a single word so that it can be fetched cheaply using a call to driver->GetCapabilities().

Storage information.

This contains device-metadata. It is the return value from calling GetInfo() on the storage driver.

These fields serve a different purpose than the ones contained in ARM_STORAGE_CAPABILITIES, which is another structure containing device-level metadata. ARM_STORAGE_CAPABILITIES describes the API capabilities, whereas ARM_STORAGE_INFO describes the device. Furthermore ARM_STORAGE_CAPABILITIES fits within a single word, and is designed to be passed around by value; ARM_STORAGE_INFO, on the other hand, contains metadata which doesn't fit into a single word and requires the use of pointers to be moved around.

Command opcodes for Storage.

Completion callbacks use these codes to refer to completing commands. Refer to ARM_Storage_Callback_t.

Device Data Security Protection Features.

Applicable mostly to EXTERNAL_NVM.

Operating status of the storage controller.

Generic buffer structure.

CRC Polynomial value.

Different polynomial values supported

Analogout hal structure.

dac_s is declared in the target's hal

Definition at line 34 of file analogout_api.h.

GPIO IRQ HAL structure.

gpio_irq_s is declared in the target's HAL

Definition at line 42 of file gpio_irq_api.h.

Port HAL structure.

port_s is declared in the target's HAL

Definition at line 33 of file port_api.h.

Pwmout hal structure.

pwmout_s is declared in the target's hal

Definition at line 34 of file pwmout_api.h.

Ticker's event structure.

Legacy format representing a timestamp in us.

Given it is modeled as a 32 bit integer, this type can represent timestamp up to 4294 seconds (71 minutes). Prefer using us_timestamp_t which store timestamp as 64 bits integer.

Definition at line 33 of file ticker_api.h.

TRNG HAL structure.

trng_s is declared in the target's HAL

Definition at line 30 of file trng_api.h.

A us timestamp stored in a 64 bit integer.

Can store timestamp up to 584810 years.

Definition at line 39 of file ticker_api.h.

General power states.

Definition at line 52 of file Driver_Common.h.

Command opcodes for Storage.

Completion callbacks use these codes to refer to completing commands. Refer to ARM_Storage_Callback_t.

Definition at line 211 of file Driver_Storage.h.

Values that represent CAN Format.

Definition at line 35 of file can_helper.h.

Values that represent CAN Type.

Definition at line 48 of file can_helper.h.

CRC Polynomial value.

Different polynomial values supported

Definition at line 30 of file crc_api.h.

GPIO IRQ events.

Definition at line 34 of file gpio_irq_api.h.

Serial interrupt sources.

Definition at line 75 of file serial_api.h.

Get the pins that support CAN RD.

Return a PinMap array of pins that support CAN RD. The array is terminated with {NC, NC, 0}.

Returns

PinMap array

Get the pins that support CAN TD.

Return a PinMap array of pins that support CAN TD. The array is terminated with {NC, NC, 0}.

Returns

PinMap array

Get wrapped lp ticker data.

Parameters

data	hardware low power ticker object

Returns

wrapped low power ticker object

Return a the USBPhy instance for this hardware.

For details on adding support for a USBPhy see the specification in USBPhy.h.

Returns

A pointer to a USBPhy instance

Note

Calling this function on platforms without a USBPhy will result in an error

Interrupt handler for the wrapped lp ticker.

Parameters

handler

the function which would normally be called by the lp ticker handler when it is not wrapped

Resume the wrapper layer code.

Resume operation of the wrapper layer. Interrupts will be filtered as normal and the microsecond timer will be used for interrupts scheduled too quickly back-to-back.

Suspend the wrapper layer code.

Pass through all interrupts to the low power ticker and stop using the microsecond ticker.

Warning

: Make sure to suspend the LP ticker first (call ticker_suspend()), otherwise the behavior is undefined.

Find a combination of pins suitable for use given the constraints.

This function finds pins which meet these specific properties:

• The pin is part of the form factor
• The pin is not in the restricted list
• The pin is contained within the respective pinmap
• The pin belongs to the given peripheral
• Each pin found is distinct; in the example below mosi and miso will never be assigned the same pin

Example:

Parameters

whitelist	List of pins to choose from
blacklist	List of pins which cannot be used
per	Peripheral to which the pins belong
maps	An array of pin maps to select from
pins	An array of pins to find. Pins already set to a value will be left unchanged. Only pins initialized to NC will be updated by this function
count	The size of maps and pins

Returns

true if a suitable combination of pins was found and written to the pins array, otherwise false

Check if the peripheral is in the list.

Parameters

list	peripheral list to check
peripheral	peripheral to check for in the list

Returns

true if the peripheral is in the list, false otherwise

Check if the pin is in the list.

Parameters

list	pin list to check
pin	pin to check for in the list

Returns

true if the pin is in the list, false otherwise

Get the pin list of peripherals to avoid during testing.

The restricted peripheral list is used to indicate to testing that a peripheral should be skipped due to some caveat about it. For example, using the USB serial port during tests will interfere with the test runner and should be avoided.

Targets should override the weak implementation of this function if they have peripherals which should be skipped during testing.

Note

Some targets use the same value for multiple different types of peripherals. For example SPI 0 and UART 0 may both be identified by the peripheral value 0. If your target does this then do not use this function to skip peripherals, as this will unintentionally cause all peripherals with that value to be skipped. Instead these entries should be removed from the peripheral PinMap itself.

Returns

Pointer to a peripheral list of peripheral to avoid

Get the pin list of pins to avoid during testing.

The restricted pin list is used to indicate to testing that a pin should be skipped due to some caveat about it. For example, using USBRX and USBTX during tests will interfere with the test runner and should be avoided.

Targets should override the weak implementation of this function if they have additional pins which should be skipped during testing.

Returns

Pointer to a pin list of pins to avoid