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>
Depending on the linker script, the generated .bin file may start beyond
the beginning of the flash memory. However, no target address was passed
to cc2538-bsl.py by the upload make target, so it used the beginning of
the flash memory in all cases.
The load address of the lowest loadable output section is now passed to
cc2538-bsl.py. The start address of the .text output section or the
address of the _text symbol could have been used too, but this would not
have been compatible with all the possible custom linker scripts.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
No entry point was defined, so it defaulted to the beginning of the
.text output section where the vector table is located by default in
Contiki. Actually, the vector table may be located elsewhere, and the
ROM-based boot loader first reads the CCA to find the vector table.
Consequently, this commit sets the entry point to the CCA, which fixes
both the entry point and the initial symbol reference, so this commit
also removes the now-unneeded "__used__" and "KEEP" keywords from the
CCA.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The current CC2538 linker script in Contiki places the vector table at
the beginning of the flash memory / .text output section. However, this
location is arbitrary (the only requirement is that the vector table is
512-byte aligned), and custom linker scripts may be used with Contiki,
which means that Contiki may be used with a vector table placed
elsewhere. Thus, using the flash/.text start address in the CCA and as
the default NVIC VTABLE value was wrong.
This commit rather uses the address of the vectors[] array from
startup-gcc.c, which makes it possible to freely move around the vector
table without breaking anything or having to use a custom startup-gcc.c
and to configure the NVIC driver for that. Moreover, referencing the
vectors[] array naturally prevents it and its input section from being
garbage-collected by the linker, so this commit also removes the
now-unneeded "used" and "KEEP" keywords from the vector table.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The only thing needed for VTABLE is the absolute address of the vector
table. Splitting it between code/SRAM base and offset complicates things
and brings nothing.
Consequently, this commit merges the NVIC VTABLE configurations into a
single one giving the vector table absolute address.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
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>
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>
This commit tries to also fix the documentations of sicslowpan and
uip6 to reflect the current code state. I’m not sure if everything
makes sense.
sicslowpan: There are still some references to HC01, can this be
replaced by HC06?
uip6: Section about timers has changed, is this correct?
Doxyfile: The documentations reference static functions, to link to
them correctly EXTRACT_STATIC = YES is needed.
Congratulations you fixed 134 of doxygen's warnings (old: 134 new: 0).
This commit fixes nearly all of the reported doxygen warnings.
I tried to not clutter the log with removed trailing spaces.
Removed whitespace and converted tab/spaces for all files affected by this commit
are in a separate branch.
This commit simplifies the regression test for the doxygen build to
allow only 0 warnings.
Clean doxygen.runlog and doxygen.runerr for clean target
and ignore them in .gitignore.
This commit applies a number of improvements to the logic used when trying to drop to a CC13xx/CC26xx low-power mode:
* We identify whether there are any pending etimers by using `etimer_pending()` instead of `etimer_next_expiration_time()`. This subsequently allows us to also identify whether an etimer is set to fire at time 0.
* We run a larger portion of the code with the global interrupt disabled. This prevents a number of messy conditions that can occur if an interrupt fires after we have started the low-power sequence.
* We check whether there are pending events earlier in the sequence.
* We make sure to schedule a next wakeup event even when an LPM module prohibits deep sleep and forces sleep instead.
This fixes some of the issues discussed in #1236
