MBED->Zephyr status? Beta by end of year?

Community General Discussion
1

I remember earlier this year reading about the EOL for MBED and that Arduino was going to transition to Zeyphyr. I believe I read somewhere that Arduino was planning on having something like a beta by the end of the year? Don't remember if it was specific on which of the MBED based Arduino boards or all of them.

Is this still the plan?

I believe it was either somewhere in the thread:
Mbed end of life - Hardware - Arduino Forum Or some of the links from that thread.

I know that we are early, but it can be fun to try to contribute where appropriate. We have been involved with the early phases of other boards, such as different Teensy boards.

Background
A couple of us including @Merlin513 and myself started playing with running the GIGA on Zephyr. Some of the details are in the forum thread: I2C, Serial, SPI experiments with Zephyr on Giga - Hardware / GIGA R1 - Arduino Forum

We started off using the instructions in the Readme file for the github project:
arduino/ArduinoCore-zephyr: Arduino Core based on Zephyr+llext

We started, by using the board manager to install the zephyr board package. The URL mentioned in the above readme: https://downloads.arduino.cc/packages/package_zephyr_index.json

We quickly learned the last release 0.1.3 was over a year old, and very primitive with only a few IO pins defined and likewise for other objects like Uarts, SPI, I2C...

We decided to go to the next step and setup the environment, and install the current stuff from github plus zephyr plus... And with the help of @ptillisch was able to build the more current stuff for the GIGA :smiley: I have it building both on Ubuntu 24.04 as well as on Windows 11 using WSL with Ubuntu 24.04

Some of it is sort of fun! For example: it is great that the SerialX objects writes are buffered. Note I created a PR against this project that fixes or implemented some of the methods. Things like: availableForWrite, flush(), read() returns -1 when empty...

Over the last couple of days, we have been trying to get SPI to work. We have a few things working, but in most cases, the board ends up logically dead. That is the board no longer shows up in the IDE... And in some cases, for no real obvious reason. Double click boot still works.

We are currently trying to get SDFat to work. Currently trying SDFat-beta.
I have sketch simple_sd, which is up on my github project: KurtE/Arduino_GIGA-stuff: This is my GIGA test sketches and other like stuff for Arduino GIGA boards

Where I am trying to figure out why the board will not init:

//    digitalWrite(DEBUG_PIN, HIGH);  // make sure display does not interfere
    if (!sd.cardBegin(SD_CONFIG)) {
//        digitalWrite(DEBUG_PIN, LOW);  // make sure display does not interfere
        Serial.print("Card Begin failed Error: ");
        Serial.println(sd.sdErrorCode());
        while (1) {}
    }
    //digitalWrite(DEBUG_PIN, LOW);  // make sure display does not interfere

In this section of code, I do receive the Card Begin Failed message.
However if I uncomment the line digitalWrite(DEBUG_PIN, HIGH);
The board will crash, and I receive no Serial output at all from the sketch...

Questions:

  1. is there a better place/way to ask questions, and discuss issues. Options might include punt, here, github, email, or ???

  2. Best set of sources to use now? Currently we are using the Arduino branch of the ArduinoCore-Zephyr project. The bootstrap shell, does a git clone of the zephyr github library from //github.com/facchinm/zephyr, using a detached head of minifest-rev
    I have noticed that @facchinm has at least two newer branches.

  3. When do you have to flash the GIGA? (new bootloader). Once with support for Zephyr? Or every time the device tree changes? every time the overlay changes?

  4. Making changes to the device tree. For example, usart2 was not defined. Should you always add the object to the dts file? (arduino_giga_r1_stm32747xx_m7.dts) or is ok and
    sufficient to simply add it to the overlay. Like in arduino_giga_r1_m7.overlay adding it as

&usart2 {
	status = "okay";
	pinctrl-0 = <&usart2_tx_pd5 &usart2_rx_pd6>;
	pinctrl-names = "default";
	current-speed = <115200>;
};

Do I always need to run the build.sh on it if I change either of the two files.

  1. Debugging: does it work with the IDE? Or is there a different one, I tried with a
    cmis-DAP adapter, but it did not want to start up.

  2. What does mode: Standard/Debug work? If I set it to debug I see a few things, printed
    but not sure if there is supposed to be a command input or ...

  3. M4?? - Probably something for later

  4. Crashes - As I mentioned, we are getting a lot of board stops (assuming a crash). Suggested way to debug? Sometimes just referencing an object in the sketch will cause it to crash as sketch startup. Is there some default crash monitor or the like where you can maybe find out where the code was?

  5. What version of compiler and c++? I believe GCC is 12.2.0, did not fined where the version of C++ defined? Guessing c++17?

