This patch replaces all occurences of the macro DEV_FAIL by -EIO
at the driver level. So this patch touch the files under drivers/,
include/ and samples/drivers/ when applicable.
This patch is part of the effort to transition from DEV_* codes to
errno.h codes.
Change-Id: I0594ab5dbe667e074c250129e7c13ce512ac940f
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
This patch replaces all occurences of the macro DEV_OK by the actual
value 0 at the driver level. So this patch touch the files under
drivers/, include/ and samples/drivers/.
This patch is part of the effort to transition from DEV_* codes to
errno.h codes.
Change-Id: I69980ecb9755f2fb026de5668ae9c21a4ae62d1e
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
The driver should read the mac address from the chip but in
case of cc2520, the chip does not have it. So generate a
random mac address for this invocation of the device.
Change-Id: I2d0cf2ee70525e7f5e65da9fb8ceaa1a2dccecdd
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This reverts commit bf77d902ac.
The commit is reverted because it causes hangs in packet
reception. After transferring data a while, the chip stops
packet reception.
Change-Id: Icb94e978e3ba526314afd5e80f35c877febe8740
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This reverts commit e695d43fad.
This commit allows reversal of the commit
bf77d902ac which is called
"cc2520: Rework reception logic". Original code had auto ACK
turned off so we can revert this commit too.
Change-Id: Ic4979d1caa0f4341b9642d8a83ee65cf71562994
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
setreg(CC2520_EXCFLAG0, 0) is in print_radio_status(), it should
be in print_exceptions_0().
Change-Id: I62bd366b850f0a1abef651cfa8de8939b6c30685
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
The auto ack does not seem to work properly. I am seeing that
the driver claims to have sent a packet but nothing is seen
in the air. Because of this the auto ACK cannot be turned on
right now as it would break connectivity.
Change-Id: I4e71e14a2058cc4f64740a8f4b390ba21a01cb23
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Setting the highest possible threshold is bogus. It will certainly work
well when packet are small, but it will be very easy to overflow RX FIFO
when these are big (which happens when a big packet is fragmented).
Instead:
- setting the threshold to the bare minimum (len + header)
- reading is made into a loop based on RX FIFO counter
Taking the opportunity to:
- Reset exceptions once printed out
- Print out "Transmitted!" instead of unbearable status
Change-Id: I8d77b88756d5c3fb42d4d0d38dd0296569db07ad
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
cc2520 does not need to clear any gpio interruption as it does not deal
with the low level gpio hardware directly.
Change-Id: Ic568e817b23b879cdf7da791417a4a6e1f95d34a
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
There is no such thing as being out of sync.
1 - RX FIFO is always flushed before receiving anything.
2 - So whatever comes in, if it was rejected the hardware would not set
FIFOP high (we are on high threshold, see page 83).
3 - According to 802.15.4 specs, length cannot be bigger than 127, so
7th bit of the length should never be set. However, and for some reason,
it happens to be set (noise, memory glitch?). According to datasheet
page 75, masking this bit is useful then. The hardware does it for
itself when filtering, and that does not affect the buffer content, so
it's also up to the driver to mask it as well.
Change-Id: I30b878852076c0c9d3a92b490aaf37f826ab4541
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The 100ms wait was too short. After some debugging, the
packets were successfully sent after 250ms wait.
Change-Id: Ib367f8df81ed3039b041f1e7b46d8f562a0adcac
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Instead of return 0 if there is an error, return
a value < 0 so that caller caller of cc2520_read()
can reject packet right away.
Change-Id: I99808db6aa692cf4415f630193d35e51d4bc3144
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If current packet is being rejected, it will print some more cc2520
internal insights in debug mode.
Change-Id: If63225e7dd025fb239a7bac5638624accfcc7f4f
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This is needed because in the microkernel, the system clock
is not yet running and the cc2520 driver needs that. By moving
the device initialization later, the clock gets to run and
the cc2520 driver works both in nanokernel and microkernel.
See also related commit 3c66686a43
for details.
Change-Id: Idc5530398b4cff2bb3e0955c8ab57c5f03344079
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The buf pointer in cc2520_read() points to memory that will
hold the received data. It must not be used to set RSSI and
link quality values. Very difficult to find memory corruption
was seen as we were overwriting memory in other part of the
system. The fix was to set the RSSI and link quality variables
in read_packet() where the buf pointer points to proper memory.
Change-Id: I49bfe37f4c7ccc0f582f3aecdf73d5b3ea6bb4e5
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Default cc2520/802.15.4 channel number is 26. Using Kconfig option
user will have chance to set different channel number between
11 and 26.
Change-Id: Id8f47ab5e328adae56e00adc6437c8ca8601a658
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
This helps saving stack but also fixes an error when unrelevant packet
detection is made and thus calls read_packet recursively.
Change-Id: I5c1130a369b573f204f30230417e5bcbb97257bc
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Original mechanism was useless, but it was due to the fact prototype
code was purely polling-based. Now that we are back to interrupt mode
only, it's actually required. It's done a different way than original
though as it was really redundant, and sometimes bogus (no release).
Change-Id: I36b55b072564ee2f9d331f49c69751d9d274bab2
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
As the GPIO callback is ran into ISR context, it's thus impossible to
start SPI transactions as these are interrupt based as well. Thus
forwarding the packet reading to an internal fiber.
If CONFIG_INIT_STACKS is set as well as debug mode, it will print out
the usage of the stack after each loop in read_packet().
CC2520 internal fiber stack size is set via Kconfig option, where the
default is set to 640 bytes. At this stage, this value cannot be fixed
so it's more flexible to be able to tweak it from a Kconfig option
rather than tweaking the source code.
Change-Id: I54138c4d1e66f6775b1ae0248574ac8eb5e44f3d
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
config_info data comes after driver_data (though the first one is
usually the one you use first, but anyway).
Fixes a bug introduced by my commit id
3eade319e878c7e11faf4cd93a99d33737e16e6c
Change-Id: I3f58b7fd9605270bb6edf24ae0d129313ac9ab2f
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Fix a build issue, as DEVICE_INIT() is the only macro used now and
others have been removed.
Change-Id: I69f7df168f5c4284104068b79ba9097d9a1904c1
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
SPI, to control the CC2520 chip, is the only generic feature and thus
the only one configurable through Kconfig. GPIO on the other end depends
a lot on the SoC/Board. Adding a slave select option as well.
Change-Id: I63068fab476ed8d5b26103e4ad20e5be253c9932
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
FIFOP setting is a wrong assumption to know if radio is on.
Transmission runs on clock basis instead of pre-set loop counter. Thus
removing useless config option relevantly as well.
Opmitizing a bit the code as well, and making cc2520_on() public for
testing purpose.
Change-Id: I4495d1d6c19d10dcbc18f7e2fd5041720ec1f438
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
CC2520 drivers as a singleton:
Current driver can only handle a single instance. This is due to the
gpio callback which cannot provide the concerned device (not the gpio
device, the cc2520 one). Setting a singleton instance for now, as the
network stack cannot handle more net devices anyway. This will be fixed
in the future.
In the mean time: improving a bit the usage of spi and gpio by accessing
the cc2520 instance directly.
Also: simplifying SPI usage, useless internal locking removed, better
debugging routines, better busy wait macro and use Zephyr's BIT() macro
instead of internal one.
Change-Id: I92b849135a92f77ee6a4374c9f662dcad8347814
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Integrating it into network stack. Centralizing all in drivers/802.15.4
Change-Id: Ia2916ff652afe5fe736f6560c2ed4a911a5f0679
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Andre Guedes