search

zephyriot / zephyr-issues

0 stars 0 forks source link

IEEE 802.15.4 MCR20A driver problem sending packets #2310

Open nashif opened 7 years ago

nashif commented 7 years ago

Reported by Jukka Rissanen:

Just noticed two issues with ieee802154_mcr20a.c driver.

  1. It is not possible to set the used channel using management interface. When trying to do that this is printed [dev/mcr20a] [ERR] mcr20a_set_channel: Failed to reset XCV sequence

  2. Many packets (but not all) that are suppose to be sent, are not seen by 802.15.4 sniffer. This indicates that the packet is dropped by the driver. This is printed when sending (not sure if related to this issue).

[dev/mcr20a] [DBG] mcr20a_tx: 0x20011a80 (48) [dev/mcr20a] [DBG] mcr20a_abort_sequence: CTRL1 0x38 [dev/mcr20a] [DBG] mcr20a_timer_set: now: 0x4ba1 set 0x79df [dev/mcr20a] [DBG] _irqsts3_event: Sequence timeout, IRQSTSs 0x0a 0x08 0x78 [dev/mcr20a] [DBG] mcr20a_thread_main: WB: 0x7f | 0x08 | 0x78 [dev/mcr20a] [DBG] mcr20a_tx: done

This issue was seen when working with RPL border router sample https://github.com/zephyrproject-rtos/zephyr/pull/980 which is currently WIP. In this case I am using at the same time both the ethernet (frdm_k64f) and 802.15.4 (mcr20a) network interfaces. The ethernet interface works ok.

(Imported from Jira ZEP-2479)

nashif commented 7 years ago

by Jukka Rissanen:

nashif commented 7 years ago

by Johann Fischer:

  1. seems to be the same issue as reported here GH-3863. If both interfaces are enabled the channel can not be changed from the shell :-)

  2. the sender has not received an ACK after TX sequence, ACK handling can be turned off (L:53, MCR20A_AUTOACK_ENABLED macro)

nashif commented 7 years ago

by Johann Fischer:

Jukka Rissanen Can you please describe your test setup more, how many 802154 nodes in the network? What for sample runs on the nodes?

nashif commented 7 years ago

by Jukka Rissanen:

The test setup consisted of one frdm_k64f + mcr20a node running the rpl-border-router sample app, and one quark_se_c1000_devboard node (cc2520 based) running RPL client software.

Anyway, I will do more testing by turning off the ACK handling so we see if that improves things.

nashif commented 7 years ago

by Johann Fischer:

Update for 1: The mcr20a_set_channel will fail immediately after the start because the transceiver is still in the TX or TX_RX mode, these sequences should not be aborted when calling from the set_channel (force = false). There is somewhere a bug with interrupt handling, the transceiver and driver continue to work and I can ping the device ...

nashif commented 7 years ago

by Jukka Rissanen:

I can confirm this. When device starts, I see the "mcr20a_set_channel: Failed to reset XCV sequence" error, but later the channel can be set properly (no error is seen). I have the https://github.com/zephyrproject-rtos/zephyr/pull/1054 applied in my test.

It is actually a bit cumbersome to use this device if the channel cannot be set during device startup. Currently there is support for setting up IEEE 802.15.4 radios automatically when device starts (see subsys/net/lib/app/init.c for details) which does not then work properly with this hw.

Testing next the ack settings.

nashif commented 7 years ago

by Jukka Rissanen:

Disabling ack did not help.

So current status of the issues I am seeing:

I will update the border router sample app in https://github.com/zephyrproject-rtos/zephyr/pull/980 if anyone wants to try that too.

nashif commented 7 years ago

by Johann Fischer:

Btw, the driver must know during tx, whether it expects an ACK or not (e.g. FCF: ACK_REQ is false in neighbor solicitation packet), is there a simple way for this?

nashif commented 7 years ago

by Johann Fischer:

TX works very randomly. Most of the sent packet (seen in the zephyr console log) are not shown by wireshark. Wireshark shows some packets with Bad FCS at some >point. Reading the channel value returns always 0 (ieee15_4 get_chan)

I can not confirm this, there are some problems regarding ACK handling but ping and rpl work, I test it with FRDM-K64F (SYS_LOG_IEEE802154_DRIVER_LEVEL=4) against RIOT OS (gnrc_networking) on the phytec board with KW2xD

nashif commented 7 years ago

by Jukka Rissanen:

If you do not see any TX errors, then perhaps my board is broken or something, or I have something wrong in the config file. The same application software works ok in frdm_k64f + cc2520 board.

nashif commented 7 years ago

by Johann Fischer:

I have tested the driver yesterday and today and if I put it a little under stress (like ping6 -c 100 -i 0.1 -s 60 fe80::204:9fff:fe9e:f916%wpan0) then get errors that are really hard to debug, e.g. spi_mcux_transceive: Transfer could not start or mcr20a_thread_main is running but the semaphore has not been released by the ISR.