There are probably a lot more questions we could ask, but hopefully a good enough start.

Thanks
Kurt

2

GitHub should only be used for formal bug reports, feature requests, and pull requests.

For unstructured discussion, the forum is fine of course. The alternative would be the Arduino Developers Mailing List:

3

Understood, sometimes things are on the border line, like SPI sketches hang/crash the board...

Might try that, not sure if I am still a member or not... I know it has been awfully quiet. I think only one response this year.

Quick updates on some of my questions:

  1. Debugger - I got the CMIS-DAP to at least start up.
    Edited programmers.txt: added some lines that were in the main GIGA boards version, like:
    cmsis-dap.programmer.transport_script={runtime.platform.path}/debugger/select_swd.cfg

Also copied some files out of the MBED Giga build, in particular the debugger and swd directories.

My Jlink EDU one did not want to start up... Some message like not supported,
but my CMIS-DAP one did start up. Will play more.

  1. Still not sure yet on what the debug setting is, other than it so far shows some
    initial debug messages: But I did find that Serial1 appears to setup to output Debug
    information (regardless of this setting) at 11500. I connected it to a Teensy, programmed as USB to serial adapter:

And on the case with now crash but sd does not start I see:

e[1;32muart:~$ e[me[8De[J[00:00:04.177,000] e[1;31m<err> spi_ll_stm32: Unsupported frequency 400000Hz, max 60000000Hz, min 468750Hze[0m
e[1;32muart:~$ e[me[8De[J[00:00:04.189,000] e[1;31m<err> spi_ll_stm32: Unsupported frequency 400000Hz, max 60000000Hz, min 468750Hze[0m
e[1;32muart:~$ e[me[8De[J[00:00:04.201,000] e[1;31m<err> spi_ll_stm32: Unsupported frequency 400000Hz, max 60000000Hz, min 468750Hze[0m
e[1;32muart:~$ e[me[8De[J[00:00:04.213,000] e[1;31m<err> spi_ll_stm32: Unsupported frequency 400000Hz, max 60000000Hz, min 468750Hze[0m
e[1;32muart:~$ e[me[8De[J[00:00:04.224,000] e[1;31m<err> spi_ll_stm32: Unsupported frequency 400000Hz, max 60000000Hz, min 468750Hze[0m
e[1;32muart:~$ e[me[8De[J[00:00:04.236,000] e[1;31m<err> spi_ll_stm32: Unsupported frequency 400000Hz, max 60000000Hz, min 468750Hze[0m
e[1;32muart:~$ e[m

Looks like it does not like the SPI speed...
I believe it is output from the file zephyr\spi\spi_II_stm32.c

	if (br > ARRAY_SIZE(scaler)) {
		LOG_ERR("Unsupported frequency %uHz, max %uHz, min %uHz",
			    config->frequency,
			    clock >> 1,
			    clock >> ARRAY_SIZE(scaler));
		return -EINVAL;
	}

Now to figure out where the SPI Speed is set.

4

By all means feel free to submit formal bug reports if you find reproducible defects in the code.

They would never kick out anyone who is legit. So you are definitely still a member unless you explicitly left the group. The group membership is through your Google account. You can see the groups you are a member of by signing into your Google account and then going to this page:

Yes, it is definitely questionable whether it makes sense to use the mailing list. My preference would be that we consolidate all discussions to the forum instead of fragmenting them across multiple platforms. However, I will say that those who do reply in the mailing list conversations are often heavy hitters who probably would not have noticed the post if it had been made on Arduino Forum instead.

Those things are so trusty. Mine is certainly a treasured tool. Hopefully Alex Taradov will start selling them on Tindie again in 2025.

5

If you look in SpiDriver.h you see:

/** SPISettings for SCK frequency in MHz. */
#define SD_SCK_MHZ(maxMhz) (1000000UL * (maxMhz))
// SPI divisor constants - obsolete.
/** Set SCK to max rate. */
#define SPI_FULL_SPEED SD_SCK_MHZ(50)
/** Set SCK rate to 16 MHz for Due */
#define SPI_DIV3_SPEED SD_SCK_MHZ(16)
/** Set SCK rate to 4 MHz for AVR. */
#define SPI_HALF_SPEED SD_SCK_MHZ(4)
/** Set SCK rate to 8 MHz for Due */
#define SPI_DIV6_SPEED SD_SCK_MHZ(8)
/** Set SCK rate to 2 MHz for AVR. */
#define SPI_QUARTER_SPEED SD_SCK_MHZ(2)
/** Set SCK rate to 1 MHz for AVR. */
#define SPI_EIGHTH_SPEED SD_SCK_MHZ(1)
/** Set SCK rate to 500 kHz for AVR. */
#define SPI_SIXTEENTH_SPEED SD_SCK_HZ(500000)

and looks like you can set it up in sdconfig when you pass it to begin:

#define SD_CONFIG SdSpiConfig(SD_CS_PIN, SHARED_SPI, SPI_CLOCK)
6

Thanks,
Looks like I joined it in 2012... Or was that when the 2nd incarnation of where the list resided.

I agree. But we @Merlin513 sent one, which I responded to. As you mentioned there are/were a lot of heavy hitters.

Yep - looks like still two options, until (or if) he does. He has all of the design files up there on the github project, including zip files with the Gerbers. So could always send them off to OSHPark, or PCBWay and solder up a few.

Or he also mentions that you can also use an RPI Pico as well. He has prebuilt firmware for that and shows which pins to use. So could use jumper wires and/or we could make simple board you mount pico and have connector....

7

In order to make all relevant information available to any who are interested in this subject, I'll share a link to the related discussion in the Arduino Developers Mailing List:

Yeah! Not only is the debug probe a very useful tool, it is also open source hardware :+1: .

8

A couple of years ago,I tried getting my Arduino Nano to read an SD Card via simple physical card reader and [some library]; it wouldn't work.
I then added lots of physical reader logging to check various lines etc to debug the thing.
And then reading the SD card would work!
IOW I reckon that there were timing issues with reading the card, and the logging slowed down the Arduino transmission speeds so that the card could be read successfully.
An avenue to consider ...
HTH

9

Thanks, I have been there, where adding more debug stuff can screw up the timings and the like. Will double check.

Currently I think, there are probably some more fundamental issues. I probably need to go back and ring out more of the underlying SPI issues and see if that gets us any clues that help with SD.

Things like, the SPI object does not initialize it's state information fully with the call to begin. Things like the transfer speed, size, MSB/LSB, are not set at all until the client code
calls beginTransaction()...

Thanks again.

10

Well think @KurtE is right, it may be more complicated. Yesterday, using a sketch I did form giga mbed ( Configuring SPI Speed For Use In SD Library On Arduino GHiga - Hardware / GIGA R1 - Arduino Forum ) where I define my own driver using transactions - note didn't see anything in the zephyr core for a typical define SPI_HAS_TRANSACTIONS.

Got it working yesterday and was able to read the SD Card but the CS pin was hard coded to 10. So went back in to try to fix that and then it hung again. So I reversed the changes and then the Giga zephyr is hanging again using SDFat. Something is still off - could be timing or something else.

Right now though all is silent Arduino Team so really just shooting in the dark.

11

Quick update: on SPI with my ILI9341 stuff...

I stripped down my ILI9341 library that I have been playing with on the mbed GIGA stuff. In particular I removed the usage of SPI registers, DMA, my digitalWriteFast stuff, ... And simply using SPI.transfer() type code.

It kept faulting at startup. So I built it for MBED and the linker failed with the missing a symbol... So I fixed it and it ran on the GIGA. I then rebuilt it and it finally ran on the Zephyr board type. This is a version of the Adafruit Graphic test sketch. The DeadBeef message kept rotating around on the screen, the first time, for some reason after a bit, the GIGA went into boot loader mode. But after reset it has run for a while...

Now to play with it some more... See how possible it is to get some of the other things working.

12

OOps spoke too soon.

Turns out, that didn't fix it.
When I ran the MBED version I believe it wiped out the bootloader of the zephyr stuff,
and then the download code area gives you the impression that it downloaded the sketch... But it appears that the bootloader silently just punts the data and runs the previous sketch.

Think I might put all of this on hold for now...

13

Let's move the SDFat conversation here :wink:

14

Quick update on some of the Zephyr on GIGA experiments. We have been making some progress!

Github appears to be the best place for specific conversations, like SPI/SD work:
SdFat failing using SPI or SPI1 (after updating overlay). · Issue #4 · arduino/ArduinoCore-zephyr

We are still using the same sources. Note: changes have been pulled in so you may need to sync up.

You need to reflash the bootloader anytime the device tree or other settings change. Or anytime you loaded something other than zephyr, like an MBED sketch.
When in doubt flash it. Note: you need to have a programmer defined, but not necessary to connect one up.

Still not sure what things should go into main device tree file and which things should go into overlay.

There is lots of details about device trees up at:
Devicetree — Zephyr Project Documentation

With the current setup, you really need to setup an external monitor (not sure of their name for it). But you need to connect Serial1 (pins 0, 1), to your PC, through some form of USB to Serial Adapter. On one I am using an FTDI cable (3.3v) and on another I am using a Teensy Micromod, with USB to Serial software). You need to have your connection setup to run at baud rate of 115200. I am currently using PuTTy on my PC (both Windows and Ubuntu).

With many of the "crashes" I was seeing, there was an issue with loading the sketch.
The first issue was, something in the code was too large to load.

When it started up: the monitor window will show you a prompt like: uart:~$ sketch
At that point type in sketch
And you might see something that looked like:

uart:~$ sketch
[00:00:07.059,000] <err> llext: Failed to copy regions, ret -12
Failed to load sketch, rc -12
uart:~$

At this point you want to reconfigure some of the settings, that are in the boards configuration file, which is located at:
/loader/boards/arduino_giga_r1_m7.conf
And currently have added at the end of it:

#CONFIG_LLEXT_STORAGE_WRITABLE=n
#CONFIG_HEAP_MEM_POOL_SIZE=2048
CONFIG_SHELL_STACK_SIZE=32768
CONFIG_MAIN_STACK_SIZE=32768
CONFIG_LLEXT_HEAP_SIZE=128

After saving, you need to run the ./extra/build.sh again, plus reflash the bootloader
plus reload the sketch.

It might again come up with the same prompt as above, when in doubt and nothing
else happens, try typing: sketch

Then ran into issues where your sketch has missing stuff, from the link phase. Something like:

[00:00:03.332,000] <err> llext: Undefined symbol with no entry in symbol table isalpha, offset 13200, link 0 [00:00:03.343,000] <err> llext: 
Failed to link, ret -61

Depending on where the missing symbol(s) are located, you may need to update
either your sketch or base code...
You may need to do the full build.sh... or you might simply need to do an upload of the updated sketch.

hopefully after a few iterations the sketch loads and maybe you see something like:

uart:~$ sketch
[00:00:07.439,000] <inf> usb_cdc_acm: Device suspended
[00:00:07.667,000] <inf> usb_cdc_acm: Device configured

And your sketch is running.

Mode: Standard/Debug - Is a setting that if in Debug mode, the program will be started up to wait in the monitor for you to tell it to load the sketch:
arduino/ArduinoCore-zephyr: Arduino Core based on Zephyr+llext

And as I mentioned, have been making some progress. Have one of my sketches
modified over to run on the GIGA/Zephyr that reads images from SD and shows them on an ILI9341. Both of TFT and SD are using SPI on SPI1:

image
image977×743 103 KB

Lots more stuff to figure out, but it is a start.

15

Really nice summary @KurtE of whats been going on so far.

16

@facchinm @ptillisch @Merlin513, all - Update to the previous post here, plus more generic questions?

Hard to know what forum this should be under, as it applies to multiple hardware devices, but posted here as well, been doing testing using GIGA... Might try Portenta H7 soon.

First a couple of generic questions and observations.

The December blog entry that is/was shown on the front page of the arduino.cc website, mentions the first beta for Zephyr :smiley:
Introducing Arduino cores with ZephyrOS (beta): take your embedded development to the next level | Arduino Blog

To me it feels more like an Alpha, but that is probably just semantics and maybe different expectations.

I am curious on is there some form of Roadmap/Document on where we are at and how you expect the system to work when it is officially released? And do you have a general timeframe?

Is there someplace to look to know the status of different sub-systems? Like Serial (UARTS) (working, except...), USB Serial, USB HID, SPI, Wire, Analog, PWM, Timers, CAN... M4... ?

Currently: For almost every sketch I have tried on the current sources, I have had to edit the arduino_giga_r1_m7.conf file and then rebuild the firmware, then reflash the firmware and finally build the actual sketch. Note: there are no instructions on how to build on firmware on Windows. Building on WSL does work, however there are no instructions for doing such. Also unclear of best approach. do the git clone... into WSL file system? A lot faster builds, but, you then need to copy into windows space to build your sketch. (Do you need to copy the whole ArduinoCore-zephyr? Or just some pieces. if pieces maybe some script to do so would help... Currently have it git done into Windows space: /mnt/d/github/ArduinoCore-zephyr, which I can then build sketches directly from, but the build.sh is real slow>

Often times have to have Serial1 connected up, to debug monitor, and deal with things like missing symbols, or don't fit...

How do you expect it to work in the future?
Things like:
a) Do you expect to provide a native windows implementation of the full build process?

b) Will sketches/libraries be able to provide their own overlays or the like to control what the Device Tree?

c) sort of follow on to b) Do you expect that the Firmware will contain all of the zephyr core, plus all of the objects (Serial, Wire, SPI, Flexio...) even if your sketch only needs a subset of the objects? For example if your board has 3 UARTS and the Serial code objects have 512 bytes of software queue for RX and likewise for TX. Is the 3K of memory space reserved for every sketch, even those who do not use the Serial objects?

Timeframe/Priorities
This is a two way question:

Arduino: How high of priority is Zephyr? Something you hope to have in a production state by the end of the month or year or something that @facchinm and maybe others work on in the background as time permits.

Volunteers: What areas would you like for us to concentrate our time on?

For myself I have spent most of my time on subsystems, that I have done a lot of work on for other boards, like Serial, SPI...

I have tried to get some of PWM working, but I keep hitting a brick wall...

Where do you prefer feedback? I am guessing issue for most specific things. But I personally wish there was also some Forum or thread, which helps some of us keep track of what has been done, what has not been done, what worked, what did not.
Example thread, when Paul of PJRC started a beta on the last board that was released, he created a thread:
MicroMod Beta Testing | Teensy Forum

It was not perfect, but at least there was one place to go to, and do a search to see if someone has tried some subsystem/library and if so, did it work or what issues they ran into.

Hopefully, this post is understandable.

Thanks
Kurt

17

It is a bad idea to use a single megathread. If Paul wants to run the PJRC forum that way, fine, but we don't do that here. Just create a separate forum topic for each distinct subject matter you wish to discuss.

But as for keeping track of what has and has not been done, GitHub issues are used for that purpose.

The forum and GitHub issues can be used in tandem, with the issue serving as the formal bug report/feature request, and tracking the progress on that task, and the forum serving as a place for related discussion. Just make sure to add a link from each to the other. This way, if an interested party wants to read or participate in discussion on an issue, they can find the relevant forum topic, and if an interested party wants to check the progress on a bug or feature discussed on a forum topic, they can find the relevant issue on GitHub.

18

Thanks @ptillisch, I hear you about there are a lot of downsides to a mega thread. It for sure is not a perfect solution!

Not sure if such a thing exists :laughing: But we can try.

I probably should have mentioned I have participated in a few other betas where they created a forum specific to the beta. Sometimes that mark the forum public and other times private...

Will continue on the way we have. The difficulty comes in, as sometimes it is hard to know which forum to create a thread under. For example, after I synced up to @facchinm merge into the arduino branch, I am trying out some of the sketches that we have been playing with.

Currently trying out the graphics test example sketch for my port of the ILI9341 library to the zephyr SPI code. On the Arduino GIGA, the code fails to load....

uart:~$
uart:~$ sketch
[00:00:12.694,000] <err> llext: Failed to copy regions, ret -12
Failed to load sketch, rc -12
uart:~$

In this case I know that there is not enough memory setup to run the sketch and I will maybe raise this again as an issue and/or PR to settings that work for most of our sketches.

But if I wanted to mention it the forum, would it go in this go here? Giga forum, Displays forum? especially if I repeat the test and try it on my Portenta or soon to have Nano 33 BLE Sense board, should I create/duplicate the thread there?

Thanks again for all of your support!

19

The problem is then we either end up with pointless categories cluttering up the forum structure after the beta phase ends, or else later a maintainer has to do a ton of work to move all those topics to appropriate permanent categories in order to get rid of the temporary category. We don't want either of those things, so we are strongly resisting the creation of additional forum categories unless there is a significant long term need for it.

FYI, the term we use here is "category":

https://meta.discourse.org/t/understanding-discourse-for-new-users/96331#p-468221-basic-terms-used-by-discourse-2

The term "forum" is only used when referring to the Arduino Forum as a whole.

A private category could be necessary in the case of a pre-launch product that had not been publicly announced. But in this case where the project development is completely open, it would only do harm by unnecessarily withholding potentially valuable information from the community.

Indeed! This is one of the reasons why we are trying hard to keep the category structure clean.

Please just do your best to pick the appropriate category. For beta testing feedback, I suggest the Community > Suggestions for the Arduino Project. For questions/discussion about using or developing the core, I suggest Projects > Programming. But we don't get uptight about category selection unless someone picks a completely inappropriate category, which of course you wouldn't do (but is a constant problem with the new forum members).

If your intent is to request or offer support regarding the problem, then Community > General Discussion is a reasonable choice. We also often use Development Tools > IDE 2.x for topics about compilation tooling or boards platform configuration, even though they aren't directly relevant to the Arduino IDE application.

If your intent is to report the issue to the platform developers (or supplement a formal report in the issue tracker), then the Community > Suggestions for the Arduino Project category would be the best place.

Not if it will be a duplicate. It could make sense if there were such significant differences between the boards as to make the discussion related to one board not relevant to the other.