* Decouple 64-bit address from LINKADDR_SIZE
* get and set object from/to the start/end of the src/dest buffer
* We expect size == 8 (rather than size < 8) for both get_ and set_object. Error otherwise
* The RF no longer sets parameters by itself. We let the platform do this, using the extended API.
This avoids the limitation of having a single UART available at runtime, without
duplicating code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Because the CC2538 has a multi-byte SPI RX FIFO, flushing the buffer
requires more than just a single read. This adds a loop that empties the
entire RX buffer on a FLUSH().
Different SPI chips needs different SPI settings. This commit adds a
function that allows chip drivers to configure the SPI peripheral before
using it.
The frame pin the driver was using as a chip select does not work as
most devices expect it to. It toggles after every byte, and most chips
interpret that as end of message. To make drivers more reliable, each
chip driver should setup a GPIO and assert it as needed.
Contiki sometimes fails to boot correctly and locks up in
random_init()
This problem only manifests itself for specific versions
of the arm-gcc toolchain and then again only for specific
levels of optimisation (-Os vs -O2, depending on the
value of the SMALL make variable)
The lockup is caused when we write an RFCORE XREG before
the RF clock ungating has taken effect, which in turn
only occurs depending on the assembly generated for those
two instructions:
REG(SYS_CTRL_RCGCRFC) = 1;
REG(RFCORE_XREG_FRMCTRL0) = 0x00000008;
This commit makes the RNG wait for the ungating to take
effect before attempting to write the register
The following problems were present in the existing DCO calibration algorithm:
Problem #1. In function msp430_quick_synch_dco(), the "for(i=0; i < 1000; i++) { .. }" loop is optimized away by the compiler, as i is not volatile. Making i volatile would improve the results, but would not be sufficient: see the next point.
Problem #2. According to MSP430F2617 Device Erratasheet, bug BCL12 precludes a naive implementations of "fast" calibration altogether. The bug is present on all MCU revisions up to date.
The description of the bug:
"After switching RSELx bits (located in register BCSCTL1) from a value of >13 to a value of <12 OR from a value of <12 to a value of >13, the resulting clock delivered by the DCO can stop before the new clock frequency is applied. This dead time is approximately 20 us. In some instances, the DCO may completely stop, requiring a power cycle.
Furthermore, if all of the RSELx bits in the BSCTL1 register are set, modifying the DCOCTL register to change the DCOx or the MODx bits could also result in DCO dead time or DCO hang up."
In Contiki code for msp430f2xxx @ 8MHz, the RSEL search currently typically goes from 15 down to 11, thus violating the rules.
Step-by-step RSEL change is proposed as the best possible workaround:
"[..] more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."
Problem #3. The old Contiki code started from the highest possible calibration values: RSEL=15, DCOx=7. According to MSP430F2617
datasheet, this means that the DCO frequency is set to 26 MHz. For one, Vcc under 3V is not supported for this frequency, so this means that battery-powered nodes have a big problem. The minimal operating voltages are:
- 1.8V for RSEL <= 13
- 2.2V for RSEL = 14
- 3.0V for RSEL = 15
So the correct way is to always start calibration from RSEL <= 13, unless explicityly pre-calibred values are present.
Problem #4. Timer B should be turned off after the calibration, following the "Principles for Low-Power Applications" in MSP430 user's Guide.
The patch fixes these issues by performing step-by-step calibration and turning off Timer B afterwards. As opposed to MSP430F1xxx calibration, this algorithm does not change the ACLK divider beforehand; attempts to make calibration more precise would lead to looping in some cases, as the calibration step granularity at larger frequencies is quite big.
Additionally, the patch improves DCOSYNCH_CONF_ENABLED behavior, allowing the resynchronization to correct for more than one step.
The CC2538 currently has two addressing options: a hardcoded address set
at compile time or the address stored in primary address section of the
info page. This commit adds the option to choose the secondary location
of the ieee address from the info page, or any memory address.
To use, define `IEEE_ADDR_CONF_USE_SECONDARY_LOCATION` in `project-conf.h`
or similar.
For example:
#define IEEE_ADDR_CONF_USE_SECONDARY_LOCATION 1
