Commit graph

39 commits

Author SHA1 Message Date
Benoît Thébaudeau bd961d1cd3 cc2538: Fix possible linker script breakage
The conditional definitions in project-conf.h depending on
CONTIKI_TARGET_<TARGET_NAME> were ignored at link time, which broke the
linker script if it used these definitions, so the flashed applications
could crash or malfunction.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-05-30 23:05:14 +02:00
Benoît Thébaudeau ccceb63e88 cc2538: Add crypto driver and example for AES-GCM
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-01-06 23:22:54 +01:00
Benoît Thébaudeau e77e9861fe cc2538: Add crypto driver and example for AES-CBC-MAC
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-01-06 23:22:53 +01:00
Benoît Thébaudeau 47c24cab11 cc2538: Add crypto driver and example for AES-CTR
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-01-06 23:22:53 +01:00
Benoît Thébaudeau cf5e9557f8 cc2538: Add crypto driver and example for AES-CBC
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-01-06 22:01:41 +01:00
Benoît Thébaudeau 69eacbddbe cc2538: Add AES-CCM* driver
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-01-04 00:28:27 +01:00
kkrentz 24cb05059a CC2538: Add AES-128 driver 2016-01-04 00:28:27 +01:00
Benoît Thébaudeau 3dbe4c9403 cc2538: Add crypto driver and example for AES-ECB
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2016-01-04 00:28:26 +01:00
Andreas Dröscher 31230a856e Implement generic Newlib syscalls 2015-12-16 19:50:49 +01:00
Benoît Thébaudeau 648b6926b5 Merge pull request #1102 from bthebaudeau/cc2538-build-without-contiki-target-library
cc2538: Build without the Contiki target library
2015-12-05 00:42:31 +01:00
Antonio Lignan 37fcb927be Added PWM driver for the Zolertia Zoul module and CC2538 platforms 2015-11-25 23:56:29 +01:00
Benoît Thébaudeau 5d98cb71e2 cc2538: Add support for Coffee
Coffee is placed by default at the beginning of the flash memory, right
before the firmware. This avoids the memory gaps that there could be
before and after Coffee if it were placed after the firmware, because it
is unlikely that the end of the firmware is aligned with a flash page
boundary, and the CCA is not flash-page-aligned. Thanks to that, Coffee
is also always in the same flash area if its size remains unchanged,
even if the firmware changes, which makes it possible to keep the Coffee
files when reprogramming the firmware after a partial flash erase
command.

The default configuration of Coffee is set to use sensible values for a
typical usage on this SoC, i.e. for sensor data logging.

The default size of Coffee is set to 0 in order not to waste flash if
Coffee is unused.

COFFEE_CONF_CUSTOM_PORT can be defined to a header file to be used with
"#include" in order to override the default CC2538 port of Coffee. This
makes it possible to use Coffee with an external memory device rather
than with the internal flash memory, without having to alter the Contiki
files.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2015-11-19 01:22:58 +01:00
Benoît Thébaudeau efb4b858e2 cc2538: Define the flash memory organization
Define the flash memory page and word sizes. These definitions are
grouped with the flash lock bit page and CCA definitions, so flash-cca.h
is renamed to flash.h.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2015-11-19 01:18:33 +01:00
Benoît Thébaudeau 790c253d6d cc2538: Define and use device features
Define the available CC2538 devices and their features, and use them to
define the linker script memory regions. The .nrdata output section is
now always defined in order to trigger an error if it is used but no
memory is available for it. The CC2538 device used by Contiki is made a
configuration option, the CC2538SF53 device being the default.

This makes more sense than defining the flash memory address and size as
configuration options like previously, all the more not all values are
possible and all the features are linked by each device.

This change also makes it possible to:
 - use the correct SRAM parameters for the CC2538NF11,
 - know at build time if the AES, SHA, ECC and RSA hardware features are
   available on the selected CC2538 device.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2015-11-19 01:18:33 +01:00
Simon Duquennoy fbd78a7e3b Merge pull request #1293 from simonduq/pr/fix-warnings
Fix a number of compiler warnings and enable -Werror in Travis
2015-11-10 08:49:11 +01:00
Adam Dunkels 12a185f394 Added the WERROR=1 flag to the CC2538 and CC26xx CPUs 2015-10-20 10:11:23 +02:00
AntiCat d631270af4 cc2538: Add PKA drivers, ECC algorithms and examples 2015-10-18 20:14:17 +02:00
Benoît Thébaudeau afe5d0403d cc2538: Build without the Contiki target library
The GNU linker ld searches and processes libraries and object files in
the order they are specified. Library files are archive files whose
members are object files. The linker handles an archive file by scanning
through it for members that define symbols that have so far been
referenced but not defined. But an ordinary object file is linked in the
usual fashion.

The C library is implicitly linked after all object files and libraries
specified on the command line.

