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>
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 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 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
The AON RTC CH1 event handler aims to schedule the next compare event on the next 512 RTC counter boundary. However, the current calculation of "now" takes place too early within the interrupt handler. In some cases, this results in the next event getting scheduled too soon in the future or on some extreme cases even in the past.
AON RTC compare events cannot happen within 2 SCLK_LF cycles after a clearance (4 RTC ticks in the 16.16 format). Thus, if the next 512 boundary is too soon (5 ticks for margin), we skip it altogether. When this happens, etimers that would have expired on the skipped tick will expire 1 tick later instead. Skipping a tick has no negative impact on our s/w clock counter, since this is always derived directly from the hardware counter.
The current logic attempts to send `CMD_SET_TX_POWER` before saving the new power setting. If `CMD_SET_TX_POWER` fails the power setting will not get saved. As a result, when the RFC is powered off, all attempts to change TX power will fail.
This commit changes this logic to always save the new TX setting as requested by the user. If the RFC is powered up, we apply it immediately. If it is powered down, the new setting will automatically be applied next time we send `CMD_RADIO_SETUP`.
Fixes#1340
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
So far 80 column display was an attribute of a cc65 platform. Now each cc65 application can ask for 80 column display by defining WITH_80COL. Of course this is ignored by platforms incapable of 80 column display.
I see three types of application:
* Applications not benefitting from 80 column at all and in fact looking better with 40 column display. These are now using 40 column display. Examples: ethconfig, ipconfig
* Applications taking advantage of 80 column display if it is available without drawbacks. These stay as they were. Examples: Telnet server, web server, wget
* Applications needing 80 column display so urgently that it is likely desirable even if the display becomes harder to read. These come now in both flavors allowing the user to choose. Examples: IRC, web browser
Note: This change doesn't actually introduce any 80 column display with drawbacks. This if left to a subsequent change.
As discussed in #1294, every time a CC13xx/CC26xx RF interrupt fires, we clear all interrupt flags unconditionally. This may result in missed events. This patch fixes this bug by clearing only the flag that triggered the interrupt in the first place.
Fixes#1294
and should be removed. In the meantime we change those needed
to upload flash and eeprom to depend on the default contiki rule
to make the .$(TARGET) executable."
Prior to this patch, the ieee radio driver did not explicitly abort
the rx operation or power down the analog components of the radio
prior to shutting down the rf-core.
The result of this was that the rf-core continued to use a lot of
power even while "off".
This patch fixes this problem.
Fix for #1229
rf_core_cmd_done_en() was enabling the wrong irq for detecting the
completion of foreground operations. This was causing cc26xx devices
to not wake-up on time when calling lpm_sleep() from transmit().
* The clock interrupt must be scheduled relative to the last interrupt, not relative to the current time (which may have progressed significantly)
* clock_time() must increase continuously, so that code that may be spinning around clock_time() will make progress, not only after each interrupt
Added a mode, configurable by the CONTIKI_WATCHDOG_CONF_LOCK_BETWEEN_USE
macro, which locks the WDT register between uses so as to prevent
any accidental modifications
According to the TRM, the WDT does not produce a reset until it
expires twice. After expiring the WDT will set the INT flag if it
is unset, and reset the MCU if INT is already set.
Before this patch, watchdog_periodic() only un-sets the INT flag. This
means that the behaviour of watchdog_periodic is underministic in that
the value of the countdown timer will be different depending on
when the function was called.
This patch fixes this behaviour by also reloading the timout value.
This commit:
* Moves all cpu files from cpu/cc26xx to cpu/cc26xx-cc13xx
* Bumps the CC26xxware submodule to the latest TI release
* Adds CC13xxware as a submodule
* Adds support for sub-ghz mode / IEEE 802.15.4g
* Splits the driver into multiple files for clarity. We now have the following structure:
* A common module that handles access to the RF core, interrupts etc
* A module that takes care of BLE functionality
* A netstack radio driver for IEEE mode (2.4GHz)
* A netstack radio driver for PROP mode (sub-ghz - multiple bands)
This commit also adds tick suppression functionality, applicable to all chips of the CC26xx and CC13xx families. Instead waking up on every clock tick simply to increment our software counter, we now only wake up just in time to service the next scheduled etimer. ContikiMAC-triggered wakeups are unaffected.
Laslty, this commit also applies a number of minor changes:
* Addition of missing includes
* Removal of stub functions
* Removal of a woraround for a CC26xxware bug that has now been fixed
read_frame was misuing the packet length in the following ways:
- returning non-zero even if buf_len is too short for the packet
- truncating the length to buf_len if len is too long then using the
truncated (i.e. wrong) length to index into the buffer
- memcpying too many bytes (used buf_len instead of real length)
This commit fixes all of this and adds some code to report
on packet length errors (to match with cc2538 driver).
- moved variable declaration to top of function in accordance with the
Contiki style guide
- made function flatter, reduced nesting to improve readability
The DNS resolver requires 1/4 sec clock resolution. The retro targets had a 1/2 sec clock resolution (optimized for the 1/2 sec TCP timer) resulting in DNS resolver timeouts being 0. Therefore the retro target clock resolution is now increased to 1/4 sec.
There are scenarios in which it is beneficial to search for an Etherne chip at several i/o locations. To do so the chip initialization is performed at several i/o locations until it succeeds. In order to allow for that operation model the i/o location fixup needs to be repeatable.
Note: This won't work with the RR-Net because the fixup bits overlap with the chip i/o bits.
Enabling this option seems to greatly improve transciever performance with
Contikimac. This seems to happen because Contikimac CCAs are much less likely
to detect false positives (thus screwing up the CCA sequence).
Parts of the stm32w108 doxygen comments have explicit links to symbols that do not exist anywhere in our source base, let alone be documented. This is likely to be caused by a partial import of manufacturer libraries in the Contiki source tree.
These links were previously not generating warnings in the doxygen log because we were not defining `DOXYGEN_SHOULD_SKIP_THIS` and they were thus being skipped altogether by the doxygen pre-processor. Defining `DOXYGEN_SHOULD_SKIP_THIS` causes those doxygen comments to get processed and to thus generate warnings.
This commit removes explicit links to non-existent symbols and updates `doxyerrors.cnt` accordingly.
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>
Several keys can be kept at the same time in the key store, and several
keys can be loaded at once. Give access to these features.
The ccm-test example is also improved to better demonstrate the use of
the key store.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Using the AES interrupt allows the user process not to waste time
polling for the completion of the operation. This time can be used by
the user process to do something else, or to let the system enter PM0.
Since the system is now free to perform various operations during a
crypto operation, a protection of the crypto resource is added, and PM1+
is prohibited in order not to stall crypto operations.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The CC2538 the WDT cannot be stopped once it has been started.
The CC2530/1 WDT can be stopped if it is running in timer mode,
but it cannot be stopped once it has been started in watchdog mode.
Both platforms currently provide "dummy" implementations of `watchdog_stop()`,
one does nothing and the other one basically re-maps `_stop()` to
`_periodic()`.
This was originally done in order to provide implementations for all prototypes
declared in `core/dev/watchdog.h`. In hindsight and as per the discussion
in #1088, this is bad practice since, if the build succeeds, the caller will
expect that the WDT has in fact been stopped, when in reality it has not.
Since the feature (stopping the WDT) is unsupported by the hardware, this pull
removes those dummy implementations. Thus, we will now be able to reliably
detect - at build time - attempts at using this unsupported feature.
This is safer because the previous code assumed that the start and end
VMAs of .data and .bss were word-aligned, which is not always the case,
so the initialization code could write data outside these sections. The
ROM functions support any address boundary.
This is faster because the ROM functions are ultra optimized, using
realignment and the LDM/STM instructions, which is much better than the
previous simple loops of single word accesses.
This is smaller because the ROM functions don't require to add any code
to the target device other than simple function calls.
This makes the code simpler and more maintainable because standard
functions are not reimplemented and no assembly is used.
Note that this is also faster and smaller than the corresponding
functions from the standard string library.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The initialization code clearing .bss is allowed to use the stack, so
the stack can not be in .bss, or this code will badly fail if it uses
the stack.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
In order to be fast, the reset_handler() function uses word accesses to
initialize the .data output section. However, most toolchains do not
automatically force the alignment of an output section LMA to use the
maximum alignment of all its input sections. Because of that, assuming
that .data contains some words, the LMA of the .data output section was
not word-aligned in some cases, resulting in an initialization performed
using slow unaligned word accesses.
This commit forces the alignment of the LMA of the .data output section
with a word boundary in order to always use fast aligned word accesses
to read the .data load area.
Note that this solution is better than using ALIGN_WITH_INPUT, both
because the latter is a new feature incompatible with older toolchains,
and because it could create a big gap between _etext and the LMA of
.data if strongly-aligned data were added to .data, although only a word
alignment is required here.
The same considerations apply to the VMA of .data. However, it is
already automatically word-aligned, both because .data contains words,
and because the end VMA of the previous output section (.socdata) is
word-aligned. Moreover, if the VMA of .data were forcibly word-aligned,
then a filled gap could appear at the beginning of this section if
strongly-aligned data were added to it, thus wasting flash memory.
Consequently, it's better not to change anything for the VMA of .data,
all the more it's very unlikely that it does not contain any word and
that the end VMA of .socdata becomes non-word-aligned, and this would
only result in a slower initialization.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Some toolchains, like Sourcery CodeBench Lite 2013.05-23 arm-none-eabi
(http://sourcery.mentor.com/public/gnu_toolchain/arm-none-eabi/)
automatically force the alignment of an output section LMA to use the
maximum alignment of all its input sections. This toolchain uses GNU
binutils 2.23, and this automatic behavior is the same as the manual
behavior of the ALIGN_WITH_INPUT feature of GNU binutils 2.24+.
This behavior is not an issue per se, but it creates a gap between
_etext and the LMA of the .data output section if _etext does not have
the same alignment, while reset_handler() initialized this section by
copying the data from _etext to its VMA, hence an offset in the
addresses of loaded data, and missing data.
This commit fixes this issue by making reset_handler() directly use the
LMA of the .data section using LOADADDR(.data), rather than assuming
that _etext is this LMA.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
* Only enable TX by default.
* Add some magic for RX handling. When an input handler is registered:
* Automatically enable RX-related and interrupts
* Automatically lock the SERIAL PD on under all power modes
* Automatically enable the UART clock under sleep and deep sleep
* Automatically undo all of the above when the input handler becomes NULL
* As a result, modules / examples that need UART RX no longer need to clock the UART and manipulate the SERIAL PD. They simply have to specify an input handler
* Don't automatically power on the UART whenever the CM3 is active
* Before accessing the UART, make sure it is powered and clocked
* Avoid falling edge glitches
* Fix garbage characters / Explicitly wait for UART TX to complete
* Implement new style of PD locks
* Use our own shutdown sequence rather than the one provided by cc26xxware
* Shutdown from within the interrupt that requested it. This allows shutdown to take place even if the code is stuck in a loop somewhere else
* Improve DCDC/GLDO/uLDO switching logic
* Explicitly handle oscillators and retentions
Instead of using a separate data structure to request that a PD remain powered during deep sleep,
we do the same within the main LPM data structure through an additional field.
This allows us to maintain only one linked list of LPM modules and overall improves code clarity
This tutorial was written for the older implementation of CoAP, and
while it may be possible to update it, the directions include URLs and
repos that no longer exist, so it's better to just remove it.
Only the interrupt flags that have been handled must be cleared.
Otherwise, if a new interrupt occurs after the interrupt statuses are
read and before they are cleared, then it is discarded without having
been handled. This issue was particularly likely with two interrupt
trigger conditions occurring on different pins of the same port in a
short period of time.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Power-up interrupts do not always update the regular interrupt status.
Because of that, in order not to miss power-up interrupts, the ISR must
handle both the regular and the power-up interrupt statuses.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Introduce new useful GPIO macros to:
- get the raw interrupt status of a port,
- get the masked interrupt status of a port,
- get the power-up interrupt status of a port.
These macros are cleaner and less error-prone than raw register access
code copied all over the place.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Behave just like the CS8900A driver: Both the CS8900A and the LAN91C96 dynamically share a buffer for received packets and packets to be send. If the chip is exposed to a network with a lot of broadcasts the shared buffer might fill quicker with received packets than the 6502 reads them (via polling). So we might need to drop some received packets in order to be able to send anything at all.
OR-ing an offset to a base address instead of adding it is dangerous
because it can only work if the base address is aligned enough for the
offset.
Moreover, if the base address or the offset has a value unknown at
compile time, then the assembly instructions dedicated to 'base +
offset' addressing on most CPUs can't be emitted by the compiler because
this would require the alignment of the base address against the offset
to be known in order to optimize 'base | offset' into 'base + offset'.
In that case, the compiler has to emit more instructions in order to
compute 'base | offset' on most CPUs, e.g. on ARM, which means larger
binary size and slower execution.
Hence, replace all occurrences of 'base | offset' with 'base + offset'.
This must become a coding rule.
Here are the results for the cc2538-demo example:
- Compilation of uart_init():
* before:
REG(regs->base | UART_CC) = 0;
200b78: f446 637c orr.w r3, r6, #4032 ; 0xfc0
200b7c: f043 0308 orr.w r3, r3, #8
200b80: 2200 movs r2, #0
200b82: 601a str r2, [r3, #0]
* now:
REG(regs->base + UART_CC) = 0;
200b7a: 2300 movs r3, #0
200b7c: f8c4 3fc8 str.w r3, [r4, #4040] ; 0xfc8
- Size of the .text section:
* before: 0x4c7c
* now: 0x4c28
* saved: 84 bytes
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
