I read KurtE's analysis of the problem but don't know how to implement fix myself. When will this PR make it to distributed code? I just received my UnoQ and have been prompted for one complete image update and also several other updates (when I open App Lab). Since I also have this SPI problem, I am assuming fix has not been integrated yet. Thanks

I read KurtE's analysis of the problem but don't know how to implement fix myself. When will this PR make it to distributed code? I just received my UnoQ and have been prompted for one complete image update and also several other updates (when I open App Lab). Since I also have this SPI problem, I am assuming fix has not been integrated yet. Thanks

Until, this is pulled in, the only way to use it, is to rebuild the zephyr "bootloader".

I don't know if you are running using Windows, or Ubuntu or the like:
But you need to setup to be able to build ArduinoCore-zephyr:
If you look at the Readme in this project:https://github.com/arduino/ArduinoCore-zephyr
At the Setup a Zephyr build environment.

My setup is a bit more complicated as I mainly work on Windows, and there is not native build support for the ArduinoCore-zephyr under windows. There is a section that shows how a few of us do it, where we do the build under WSL (Windows Subsystem for Linux), I copy the stuff out to windows file system, and then I you can update the logical Bootloader, using the burn bootloader command... Again more details in the ReadMe.

But keeping fingers crossed hopefully they will pull this one in soon and do another release.

I read KurtE's analysis of the problem but don't know how to implement fix myself. When will this PR make it to distributed code? I just received my UnoQ and have been prompted for one complete image update and also several other updates (when I open App Lab). Since I also have this SPI problem, I am assuming fix has not been integrated yet. Thanks

@pillo79 and all - I am guessing that you are all up to your eyebrows with getting things working and the like, which
I really appreciate.

@bmillier - My first response is the right response... However if it were me, I might be tempted to try some simple hack and see
if it works.

That is if you start your sketch, you might try manually updating the MOSI pin to be in SPI mode. Not sure if it would
work, but I would try something like:

void setup() {    GPIOB.AFR[1] = (GPIOB.AFR[1] & 0x0FFFFFFF) | 0x50000000;...

Typed on the fly so could have issues. Look at the test sketch I showed in the forum thread linked to in first post

@KurtE.Many thanks for your prompt attention to this bug. The line of code you quoted is something I understand- the Device Tree and re-building the bootloader for the ST MCU- not so much! While the code looked OK to me, it wouldn't compile and I had to change it to:
GPIOB->AFR[1] = (GPIOB->AFR[1] & 0x0FFFFFFF) | 0x50000000;
With that code in setup() the MOSI line is now active on my scope!!
The ST7789 TFT display is now working.

While on the SPI topic, I note that the pinout diagram shows the SPI port on D10-D13 as using SPI2 and the 6-pin header (which used to be the SPI port for programming on the old M328 Uno boards) as also using SPI2. While this was true on the M328, I don't think it's correct here as there is no continuity between the D10-13 pins and the 6-pin header. I have to look into this some more.
A few years back, when I was busy doing some Teensy projects, I rememember that you were a regular poster and very helpful on numerous topics. ( I think it was the ILI9341 TFT library that you had written ). Glad to see you on this forum. Cheers

While on the SPI topic, I note that the pinout diagram shows the SPI port on D10-D13 as using SPI2 and the 6-pin header (which used to be the SPI port for programming on the old M328 Uno boards) as also using SPI2. While this was true on the M328, I don't think it's correct here as there is no continuity between the D10-13 pins and the 6-pin header. I have to look into this some more.

Sorry about typo, looks like my fingers were off by 1 key when I typed the ;... Edited above.

As for the other connector and spi2 (SPI) object: It is sort of like the Teensy, where there are logically multiple different
hardware pins that can be used for different things like MOSI, MISO, SCK.

Here is part of the Excel document I created that shows the MUX table for the different pins. This was extracted from the
processors PDF file:

In this you see that for AF5, Arduino pins (11-13) have SPI2_ functions.

But if you look a little farther down you will see on pins 22-24 that these pins also can be SPI2 pins.

Which also matches their defines for SPI2 in zephyr (git\zephyr\boards\unoq\arduino\arduino_uno_q-common.dtsi)

&spi2 {status = "okay";pinctrl-0 = <&spi2_sck_pb13     &spi2_miso_pb14 &spi2_mosi_pb15 &spi2_nss_pb9>;pinctrl-1 = <&spi2_sck_pd1     &spi2_miso_pc2 &spi2_mosi_pc3>;pinctrl-names = "default", "sleep"; /* TODO: sleep is ICSP mux */};

But I am not sure how to change the state to logical "Sleep"
I am guessing it will be something like:

ret = pinctrl_apply_state(PINCTRL_DT_DEV_CONFIG_GET(SPI_NODE),  PINCTRL_STATE_SLEEP);

Not sure which object or if other things in the state need to change...
I might try hacking it the same way I mentioned for getting pins 11-13 to work.

@KurtE: It wasn't the missing ; - I corrected that when pasting it into code. It was that I had to change
GPIOB.AFR[1] to GPIOB->AFR[1] in 2 spots in order to compile it.
I see from your spreadsheet that indeed, both the D10-D13 pins and the ones on the 6-pin JSPI are alternatives for hardware spi2 port- so only one or the other can be used. But, the STM32U585 has 3 discrete SPI ports, one of which is dedicated to the Linux Bridge. So, I thought that if I used SPI1 instead of SPI in my test code, that it might operate on the D2-D5 pins which show up for spi1 in your spreadsheet. However, this doesn't produce the SCK signal on D2, so that won't work.
I haven't yet been able to find the file that you point to (on my local machine or on the web in github):
git\zephyr\boards\unoq\arduino\arduino_uno_q-common.dtsi

I did find the hex and elf files for the bootloader while searching.
I have no prior knowledge of Zephyr so this is all new to me.
I don't have a need for 2 discrete SPI ports- I'm just working on an article for Circuit Cellar on this new board, and am checking various things out. I have used 2 SPI ports with both Teensy4.x and ESP32.
I think I saw elsewhere that you found the ST7789 TFT library was slow on the UnoQ. I measure the SCK freq at only 5.4 MHz, so that's part of it. I am probably not using the same ST7789 lib as you are but I observe 1-2 seconds to just clear the display on a tiny OLED display that I have. The same display works much quicker on the Arduino Nano Matter boards that I have used it with.
Cheers