Beagleplay Quickstart issues

I went through the quickstart guide for the Play, and found a few issues, along with some solutions.

  1. python virtualenv can’t run (west flash), but the global environment can. That’s because the global environment gets gpiod from Copying this file from the global packages folder, /usr/lib/python3/dist-packages/ to the virtualenv packages folder, /home/debian/zephyr-beagle-cc1352-sdk/zephyr-beagle-cc1352-env/lib/python3.9/site-packages/ fixes this.

  2. zephyr micropython fails to build with undefined references to console_init, and some other console_xxx functions. Run menuconfig from the micropython/play folder with “west build -t menuconfig”. Enable “device drivers → serial drivers → uart interrupt support”, and “device drivers → console drivers → use uart for console”. Only once these two settings are enabled will “sub systems and os services → console subsystem / support routines” change from binary selection to a deeper menu, where “console get function” can be selected. With these three menuconfig changes, micropython now builds.

  3. micropython can’t access gpio because the gpio node doesn’t have a label in the device tree. In zephyr-beagle-cc1352-sdk/zephyr/boards/arm/beagle_play_cc1352/beagleplay.dts, find the &gpio0 node, and add a label.


after rebuilding and reflashing micropython, the following script can control LEDs:

from machine import Pin

pin_27 = Pin((“GPIO_0”, 27), Pin.OUT)
pin_28 = Pin((“GPIO_0”, 28), Pin.OUT)


Thank you so much for trying things out, reporting issues and discovering workarounds. Please feel encouraged to report issues at Zephyr · GitLab and

UPDATE: I made several comments below that probably won’t make sense. I just went back and re-read your comment–you are talking about Micropython on BeaglePlay, not on BeagleConnect Freedom. I never went back and retested those steps as I figured most people would just use the WPANUSB firmware, at least initially. I’ll go back and fix the Micropython release and documentation for that. Thanks.

Shouldn’t this be installed with the requirements?

I’ll try this again on a fresh install and make sure all the dependencies are there. I think installing them with pip should be the right way, rather than copying them from the Debian file system. My goal with virtualenv was to try to avoid cross-polluting the Debian file system with pip-based installs, so I’ll make sure the instructions for building the virtualenv are complete.


Yeah, the head of the tree involves some other hacking involving putting Greybus in as a service to the Micropython image. Based on early user feedback, Micropython gives a quick development environment familiar to many MCU users. We are working on integrating control over the Greybus service into the Micropython environment such that users can easily choose if they want local or remote control over the peripherals.

Just so you know where we are at, we are fighting through the file-system conflicts between Zephyr (mcumgr) and Micropython and it shouldn’t take too much longer to figure out how to make them both happy.

Odd. The production firmware release should have been 0.0.3, which is based on commit bfd5361e, which includes commit, which I’m recalling now doesn’t have a hard-coded version of the Zephyr tree, just used the demo branch. However, it was expected to pick up the commit to add the deprecated label. I know this was tested per my release notes, but this isn’t the way to make a stable release, nor is it the right fix as Zephyr is moving away from using labels to reference GPIOs.

Can you try using gpio@40022000 on the released image, rather than GPIO_0?

I couldn’t get the wpanusb to work either. When running the linux image that came flashed from the factory, both lowpan0 and wpan0 show up in my ifconfig once Im running the firmware on the cc1352, but I don’t get a global ipv6 address in lowpan0. I downloaded an SD card linux image from 2023-03-13, and once the cc1352 firmware is loaded and bcfserial is running, I don’t see wpan0 or lowpan0 in ifconfig at all.

For the micropython gpio issue, I took out the dts label change, and rebuilt micropython. initializing the Pin class with gpio@40022000 was successful.

For the west flash issue, I deleted my virtualenv and did pip3 install -r reqiurements-base.txt. Once done, I actually get two different failures running west flash.

The first failure is importing gpiod. Nothing in requirements-base.txt looks related to gpio, so Im not sure what is supposed to trigger its installation. I’ve looked through all of the requirements-*.txt, and I don’t see anything that looks like it would install gpiod. Even the global python environment’s pip doesn’t seem to know about the, as “pip show gpiod” says its not installed.

After copying the gpiod .so, I also got a traceback complaining about pyserial. That one was simple to install with pip, it just needs to be added to requirements-base.txt. Its currently in requirements-run-tests.txt.

I tried accessing the gitlab to raise these issues, but I need approval from an administrator, it seems.

just rebased the builds into a single repo using west.yaml


pay attention to the bcf and play directories.

commits are a mess and i will clean up the history, so expect the history to be rewritten.

going to update the instructions, including flashing in and out of the virtualenv. i’m out for the week, so it’ll be right after that.