Riot: driver xbee and uart

Created on 2 Feb 2016  路  7Comments  路  Source: RIOT-OS/RIOT

Hi, i'm testing the xbee driver with an arduino-due board.
The current driver for xbee not work with the board, the driver stop run at line 126 of xbee.c:
while (dev->resp_limit != dev->resp_count) { mutex_lock(&(dev->resp_lock)); }

The same configuration and board work with riot release 2015.09.

Maybe the problem is into uart driver, but I think the xbee driver need to have a timeout. Because now riot is locked and it not log any info to detect the problem.

drivers network ARM question

Most helpful comment

This issue can be closed, as #4445 has been merged.

All 7 comments

Created PR #4734.

Following commits add extra debug outputs.

https://github.com/Yonezawa-T2/RIOT/commit/0b437f440d114a28bbc63c3c6a7ff9dc4ded4bfd
https://github.com/Yonezawa-T2/RIOT/commit/c16cd9281821aaec8c9dd8260a3a98db659e8ef5

Set ENABLE_DEBUG and XBEE_ENABLE_DETAILED_DEBUG to 1.

You may also be interested in #4445 if you have other problems.

I've tried the driver with the arduino-due and it still fails, but I think is a problem of uart.
But the xbee driver not work perfectly:
xbee_init not fails if _api_at_cmd fails, at example if _get_addr_long return a value <0 xbee_init must fail, something like:

if(_get_addr_long(dev, dev->addr_long.uint8, 8) < 0) {
        DEBUG("xbee: Initialization failed\n");
        return -1;
}

At last, not log the debug info "xbee: response timeout" into isr_resp_timeout but move it into _api_at_cmd, because in the first case it run in another thread and it can't always print the debug.

Created PR #4749.

Good, i've tested the new driver and it works as wanted.
I've noticed some other problems on xbee driver, in send function :

    dev->tx_buf[0] = API_START_DELIMITER;
    dev->tx_buf[4] = 0;         /* set to zero to disable response frame */
    /* set size, API id and address field depending on dst address length  */
    if (_is_broadcast(hdr)) {
        dev->tx_buf[1] = (uint8_t)((size + 5) >> 8);
        dev->tx_buf[2] = (uint8_t)(size + 5);
        dev->tx_buf[3] = API_ID_TX_SHORT_ADDR;
        dev->tx_buf[4] = 0xff;
        dev->tx_buf[5] = 0xff;
    }
    if (hdr->dst_l2addr_len == 2) {
        dev->tx_buf[1] = (uint8_t)((size + 5) >> 8);
        dev->tx_buf[2] = (uint8_t)(size + 5);
        dev->tx_buf[3] = API_ID_TX_SHORT_ADDR;
        memcpy(dev->tx_buf + 5, gnrc_netif_hdr_get_dst_addr(hdr), 2);
        pos = 7;
    }
    else {
        dev->tx_buf[1] = (uint8_t)((size + 11) >> 8);
        dev->tx_buf[2] = (uint8_t)(size + 11);
        dev->tx_buf[3] = API_ID_TX_LONG_ADDR;
        memcpy(dev->tx_buf + 5, gnrc_netif_hdr_get_dst_addr(hdr), 8);
        pos = 13;
    }
  1. in first if: tx_buf[4] is overwrite, destination short address is at index 5 and 6
  2. second if maybe it would be else if (hdr->dst_l2addr_len == 2)

Last question: destination long address how is obtained? because with my xbee it not matches.

@l3nko

I've noticed some other problems on xbee driver, in send function :
Yes. See #4445.

Last question: destination long address how is obtained? because with my xbee it not matches.

I don't sure that I understand your question correctly. XBee use short address as its source address unless its short address is configured to 0xFFFF. This also fixed in #4445.

This issue can be closed, as #4445 has been merged.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nmeum picture nmeum  路  5Comments

chrysn picture chrysn  路  5Comments

jia200x picture jia200x  路  7Comments

romainvause picture romainvause  路  3Comments

jcarrano picture jcarrano  路  5Comments