Because of that, if the C library depends on the Contiki target library,
e.g. for the implementation of system calls, then these dependencies are
not linked, which results in undefined references. Actually, the Contiki
target library also needs the C library, hence a circular dependency
between these libraries, which means that explicitly adding -lc anywhere
on the command line can not help. The only solution in that case is to
pass these libraries to ld between --start-group and --end-group.
Archives grouped in this way are searched repeatedly by the linker until
no new undefined references are created.

This archive grouping option has a significant performance cost for the
linking stage. Moreover, having to use it and to pass -lc explicitly on
the command line is unusual, which is disturbing and more complicated
for users needing the C library to depend on the Contiki target library.
The same would be true for circular dependencies between the Contiki
target library and any other library.

Another issue with the Contiki target library is that it may alter the
apparent behavior of the weak vs. strong symbols, because of the way ld
handles archives, which may make it discard archive object files
containing strong versions of referenced symbols:
 - If a symbol has a weak and a strong version in this library, both
   inside the same object file, then the linker uses the strong
   definition.
 - If a weak symbol in this library has a strong counterpart in an
   object file outside, then the linker uses the strong definition.
 - If a strong symbol in this library is inside an object file
   containing other referenced symbols, and has a weak counterpart
   anywhere, then the linker uses the strong definition.
 - If a strong symbol in this library is the only symbol referenced in
   its object file, and has a weak counterpart in an object file
   outside, then the linker uses the strong definition if this library
   is linked first, and the weak one otherwise.
 - If a strong symbol in this library is the only symbol referenced in
   its object file, and has a weak counterpart in another object file in
   this library, then the linker uses the definition from the first of
   these objects added when creating this archive.
 - If a symbol has a weak and a strong version, one in this library, and
   the other in another library, then the rules are the same as if both
   were in the Contiki target library.

The existence of cases where the linker uses a weak symbol despite the
presence of its strong counterpart in the sources compiled then passed
to the linker is very error-prone, all the more this behavior depends on
the order the object and archive files are passed on the command lines,
which may just result from the order of source files in lists where it
apparently does not matter. Such cases would be needed in the future,
e.g. to define weak default implementations of some system calls that
can be overridden by platform-specific implementations, both ending up
in the Contiki target library. There was already such a case used to
define the UART and USB ISRs as weak aliases of default_handler(),
relying on this implicit unusual behavior to keep default_handler() if
the UART or USB driver was unused, which was dangerous.

Since the Contiki target library was only used as an intermediate file
during the build, the current commit fixes these issues by simply
directly using the object files instead of building an intermediate
archive from them.

The CONTIKI_OBJECTFILES make variable would be incomplete if it were
used as a simple prerequisite in the %.elf rule in Makefile.cc2538,
because other object files are added to it after this rule. That's why
.SECONDEXPANSION is used to defer its expansion. Another solution would
have been to split Makefile.cc2538, with the variable assignments kept
in it, and the rule definitions moved to Makefile.customrules-cc2538,
but this would have required to add Makefile.customrules-<target> files
to all CC2538 platforms, only to include Makefile.customrules-cc2538.
The solution used here is much simpler.

Because the UART and USB ISRs were weak aliases of default_handler(),
this change would imply that these ISRs would always be used by the
linker instead of default_handler(), even if their drivers were
configured as unused with UART_CONF_ENABLE and USB_SERIAL_CONF_ENABLE,
which would be wrong. This commit fixes this issue by removing these
weak aliases and putting either these ISRs or default_handler() in the
vector table, depending on the configuration. Weak aliases are elegant,
but Contiki's build system does not currently allow to automatically
build or not source files depending on the configuration, so keeping
these weak aliases would have required to add #if constructs somewhere
in the source code, which would have broken their elegance and made them
pointless.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2015-06-05 21:55:51 +02:00
Benoît Thébaudeau 117dc4e5e3 cc2538: Add crypto drivers and examples for AES-CCM and SHA-256
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
2015-06-02 21:41:06 +02:00
Benoît Thébaudeau d64927397f Merge pull request #968 from g-oikonomou/cc2538-contrib-on-chip-sensors
Move CC2538 VDD/3 and On-Chip Temp sensors to the CPU dir
2015-05-14 19:21:56 +02:00
Benoît Thébaudeau 71f22b1775 Merge pull request #966 from g-oikonomou/cc2538-startup-to-cpu-dir
Move cc2538 startup-gcc.c to the CPU dir
2015-05-14 18:43:39 +02:00
George Oikonomou 96e1647270 Move cc2538 startup-gcc.c to the CPU dir 2015-05-13 01:31:10 +01:00
George Oikonomou 06b0ee4a8b Include CC2538 sensors in the build 2015-05-12 23:42:19 +01:00
Antonio Lignan 22be9fd8b7 I2C driver taken from PR #677, uncrustified, made functions static and added burst modes 2015-03-25 16:44:12 +01:00
George Oikonomou 49bf7cc241 Merge pull request #616 from hexluthor/listing
CC2538: Add a Makefile rule to generate a final assembly listing.
2014-04-17 22:13:52 +01:00
George Oikonomou 33abe26ec8 Merge pull request #411 from ADVANSEE/cc2538-adc
cc2538: Add adc driver and example
2014-04-13 03:05:12 +01:00
Ian Martin 56d0dfdc7a CC2538: Add a Makefile rule to generate a final assembly listing. 2014-04-02 18:17:49 -04:00
George Oikonomou 332d56ac11 Make some CC2538 CFLAGS and LDFLAGS common
Some CFLAGS and LDFLAGS previously only enabled with SMALL=1 have
now been enabled for all builds, regardless of the value of SMALL.

