Beaglebone black with UZ2400 unable to send packages

Added by Ivan Grujic almost 7 years ago


I am using the ZBOSS stack on a beaglebone black with a UZ2400 transceiver connected via SPI.

When running the zdo_start_zc test program,I don't see any packages sent on the sniffer (using default channel 15).

I have cross compiled the stack on a Ubuntu installation on my PC, the Options file is attached.
I build the test program using the eclipse cdt but with the given makefile provided in the test code (in /test/zdo_startup). All though I modified the BUILD_HOME define to my stack root directory.

I have modified the zb_transport_linux_spidev.h header with the line below to open the correct spidev device.
#define ZB_MAC_TRANSPORT_SPIDEV_PATH "/dev/spidev1.0"

I made a kernel module for the transceiver interrupt, which seems to be working fine. Interrupts are shown in the log at least, which is attached here.

I don't see any action on the sniffer or the terminal on the beaglebone, so i rely on the log to know whats going on.

As far as I can see from the log, everything goes fine until an attempt is made to send a beacon request.

/* Log line no 163
09:37:21.666 0 zb_uz2400.c:902 << zb_transceiver_send_fifo_packet, ret 0
09:37:21.666 0 mac_routines.c:302 << zb_beacon_request_command ret 0
09:37:21.666 0 mac_scan.c:369 mac set state 1 0 -> 16
09:37:21.666 0 mac.c:1649 mac st 0 (layer 1) 23
09:37:21.666 0 mac.c:1650 mac st 1 (layer 2) 16
09:37:21.667 0 mac.c:1651 mac st 2 (layer 3) 0
09:37:21.667 0 mac.c:1652 mac st 3 (rx) 0
09:37:21.667 0 mac.c:1653 mac st 4 (tx) 0
09:37:21.667 0 mac.c:1170 ignore_tx_cnt 0
09:37:21.667 0 mac.c:1195 cmd tx status -2
*/ Log

And for some reason when the transceiver interrupt occurs the interrupt status register (ISRSTS) is 0x01, with the transmit status register (TXSR) being 0x21.
/* Log line no 249
09:37:21.684 2 zb_scheduler.c:118 uz2400 int!
09:37:21.684 2 zb_uz2400.c:89 Ints: 0, checks: 2
09:37:21.685 2 zb_mac_transport_linux_spidev.c:164 tx #68 len 1
09:37:21.686 2 zb_mac_transport_linux_spidev.c:203 rx #69 len 1
09:37:21.686 2 zb_uz2400.c:92 interrupt: 0x1
09:37:21.686 2 zb_uz2400.c:121 TX counter: 1
09:37:21.687 2 zb_mac_transport_linux_spidev.c:164 tx #70 len 1
09:37:21.687 2 zb_mac_transport_linux_spidev.c:203 rx #71 len 1
09:37:21.687 2 zb_uz2400.c:130 tx status: 0x21
*/ Log

To my knowledge the 0x21 register value means a "normal" transmit interrupt has occurred, but with the error : Bit 5 CCAFAIL: Channel busy causes CSMA-CA fails.
I have checked the channel with a sniffer and there is not nearly enough traffic to cause this error consistently. Some device is broadcasting a message every other second, along with some random bursts now and then.
Another interesting thing I have noticed, which is also shown in the log file starting at line 464, is that the device actually receives the broadcast message. But since the security key is unknown the message is dropped (I assume), which is also the appropriate behavior in my opinion.

I guess the problem boils down to being able to receive packages but not send them.