IEEE 802.15.4 MCR20A driver problem sending packets

[zephyrbot]

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 #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)

[zephyrbot]

by Jukka Rissanen:

• prj_frdm_k64f_mcr20a.conf (size: 1521)

[zephyrbot]

by Johann Fischer:

1. seems to be the same issue as reported here ieee802154_shell.c, net_mgmt call leads to a BUS FAULT #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)

[zephyrbot]

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?

[zephyrbot]

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.

[zephyrbot]

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 ...

[zephyrbot]

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 #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.

[zephyrbot]

by Jukka Rissanen:

Disabling ack did not help.

So current status of the issues I am seeing:

• RX seems to work ok
• 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 will update the border router sample app in #980 if anyone wants to try that too.

[zephyrbot]

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?

[zephyrbot]

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

[zephyrbot]

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.

[zephyrbot]

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.

[galak]

@jfischer-phytec-iot is this still an issue?

[jfischer-no]

not sure, I know there is a issue related to FRDM-K64F and MCR20A, e.g. simple ping from linux host or other node over 802.15.4 makes SPI driver logic broken after a while, whereby USB-KW24D512 works without any problems in the same test setup. I am not sure if it's the MCR20A driver or the SPI driver. I need to test current master.

[tbursztyka]

@jfischer-phytec-iot It think it's unlikely to be spi driver, unless you use a too aggressive frequency, because we have been using cc2520 on top of frdm and it works perfectly well with the same spi driver below.

[jfischer-no]

@tbursztyka I do not really suspect the SPI driver, but I have noticed that after a long time, k_sem_take (in spi_mcux_transceive(...)) did not block even though the count was at zero and the transfer not finished. I have observed it on FRDM-K64F and FRDM-CR20A. But the code has changed and I have to check it again.

[tbursztyka]

ouch that sounds like a deeper issue if semaphore seems to bug then

[nashif]

@jfischer-phytec-iot any updates on this?

[carlescufi]

Re-investigate this one once the new SPI driver API (and driver implementation lands)

[tbursztyka]

Afaik this is working fine, since commit id 9078378

[nashif]

@jukkar can you still reproduce this?

[tbursztyka]

That's super old, mcr20a got changes since then (I moved it to new spi api), and it proved to work well in Ravi's RPL BR sample. Let's close this.