boards: arm: add Seeed XIAO BLE board

[mniestroj]

The Seeed XIAO BLE is a tiny (21 mm x 17.5 mm) Nordic Semiconductor
nRF52840 ARM Cortex-M4F development board with onboard LEDs, USB port,
QSPI flash, battery charger, and range of I/O broken out into 14 pins.

[carlescufi]

Looks good, thanks!

[carlescufi]

@anangl can you please take a look?

[ghost]

Some comments, since I have this board too. I haven't tried to upstream it, since I don't know yet how to configure the onboard flash for zephyr (I'm still new here)

Shouldn't it be named seeed_xiao_ble to match the other seeed board?

It seems not to have support for the flash on qspi. is that intentional? It'd be nice to have it working if possible.

I've asked @petejohanson to take a look as well, since he also has this board, and is a bit more familiar with zephyr than I am.

EDIT: here's a link to his board defintiion from the zmk repo: https://github.com/zmkfirmware/zephyr/tree/v3.0.0%2Bzmk-fixes/boards/arm/seeeduino_xiao_ble

[mniestroj]

Shouldn't it be named seeed_xiao_ble to match the other seeed board?

Looking at Seeed WIKI boards are structured as:

• Platform / XIAO / Seeeduino XIAO
• Platform / XIAO / XIAO BLE (SENSE)

Also, board names in Zephyr are not prepended with vendor name ("seeed" in that case).

It seems not to have support for the flash on qspi. is that intentional? It'd be nice to have it working if possible.

I have configured spi3 (with spi_nor driver) peripheral instead of qspi, simply because I was not succesful with qspi, but everything is fine and tested with spi3 and spi_nor driver. Once qspi is figured out how it should be configured, then we can make a follow up patch with that improvement. I think #46285 needs to be resolved first.

[ghost]

So that is the proper configuration for the flash chip (even if not on the bus we wish it was) ? it works?

[mniestroj]

So that is the proper configuration for the flash chip (even if not on the bus we wish it was) ? it works?

It works. Tested with flash test command.

[petejohanson]

A few comments, based on the differences between this definition and the one we've been using in ZMK.

[petejohanson]

Our board definition: https://github.com/zmkfirmware/zephyr/tree/v3.0.0%2Bzmk-fixes/boards%2Farm%2Fseeeduino_xiao_ble

(I hadn't had a chance to test the flash, so definitely ignore that portion)

[jeremyherbert]

I have tested this with the seeeduino xiao ble and the littlefs sample (but you need the fix from here for it to work).

&qspi {
	status = "okay";
	pinctrl-0 = <&qspi_default>;
	pinctrl-1 = <&qspi_sleep>;
	pinctrl-names = "default", "sleep";
	p25q16h: p25q16h-uxh-ir@0 {
		compatible = "nordic,qspi-nor";
		reg = <0>;
		writeoc = "pp2o";
		readoc = "read2io";
		sck-frequency = <16000000>;
		label = "p25q16h";
		jedec-id = [85 60 15];
		size = <16777216>;
		has-dpd;
		t-enter-dpd = <20000>; 
		t-exit-dpd = <35000>;
	};
};

I don't believe quad IO will work as-is because of a similar problem with the GD flash chips where you need to enable quad IO through a register write and the driver doesn't do this (or at least the last time I checked).

Also here are my pinctrl configs:

	qspi_default: qspi_default {
		group1 {
			psels = <NRF_PSEL(QSPI_SCK, 0, 21)>,
				<NRF_PSEL(QSPI_IO0, 0, 20)>,
				<NRF_PSEL(QSPI_IO1, 0, 24)>,
				<NRF_PSEL(QSPI_IO2, 0, 22)>,
				<NRF_PSEL(QSPI_IO3, 0, 23)>,
				<NRF_PSEL(QSPI_CSN, 0, 25)>;
		};
	};

	qspi_sleep: qspi_sleep {
		group1 {
			psels = <NRF_PSEL(QSPI_SCK, 0, 21)>,
				<NRF_PSEL(QSPI_IO0, 0, 20)>,
				<NRF_PSEL(QSPI_IO1, 0, 24)>,
				<NRF_PSEL(QSPI_IO2, 0, 22)>,
				<NRF_PSEL(QSPI_IO3, 0, 23)>,
				<NRF_PSEL(QSPI_CSN, 0, 25)>;
			low-power-enable;
		};
	};

[anangl]

I don't believe quad IO will work as-is because of a similar problem with the GD flash chips where you need to enable quad IO through a register write and the driver doesn't do this (or at least the last time I checked).

@jeremyherbert Quad IO should work after adding quad-enable-requirements = "S2B1v5"; in the p25q16h node (this property is by default set to "S1B6" for "nordic,qspi-nor" compatible nodes, and such configuration is not suitable for the P25Q16H chip). Then, the driver should be able to set the QE bit properly.

[jeremyherbert]

Thank you @anangl - I wasn't aware of that.

I can confirm that the following works with the littlefs sample and the device I have:

&qspi {
	status = "okay";
	pinctrl-0 = <&qspi_default>;
	pinctrl-1 = <&qspi_sleep>;
	pinctrl-names = "default", "sleep";
	p25q16h: p25q16h-uxh-ir@0 {
		compatible = "nordic,qspi-nor";
		reg = <0>;
		quad-enable-requirements = "S2B1v5";
		writeoc = "pp4o";
		readoc = "read4io";
		sck-frequency = <16000000>;
		label = "p25q16h";
		jedec-id = [85 60 15];
		size = <16777216>;
		has-dpd;
		t-enter-dpd = <20000>; 
		t-exit-dpd = <35000>;
	};
};

[mniestroj]

Unfortunately I was still not able to run external flash with QSPI instead of SPI. Maybe I just used the wrong PRs / patches, not sure. @jeremyherbert can we leave that part to a follow-up PR with an improvement switching from SPI to QSPI? I would prefer the same with switching from mcuboot flash layout to uf2 or whatever sits there by default. Any objections?

[petejohanson]

Given the review cycle can take a while, I'm not sure I agree with the flash layout/UF2 approach suggested.

Maybe a Zephyr maintainer can weigh in, but I still think defaults that match the default bootloader should be expected as a baseline.

I'm happy to send a PR to your fork/branch with the changes, if that would help.

[mniestroj]

@petejohanson If you will provide documentation part (how to use uf2, how to flash inside index.rst changes, etc.) then I can include those changes in this PR. Factory compatible layout is just part of that and I don't want to include that in a PR without testing that it works. For now I tried to use uf2 by my own, without success, but I gave up mainly because it took much more time than I could spent on it.

There are plenty of things already tested and documented as part of this board, like USB with shell and hello world, UART (when using instead of USB) with shell and hello world, documentation about how to use that board with J-Link, west runner configuration, RGB led (with blinky samples) and many more. IMO layout is not a blocking point, because right now this PR can be used to successfully use XIAO BLE with external programming probe (which is documented that way).

Given the review cycle can take a while, I'm not sure I agree with the flash layout/UF2 approach suggested.

A lot depends on the quality of PR. There are PRs merged in the same day, quite often. If you will have PR with flash layout and documentation changes, just assign me to this PR, so I can test and approve it. What happens now is that basic board support PR is not being merged because there are some comments that "this or that could be improved". I agree with those, but I don't have time and interest in doing 100% support for that board now, and just want to unblock PR with 90% of the work already done, so that other Zephyr users/developers can take it from that point.

[jeremyherbert]

@mniestroj no worries, qspi can come later. I can create a PR once this and the nrfx fix is merged.

Out of interest, when you tested QSPI did you just get a hang at boot? That is the issue which I had.

[mniestroj]

Out of interest, when you tested QSPI did you just get a hang at boot? That is the issue which I had.

Yes, that was one of the symptoms. Another was "disabled" flash device when listed with device list. It depends on the configuration I used, but not sure now what I have changed in between.

[petejohanson]

Whatever we want to do in terms of timing is fine, I've created a PR against your branch here: mniestroj#1

But I'm just as happy to submit that to Zephyr once this is merged as well.

If you've already cleared the default bootloader, and want to test UF2 flashing, they published their bootloader hex (linked from their wiki) at https://github.com/0hotpotman0/BLE_52840_Core/blob/main/bootloader/Seeed_XIAO_nRF52840_Sense/Seeed_XIAO_nRF52840_Sense_bootloader-0.6.1_s140_7.3.0.hex

[mniestroj]

UF2 is now built by default with UF2 compatible flash layout. Updated documentation.

[ghost]

I think #46285 needs to be resolved first.

A fix was just merged. If someone has time can they give it a go?

[ghost]

is there a reason nrfjprog is excluded from board.cmake?
board_runner_args(nrfjprog "--nrf-family=NRF52")
include(${ZEPHYR_BASE}/boards/common/nrfjprog.board.cmake)

would be the line sto add if it wasn't on purpose.

[mniestroj]

is there a reason nrfjprog is excluded from board.cmake? board_runner_args(nrfjprog "--nrf-family=NRF52") include(${ZEPHYR_BASE}/boards/common/nrfjprog.board.cmake)

would be the line sto add if it wasn't on purpose.

I didn't test it previously, so wasn't sure it works. Added it now (after testing), thanks!

[mniestroj]

Rebased on main, solved conflicts and added nrfjprog support.

@petejohanson @jrobeson Could you please review and approve? You are the most interested in addition of this board, which is why I guess other Zephyr maintainers wait before approving :)

[petejohanson]

LGTM!

[ghost]

I've seen --softreset added to the nrfjprog args in other nrf boards. Without it, it doesn't seem to reset the board as I would expect. Maybe that's not the behavior as others would expect though?

[mniestroj]

--softreset is required only if you don't have hardware reset connected. I think that when I have RST (pogo pin) connected to J-Link, then XIAO BLE was reset automatically after flashing.

[ghost]

ah, you're right. the expansion board doesn't expose reset in the header for some reason. it's got TX, RX, SWDIO, SWCLK, 3v3,5v, and 2 GND, but NOT reset. The reset is exposed to a button instead.

I guess we can just leave it the way it is until there's something explicit about the expansion board. That'd be for a separate PR.

[ghost]

I see there are basic instructions for how to use this with external debuggers, but not necessarily for how to use it with mcuboot. Should there be?

I'm currently trying to use the smp svr sample, and to get it to compile (but probably not work) I've had to:

1. disable CONFIG_USB_DEVICE_STACK
2. change zephyr,uart-mcumgr = &usb_cdc_acm_uart; to point to &uart0

There are only 2 other arm boards that enable CONFIG_USB_DEVICE_STACK in their defconfig and they both fail with this sample, although for different reasons.

This board is the only arm board that provides &usb_cdc_acm_uart, so it's kind of out of the ordinary in that way.

There's one more concern, even if one were to get to build with those options. The compilation will fail due to not being able to link in the acm cdc device. It's also already too big to fit into the default mcuboot partition size of 44K by about 2500 bytes. That's probably not the total shortfall though.

EDIT: i totally forgot i switched to use the partitioning of nrf52840dk (and the other nrf52 boards that support mcuboot out of the box).

So instructions are needed for mcuboot generally.

[ghost]

got it to compile with mcuboot. turns out you need to enable CONFIG_MULTITHREADING=y for mcuboot. Although it is now too large with the normal mcuboot partition size of 44K by about 6000 bytes. when building with overlay-cdc.conf

[mniestroj]

I see there are basic instructions for how to use this with external debuggers, but not necessarily for how to use it with mcuboot. Should there be?

I don't plan to add such section for now. However that would be welcome.

[mniestroj]

With yesterday's rebase CI is passing now. So please re-review if you have time :) cc @petejohanson @jrobeson @anangl @carlescufi

[ghost]

LGTM. The expansion board stuff should be done in a separate PR.