The block that controls the `.upload` target is unnecessarily replicated in multiple sub-board Makefiles. This was originally done because the SmartRF and the Launchpad can be programmed with the c2538-bsl script, whereas the sensortag cannot.
This commit moves the `cc2538-bsl` / `.upload` target logic to the top level cpu Makefile (`cpu/cc26xx-cc13xx/Makefile.cc26xx-cc13xx`). Board makefiles simply set the make variable `BOARD_SUPPORTS_BSL` to 1 to signal that they can be programmed by the BSL script. If `BOARD_SUPPORTS_BSL` is not equal to 1, trying to use the `.upload` target will return an error message.
For example:
```
$ make BOARD=sensortag/cc2650 cc26xx-demo.upload
using saved target 'srf06-cc26xx'
This board cannot be programmed with the ROM bootloader and therefore does not support the .upload target.
```
Bug fixes include:
- keep interrupts disabled during lpm_sleep() so that we don't
miss any interrupts we may have been expecting
- check that the pending etimer isn't already expired (and don't sleep
at all if it is)
- check that the about-to-be scheduled rtimer wakeup is neither too
far into the future nor too close into the future (or even in the
past) before actually setting the interrupt (should fix#1509); If
the time is out of bounds we use a default min or max value instead.
- Correctly handle LPM_MODE_MAX_SUPPORTED set to zero (and added a
macro for the zero value) so that sleeping can be disabled altogether
- If no etimer is set, we specify a wakeup time which is reasonably far
into the future instead of setting none at all (this will save on
power consumption whenever no etimers are set).
Also did a bit of refactoring in that some long functions were broken
into multiple functions.
When sending a command to the CC13xx/CC25xx RF core, we wait for command completion by checking the LSB of CMDSTA (correctly so). However, in doing so we also zero out the 3 CMDSTA return bytes. For some commands, those bytes contain useful information (e.g. an RSSI value) and are required by the caller.
This problem manifests itself e.g. in PROP mode `channel_clear()`, whereby the caller will always see an RSSI value of 0.
This pull therefore fixes the logic in `rf_core_send_cmd()` to check for command completion by blocking on the CMDSTA result byte without zeroing out the 3 return bytes.
Fixes#1465
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
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
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.
