nuttx/drivers/wireless/ieee802154/xbee/Kconfig
Anthony Merlino bc60397e48 drivers/wireless/ieee802154/xbee: Adds CONFIG_XBEE_LOCKUP_WORKAROUND option and corresponding logic to workaround an issue where the XBee locks up and stops responding.
This typically happens when there is a lot of data being received over the link. When the XBee stops responding, many times, querying the XBee kicks it out of this state. However, occasionally the XBee is completely locked up and the XBee has to be reset. This change handles these conditions by periodically (if not naturally occuring) querying the XBee. If during any query, the XBee does not respond within a certain number of attempts, the XBee is reset.
2019-08-16 16:23:12 -04:00

47 lines
1.8 KiB
Plaintext

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
if IEEE802154_XBEE
config IEEE802154_XBEE_FREQUENCY
int "SPI Frequency for XBee Radio"
default 2000000
---help---
SPI SLCK frequency in Hz
config XBEE_NETDEV_RECVRPRIO
int "Priority of frame receiver registerd with the MAC layer"
default 1
---help---
When the MAC layer receives an incoming data frame, it passes the frame
to registered receivers, in order of receiver priority, until one of the
receivers claim the frame.
An example case would be when 6LoWPAN and the MAC character driver are
enabled. Both have receivers registered with the MAC. The 6LoWPAN layer
should get assigned a higher priority than the character driver. In this
case, the 6LoWPAN receiver will receive the frame first. If the frame is
a 6LoWPAN frame, it will claim the frame and the MAC will not pass the
frame to any additional receivers. If it does not claim the frame, the
MAC layer will call the next highest priority receiver, in this case,
the MAC character driver (which should always be lowest priority since
it is a "catch-all" type receiver).
config XBEE_LOCKUP_WORKAROUND
bool "Enable workaround to counteract XBee lockup"
default y
---help---
When receiving large amounts of data over the XBee, there is some probability
that the XBee will lockup and stop sending us data over SPI. In most cases,
querying the XBee will get it out of this state and communication will resume.
In some cases however, the XBee will freeze completely and won't ever respond
to our queries.
This workaround periodically queries the XBee if there hasn't been any
recent interaction. Additionally, if any query does not get a response
after 10 attempts, the XBee is reset.
endif # IEEE802154_XBEE