The pending GPIO power-up interrupts have to be cleared in the ISRs in order not
to re-trigger the interrupts and the wake-up events.
The power-up interrupts of all pins are cleared for each port in the
corresponding port ISR. This is done after calling the registered callbacks so
that the callbacks can know which pin woke up the SoC. This is done after
clearing the regular interrupt in order to avoid getting a new wake-up interrupt
without the regular interrupt in the case of a new wake-up edge occurring
between the two clears.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The GPIO power-up interrupts have to be configured and enabled in order to be
able to wake-up the SoC from PM1+ upon a signal edge occurring on a GPIO input
pin.
This set of macros allows to:
- configure the signal edge triggering a power-up interrupt,
- enable and disable a power-up interrupt,
- clear a power-up interrupt flag.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
As the comment in contiki-conf.h says, the automatic definition of
SLIP_ARCH_CONF_ENABLED works only if UIP_FALLBACK_INTERFACE is tied to SLIP. If
UIP_FALLBACK_INTERFACE is set to another interface, SLIP_ARCH_CONF_ENABLED is
still automatically set to 1, leading to unwanted SLIP_END characters from
dbg.c:putchar() being printed on the UART.
This change makes it possible to force the definition of SLIP_ARCH_CONF_ENABLED
(e.g. from project-conf.h), so that it can be disabled if UIP_FALLBACK_INTERFACE
is used with something else than SLIP.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
If PM2 is enabled with LPM_CONF_MAX_PM, but not active, the non-retention area
of the SRAM can be useful to place temporary data that does not fit in the
low-leakage SRAM, typically after having called lpm_set_max_pm(LPM_PM1). Hence,
give access to this non-retention area thanks to .nrdata* sections.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The data sheet recommends that the USB pull-up resistor be driven by a GPIO so
that it can be controlled by software, but this is not mandatory. Hence, leave
the choice so that CC253-based boards not using this option can build and work
fine.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Homogenize port and pin definitions naming:
- PERIPHERAL_FUNCTION_PORT for the port ID,
- PERIPHERAL_FUNCTION_PIN for the pin ID,
- PERIPHERAL_FUNCTION_PORT_BASE for the port base,
- PERIPHERAL_FUNCTION_PIN_MASK for the pin mask.
Define only PERIPHERAL_FUNCTION_PORT and PERIPHERAL_FUNCTION_PIN in board.h, and
deduce PERIPHERAL_FUNCTION_PORT_BASE and PERIPHERAL_FUNCTION_PIN_MASK in the
driver from the former definitions.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
According to IEEE 802.15.4e (§6.4.3.9), in order to detect duplicate received
MAC-layer frames, only the most recently received frame's sequence number needs
to be stored for each unique device address. Doing so limits the possible false
duplicate packet detections to a single sequence number. This also allows to
keep the last sequence number of more device addresses for the same value of
MAX_SEQNOS.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The code detecting duplicate packets in the RDC layer had been copied into most
RDC implementations. Factor it out into a new mac-sequence module in order to
have a single instance of this code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
According to IEEE 802.15.4 (§5.1.6.1, §6.4.2), the MAC sequence numbers should
be initialized to random values. This was already the case in
framer-802154.c:create(), but not in csma.c:send_packet(), sometimes causing
false detections of duplicate MAC-layer packets in other devices when a device
was restarted too quickly. This patch decreases the probability of such an
event.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
* Mesh: this is the normal case. Nodes route data on behalf of others and the node can be reached via a DAO route.
* Leaf: the node does not route data on behalf of others, but others can route data to the node (it has a RPL DAO route).
* Feather: this is a new type of node. A feather node routes data on behalf of others, but does not install DAO routes in the network. Feather nodes allow having a larger number of nodes than the RPL network can sustain in terms of routing tables.
This commit introduces the RPL node types and the feather mode, but does not add support for the leaf node type.
* Added a DAO lifetime timer that sends out a new DAO after half the lifetime of the DAO. This allows implementing DAO route soft state that avoids routing tables in the network keeping stale routes for ever.
* Added ways to schedule a new DAO transmission as well as cancelling an active DAO transmit timer, which makes it possible to do nodes that don't send DAOs.
