CC2538: Add a Makefile rule to generate a final assembly listing.
Fix CC2538 random_init lockup

Contiki sometimes fails to boot correctly and locks up in
random_init()

This problem only manifests itself for specific versions
of the arm-gcc toolchain and then again only for specific
levels of optimisation (-Os vs -O2, depending on the
value of the SMALL make variable)

The lockup is caused when we write an RFCORE XREG before
the RF clock ungating has taken effect, which in turn
only occurs depending on the assembly generated for those
two instructions:

  REG(SYS_CTRL_RCGCRFC) = 1;

  REG(RFCORE_XREG_FRMCTRL0) = 0x00000008;

This commit makes the RNG wait for the ungating to take
effect before attempting to write the register
[SPI] Make SPI_FLUSH() more versatile

Currently the SPI driver in core/ sets `SPI_FLUSH()` to be a single read
of the spi RX buffer. This is fine for many microcontrollers, but newer
platforms like the CC2538 have a multi-byte FIFO for the RX buffer. In
that case, a single read is not guaranteed to flush the RX. This commit
allows `SPI_FLUSH()` to be platform dependent if needed, but doesn't
change for platforms where it works.
[CC2538-SPI] Implement SPI_FLUSH, spi mode, !CS

Because the CC2538 has a multi-byte SPI RX FIFO, flushing the buffer
requires more than just a single read. This adds a loop that empties the
entire RX buffer on a FLUSH().

Different SPI chips needs different SPI settings. This commit adds a
function that allows chip drivers to configure the SPI peripheral before
using it.

The frame pin the driver was using as a chip select does not work as
most devices expect it to. It toggles after every byte, and most chips
interpret that as end of message. To make drivers more reliable, each
chip driver should setup a GPIO and assert it as needed.
Add a note about "make cc2538-demo.lst" to the platform README.
Merge pull request #598 from lab11/spi-flush2

[SPI + CC2538] Update the SPI driver for CC2538
cc2538: uart: Make it possible to use several UARTs simultaneously

This avoids the limitation of having a single UART available at runtime, without
duplicating code.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Merge pull request #623 from ADVANSEE/cc2538-multi-uart

cc2538: uart: Make it possible to use several UARTs simultaneously
Merge pull request #616 from hexluthor/listing

CC2538: Add a Makefile rule to generate a final assembly listing.
Merge pull request #636 from g-oikonomou/fix-random-init-lockup

Fix CC2538 random_init lockup