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
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 sent ICMP6 packets (for example from RPL) are currently
not counted towards the sum of sent ip and icmp packets.
Is there any reason behind this or is it just a bug?
Looking at the code I found no side effects of adding these two lines.
Debug output:
```
uip_stat.ip .recv 10 .sent 23 .forwared 0 .drop 0
uip_stat.icmp .recv 10 .sent 11 .drop 0
uip_stat.udp .recv 0 .sent 12 .drop 0
```
(Sum of ip.sent matches icmp.sent and udp.sent)
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
