AT86RF2XX_DEFAULT_PAGE being ignored?

Hi all,

I’ve moved a 6LowPAN gnrc_networking project on the SAMR30-xpro from 2022.04 to 2023.1. In my previous build everything came up correctly and the radio would connect to the border router.

With 2023.01 it does not.

Looking at ifconfig I see the default channel page is being ignored and set to 0 for some reason. For the RF212B it should be 2 which is set here: sys/include/net/ieee802154.h:256:#define CONFIG_IEEE802154_DEFAULT_SUBGHZ_PAGE (2U)

and then here: drivers/include/at86rf2xx.h:#define AT86RF2XX_DEFAULT_PAGE

I see this as well with the gnrc_networking example as well. I have not been able to track down why its being ignored.

Has anyone else seen this?

Thanks, Matt.

I Still don’t know why the default page is being ignored but but I have worked around it programmatically:

uint16_t channel_page = 2;
netif_set_opt((netif_t*)&netif->netif, NETOPT_CHANNEL_PAGE, 0, &channel_page, sizeof(uint16_t));

hi @mattwood2000

I think I found the problem. After restructuring the driver, it turns out the variable dev->page is never being set. Since the device descriptor is allocated in the data segment, it is always zero.

This is definitely a bug (which we should fix for the upcoming release), but you can try this as a quick fix:

diff --git a/drivers/at86rf2xx/at86rf2xx.c b/drivers/at86rf2xx/at86rf2xx.c
index 77e6daab93..ee5626abce 100644
--- a/drivers/at86rf2xx/at86rf2xx.c
+++ b/drivers/at86rf2xx/at86rf2xx.c
@@ -85,6 +85,11 @@ void at86rf2xx_reset(at86rf2xx_t *dev)
     /* set default channel, page and TX power */
     at86rf2xx_configure_phy(dev, AT86RF2XX_DEFAULT_CHANNEL, AT86RF2XX_DEFAULT_PAGE, AT86RF2XX_DEFAULT_TXPOWER);
 
+    /* Record the default channel page in the device descriptor */
+#if AT86RF2XX_HAVE_SUBGHZ
+    dev->page = AT86RF2XX_DEFAULT_PAGE;
+#endif
+
     /* set default options */
 
     if (!IS_ACTIVE(AT86RF2XX_BASIC_MODE)) {

Please let me know if it works.

I opened a PR with the fix: drivers/at86rf2xx: fix default page being ignored by jia200x · Pull Request #19467 · RIOT-OS/RIOT · GitHub

Could you check whether this solves your problem?

Hi again,

I tested that patch on IoT-LAB and it seems to solve the issue.