The API follows guidelines of https://www.python.org/dev/peps/pep-0272/,
but is optimized for code size, with the idea that full PEP 0272
compatibility can be added with a simple Python wrapper mode.

The naming of the module follows (u)hashlib pattern.

At the bare minimum, this module is expected to provide:

* AES128, ECB (i.e. "null") mode, encrypt only

Implementation in this commit is based on axTLS routines, and implements
following:

* AES 128 and 256
* ECB and CBC modes
* encrypt and decrypt

Prior to this patch, if both USB FS and HS were enabled via the
configuration file then code was included to handle both of their IRQs.
But mboot only supports listening on a single USB peripheral, so this patch
excludes the code for the USB that is not used.

Only one of pcd_fs_handle/pcd_hs_handle is ever initialised, so if both of
these USB peripherals are enabled then one of these if-statements will
access invalid memory pointed to by an uninitialised Instance.  This patch
fixes this bug by explicitly referencing the peripheral struct.

Thanks to @boochow for the fix.

This and the previous 4 commits combined have change in code size of:

   bare-arm:   -92
minimal x86:  -544
   unix x64:  -544
unix nanbox:  -712
      stm32:  -116
     cc3200:  -128
    esp8266:  -348
      esp32:  -232

These files can also be used for F723, F732 and F733 MCUs.

Segments are separated by / and begin with the memory address.  This
follows how the ST DFU tool works.

This patch adds support to mboot for programming external SPI flash.  It
allows SPI flash to be programmed via a USB DFU utility in the same way
that internal MCU flash is programmed.

Prior to this patch the QSPI driver assumed that the length of all data
reads and writes was a multiple of 4.  This patch allows any length.  Reads
are optimised for speed by using 32-bit transfers when possible, but writes
always use a byte transfer because they only use a single data IO line and
are relatively slow.

This was accidentally added in 6abede2c

Fixes issue #3880.

And fix timeout value so that it does actually finish with reset_mode=1.

The DMA peripheral is limited to transferring 65535 elements at a time so
in order to send more than that the SPI driver must split the transfers up.

The user must be aware of this limit if they are relying on precise timing
of the entire SPI transfer, because there might be a small delay between
the split transfers.

Fixes issue #3851, and thanks to @kwagyeman for the original fix.

To match pin labels on other NUCLEO 64 boards.

This behaviour of a NULL write C method on a stream that uses the write
adaptor objects is no longer supported.  It was only ever used by the
coverage build for testing the fail path of mp_get_stream_raise().

With this patch objects are only checked that they have the stream protocol
at the start of their use as a stream, and afterwards the efficient
mp_get_stream() helper is used to extract the stream protocol C methods.

The existing mp_get_stream_raise() helper does explicit checks that the
input object is a real pointer object, has a non-NULL stream protocol, and
has the desired stream C method (read/write/ioctl).  In most cases it is
not necessary to do these checks because it is guaranteed that the input
object has the stream protocol and desired C methods.  For example, native
objects that use the stream wrappers (eg mp_stream_readinto_obj) in their
locals dict always have the stream protocol (or else they shouldn't have
these wrappers in their locals dict).

This patch introduces an efficient mp_get_stream() which doesn't do any
checks and just extracts the stream protocol struct.  This should be used
in all cases where the argument object is known to be a stream.  The
existing mp_get_stream_raise() should be used primarily to verify that an
object does have the correct stream protocol methods.

All uses of mp_get_stream_raise() in py/stream.c have been converted to use
mp_get_stream() because the argument is guaranteed to be a proper stream
object.

This patch improves efficiency of stream operations and reduces code size.

If the user button is held down indefinitely (eg unintenionally, or because
the GPIO signal of the user button is connected to some external device)
then it makes sense to end the reset mode cycle with the default mode of
1, which executes code as normal.

Functionality is unchanged.

This was a typo from the very first commit of this file.