Therefore, from now on, SMALL only chooses between -Os and -O2
2014-01-31 20:02:43 +00:00
George Oikonomou a63376f8be Use -Os for CC2538 builds
As discussed in #503, -Os was broken with one of the toolchains
recommended in the platform's README and for that reason we were
using -O2 by default.

This commit sets the default to -Os and updates the README to no
longer recommend the toolchain in question
2014-01-31 20:02:43 +00:00
George Oikonomou c8fbf8ca6e Merge pull request #503 from ADVANSEE/cc2538-nrdata-noload
cc2538: Clean up link stage
2014-01-30 07:58:55 -08:00
Benoît Thébaudeau a562acb160 cc2538: Fix library linkage
If a project needs to use some libraries at link stage, then the corresponding
linker options (e.g. '-lm') have to be passed after any .o file depending on
these libraries. Hence, LDFLAGS cannot be used to add such options when invoking
$(LD) in Makefile.cc2538, or it should be moved to the correct location.
Instead, this change adds TARGET_LIBFILES to the correct location, like most
other Contiki targets.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
2014-01-28 14:32:30 +01:00
Benoît Thébaudeau ab4b955f17 cc2538: Sort link input sections by alignment to optimize size
Normally, the linker does not sort files and sections matched by wildcards, so
they are placed in the order in which they are seen during link. If numerous
objects with different alignments are mixed, or if objects with unusually large
alignments are present, this very likely leads to a lot of space being wasted
because of accumulated alignment gaps.

This commit forces input sections to be sorted by alignment (unless this is
overridden by the linker script), which decreases the number and the size of
alignment gaps, thus saving space.

For a typical Contiki project, this change saves nearly 1 kiB, mainly in .bss.

Note that this behavior is only enabled if the SMALL make variable is set to 1,
because this makes more sense for a size optimization.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
2013-12-19 21:45:27 +01:00
Benoît Thébaudeau dbba311270 cc2538: Add adc driver and example
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
2013-12-06 22:07:45 +01:00
Benoît Thébaudeau a7d10ce2ad cc2538: Make it possible to use a custom linker script
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
2013-11-15 15:41:58 +01:00
Benoît Thébaudeau 974850cdf2 cc2538: Generate .hex output
ELF files generated by GCC make SmartRF Flash Programmer 2 crash (only the TI
format is supported by this tool for ELFs), and binary files are not very
appropriate because they are gapless, so generate Intel HEX files since these
are very well supported by most programming tools while still flexible.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
2013-11-15 15:41:58 +01:00
Brad Campbell e2af903d05 Added SPI driver for CC2538
This uses the core/dev/spi.h header and implements the spi_init()
function and the various macros for SPI operation. ssi.h contains all of
the register locations and information.

This implementation is not very versatile, mostly because I don't how to
make it flexible in the contiki system. It supports pin muxing for the
four spi pins, but other than that picks sensible defaults.

The SPI macros (like SPI_READ()) are defined in
cpu/cc2538/spi-arch.h. In order to use the SPI driver, add the following
includes to your project:

    #include "spi-arch.h
    #include "dev/spi.h"
2013-09-27 17:46:15 -04:00
George Oikonomou c3b5d4f5e3 Add support for verbosity control 2013-08-07 15:26:22 +01:00
Peter A. Bigot 5fc0575e99 Makefile.include: support make clean all
Historically $(OBJECTDIR) was created when Makefile.include is read.  A
consequence is that combining "clean" with "all" (or any other build
target) results in an error because the clean removes the object
directory that is required to exist when building dependencies.
Creating $(OBJECTDIR) on-demand ensures it is present when needed.

Removed creation of $(OBJECTDIR) on initial read, and added an order-only
dependency forcing its creation all Makefile* rules where the target is
explicitly or implicitly in $(OBJECTDIR).
2013-06-20 17:45:41 -05:00
George Oikonomou 40f49948e6 New Platform: TI CC2538 Development Kit
This commit adds cpu, platform and example files,
providing support for running Contiki on TI's cc2538 DK
2013-04-06 21:07:31 +01:00