Is it possible to debug an App-lab UNO Q crash?

[KurtE]

Was going to ask this as an issue, but...

Suppose your App Lab sketch crashes... Currently not hard to imagine as most of mine crash on the current release. Currently the only way to know you had a crash is if you by chance have a USB To Serial adapter hooked up to the UNO Q on pins 0 and 1 and have a Serial app running at 115200.

And for example if I run my modified version of the Weather App that shows the temperature and how much rainfall. On 0.53 it crashes:

*** Booting Zephyr OS build v4.2.0-38-g994b835f5936 ***
Invalid sketch header
[00:00:00.220,000] <err> os: ***** BUS FAULT *****
[00:00:00.225,000] <err> os:   Precise data bus error
[00:00:00.231,000] <err> os:   BFAR Address: 0x4b6e21fc
[00:00:00.237,000] <err> os: r0/a1:  0x00011b24  r1/a2:  0x4b6e21f0  r2/a3:  0x00000003
[00:00:00.245,000] <err> os: r3/a4:  0x646f6874 r12/ip:  0x00000007 r14/lr:  0x080130dd
[00:00:00.254,000] <err> os:  xpsr:  0x29002c00
[00:00:00.259,000] <err> os: s[ 0]:  0x0000200c  s[ 1]:  0x200326d8  s[ 2]:  0x00000001  s[ 3]:  0x20029420
[00:00:00.270,000] <err> os: s[ 4]:  0x00000002  s[ 5]:  0x08013155  s[ 6]:  0x00000002  s[ 7]:  0x200326d8
[00:00:00.280,000] <err> os: s[ 8]:  0x20008bd8  s[ 9]:  0x20029420  s[10]:  0x00000001  s[11]:  0x20029418
[00:00:00.291,000] <err> os: s[12]:  0xffffffff  s[13]:  0x08013477  s[14]:  0x00000000  s[15]:  0x00000001
[00:00:00.301,000] <err> os: fpscr:  0x20008bd8
[00:00:00.306,000] <err> os: Faulting instruction address (r15/pc): 0x08013012
[00:00:00.314,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.322,000] <err> os: Current thread: 0x20000558 (main)
[00:00:00.328,000] <err> os: Halting system

How can I find out what these addresses correspond to?
Currently the map file is more or less useless, as described in the issue
How to decode a fault address? · Issue #52 · arduino/ArduinoCore-zephyr

It was mentioned within that issue, that within the Arduino IDE, if you build
with link set to Static, then you can get the addresses...

Is there any such way with builds within applab to do static Builds?
Or within arduino-app-cli?

If so how... And if such options are available is it also possible to set other options, such as see all build warnings?

Also side question. The last Pulled in change in ArduinoCore-zephyr marked for a 0.53.1 release(or marker), mentioned that it fixes random issues for apps > 64k and wondered if 128k was sufficient?
What does this mean? Sufficient for what?

Thanks

[ptillisch]

Hi @KurtE.

@KurtE

Is there any such way with builds within applab to do static Builds?
Or within arduino-app-cli?

Background

The "Arduino UNO Q" board definition in the "Arduino UNO Q Board" platform (machine identifier arduino:zephyr:unoq) is configured to provide a "custom board options" menu named "Link mode" (machine identifier link_mode), which has two options:

• "Dynamic" (machine identifier dynamic)
• "Static" (machine identifier static)

When using Arduino IDE, we simply select the option we want from the Tools > Link mode menu.

When using Arduino CLI, we specify custom board option selections via the FQBN (the machine identifier of the board), either via the --fqbn command line flag, or via the fqbn key of the build profile. For example, if we want the "Static" option, we would use the FQBN arduino:zephyr:unoq:link_mode=static.

Unfortunately, no mechanism is provided for configuring the FQBN used by Arduino App Lab and Arduino App CLI. Instead, the FQBN is hardcoded:

internal/orchestrator/orchestrator.go

internal/orchestrator/orchestrator.go

Since a link_mode option is not specified by those FQBNs, the default option is used. The default option is determined by the order of the options in the board definition:

boards.txt

So we can see that the default option is "Dynamic".

Recommended Approach

The sole effect of selecting the "Static" custom board option is the definition of two platform properties:

• build.link_mode=static
• upload.extension=bin-zsk.bin

These properties are referenced by the command templates ("patterns") in the `platform.txt file.

We can accomplish the same thing by directly making the same property definitions. This can be done via the platform.local.txt file. Property definitions in this file override any definitions in the platform.txt file.

You can accomplish this by running the following command from the shell terminal:

echo "
build.link_mode=static
upload.extension=bin-zsk.bin
" > ~/.arduino15/packages/arduino/hardware/zephyr/0.53.0/platform.local.txt

This applies the modification to the release installation of version 0.53.0 of the platform. If you are using a different version of the platform, or if you are using a manual installation, adjust the path in the command accordingly.

When you want to switch back to using the "Dynamic" option, just delete the platform.local.txt file that was created by that command:

rm ~/.arduino15/packages/arduino/hardware/zephyr/0.53.0/platform.local.txt

---

Note that the modification will be lost each time you update to a new release version of the arduino:zephyr platform. So remember to run the command after doing so if you wish to continue to use the "Static" option.

If you are applying the modification to a manual installation of the Git repository, you can add an entry to the repository's .git/info/exclude file in order to cause Git to disregard the added platform.local.txt file:

echo "platform.local.txt" >> ~/Arduino/hardware/arduino/zephyr/.git/info/exclude

Alternative Approach

The fact that Arduino App CLI uses the implicit default option for the "Link mode" menu instead of explicitly specifying the option via the hardcoded FQBN provides us with a vector though which we can change the option. This would be utilized by editing the boards.txt file to reverse the order of the option definitions, from this:

boards.txt

to this:

unoq.menu.link_mode.static=Static
unoq.menu.link_mode.static.build.link_mode=static
unoq.menu.link_mode.static.upload.extension=bin-zsk.bin
unoq.menu.link_mode.dynamic=Dynamic

After this change, the default option becomes "Static".

The reason I do not consider this to be the recommended approach is because it requires the modification of boards.txt.

The modification needs to be performed after each update of the platform, and each time you want to change the "link mode" behavior of Arduino App CLI. That is simple to accomplish when the modification is contained within the dedicated user file platform.local.txt, which can simply be added to and removed from the platform installation folder as needed. Conversely, it is less convenient to modify boards.txt each time, as you will likely be performing a manual edit on the file. Editing boards.txt also opens up the possibility of introducing unintentional changes to the other content in the file.

[Merlin513]

@ptillisch

The modification needs to be performed after each update of the platform,

@ptillisch - do you know if there are plans to upgrading AppLab to allow user to select Link Mode been finding that there are instances where its better to run using Static Mode rather than Dynamic Mode?

[ptillisch]

I'm not aware of any such plans. If you would find it useful, I recommend submitting a feature request to the Arduino App CLI issue tracker:

arduino/arduino-app-cli

The capability would need to be implemented in the Arduino App CLI codebase before it could be added to Arduino App Lab, so this is needed even if your end goal is to be able to configure it in Arduino App Lab. And, if you only need to perform the configuration occasionally (as with @KurtE's use case of debugging a crash), then you might find that having the capability in Arduino App CLI alone will already be a significant improvement over the hacky approach I described in my previous reply.

[Merlin513]

@ptillisch

If you would find it useful, I recommend submitting a feature request to the Arduino App CLI issue tracker:

@ptillisch - @KurtE

I submitted a feature request: Add Link Mode Option · Issue #233 · arduino/arduino-app-cli

Feel free to add to it.

[KurtE]

Thanks @ptillisch - I have tried it on the Weather 2 sketch or App....

I used your echo on the current release.

Still crashes:

*** Booting Zephyr OS build v4.2.0-38-g994b835f5936 ***
Invalid sketch header
0j[00:00:00.209,000] <err> os: ***** BUS FAULT *****
[00:00:00.215,000] <err> os:   Precise data bus error
[00:00:00.220,000] <err> os:   BFAR Address: 0x20
[00:00:00.226,000] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000002  r2/a3:  0x000007fc
[00:00:00.234,000] <err> os: r3/a4:  0x080f8959 r12/ip:  0x08007821 r14/lr:  0x2003276d
[00:00:00.243,000] <err> os:  xpsr:  0x49000000
[00:00:00.248,000] <err> os: s[ 0]:  0x20032749  s[ 1]:  0x00000002  s[ 2]:  0x0000a7bc  s[ 3]:  0x08005539
[00:00:00.259,000] <err> os: s[ 4]:  0x9adef20f  s[ 5]:  0x0801877c  s[ 6]:  0x08019a78  s[ 7]:  0x32a7886f
[00:00:00.269,000] <err> os: s[ 8]:  0x08017fb0  s[ 9]:  0x00004d0d  s[10]:  0xcf71f7dd  s[11]:  0x00000000
[00:00:00.280,000] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:00.290,000] <err> os: fpscr:  0x00000000
[00:00:00.295,000] <err> os: Faulting instruction address (r15/pc): 0x080f8a56
[00:00:00.303,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.311,000] <err> os: Current thread: 0x20000558 (main)
[00:00:00.317,000] <err> os: Halting system

But now when I look at the map file: ArduinoApps/weather2/.cache/sketch/sketch.ino.map
And search through it I see:

.text.memmove  0x00000000080f8972       0x34 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(memmove.c.o)
                0x00000000080f8972                memmove
                0x00000000080f8972                __aeabi_memmove8
                0x00000000080f8972                __aeabi_memmove
                0x00000000080f8972                __aeabi_memmove4
 .text.memset   0x00000000080f89a6       0x10 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(memset.c.o)
                0x00000000080f89a6                memset
 .text.strnlen  0x00000000080f89b6       0x18 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(libc_string_strnlen.c.o)
                0x00000000080f89b6                strnlen
 .text.__dtox_engine
                0x00000000080f89ce      0x182 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(libc_tinystdio_dtox_engine.c.o)
                0x00000000080f89ce                __dtox_engine
 .text.__file_str_put
                0x00000000080f8b50       0x10 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(libc_tinystdio_filestrput.c.o)
                0x00000000080f8b50                __file_str_put
 *(

So somewhere in __dtox_engine function...
Obviously would be nice if it got to a specific address in our code, but probably a hint.

Also unsure of it but R3/A4 address means anything, but looks like near memcpy

 .text.memcpy   0x00000000080f8958       0x1a /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(memcpy.c.o)
                0x00000000080f8958                memcpy
                0x00000000080f8958                __aeabi_memcpy
                0x00000000080f8958                __aeabi_memcpy4
                0x00000000080f8958                __aeabi_memcpy8
 .text.memmove  0x00000000080f8972       0x34 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(memmove.c.o)
                0x00000000080f8972                memmove
                0x00000000080f8972                __aeabi_memmove8
                0x00000000080f8972                __aeabi_memmove
                0x00000000080f8972                __aeabi_memmove4
 .text.memset   0x00000000080f89a6       0x10 /home/arduino/.arduino15/packages/zephyr/tools/arm-zephyr-eabi/0.16.8/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main+fp/hard/libc.a(memset.c.o)

The R12/ip: look near __wrap_free

                0x000000000800795d                PROVIDE (__wrap_free = 0x800795d)
                0x00000000080078f1                PROVIDE (__wrap_malloc = 0x80078f1)

Have not looked through the others, but maybe something

[Merlin513]

@ptillisch

Been testing switching to "static" mode from "dynamic" and seems to be causing a fault when running the sketch.

I have a simple "Blink" app (which is just the blink sketch) I have been testing with, nothing fancy.

In dynamic mode sketch loads and runs fine in 0.53.0. When I add in the platform.local,txt to change to static mode it fails:

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒K▒GK▒
▒G▒▒ FK▒G▒▒[00:00:02.193,000] <err> os: ***** USAGE FAULT *****
[00:00:02.199,000] <err> os:   Attempt to execute undefined instruction
[00:00:02.206,000] <err> os: r0/a1:  0x20000dd0  r1/a2:  0x00000000  r2/a3:  0x20000dd0
[00:00:02.215,000] <err> os: r3/a4:  0x080f0105 r12/ip:  0x08007821 r14/lr:  0x20032799
[00:00:02.224,000] <err> os:  xpsr:  0x69000000
[00:00:02.229,000] <err> os: s[ 0]:  0x20032749  s[ 1]:  0x00000002  s[ 2]:  0x000004d4  s[ 3]:  0x08005539
[00:00:02.239,000] <err> os: s[ 4]:  0x037030b9  s[ 5]:  0x0801877c  s[ 6]:  0x08019a78  s[ 7]:  0x20000e1c
[00:00:02.250,000] <err> os: s[ 8]:  0x08017fb0  s[ 9]:  0x0000000d  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:02.260,000] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:02.270,000] <err> os: fpscr:  0x080142d9
[00:00:02.276,000] <err> os: Faulting instruction address (r15/pc): 0x080f0104
[00:00:02.284,000] <err> os: >>> ZEPHYR FATAL ERROR 36: Unknown error on CPU 0
[00:00:02.291,000] <err> os: Current thread: 0x20000558 (main)
[00:00:02.298,000] <err> os: Halting system

Now if I run Blink from the IDE no issues.

So something else needs to change I think on the applab/cli side to get "static mode working.

[KurtE]

@Merlin513 @ptillisch
My Weather2 app builds and runs with current sources. I need to undo one thing to verify...
And it scrolls the weather information on the LED matrix

However if I use the platform.local.txt file with

build.link_mode=static
upload.extension=bin-zsk.bin

It faults like @Merlin513 mentioned.

*** Booting Zephyr OS build v4.2.0-38-g994b835f5936 ***
Invalid sketch header v:0 m:0
main malloc 0x20032738
[00:00:00.214,000] <err> os: ***** BUS FAULT *****
[00:00:00.220,000] <err> os:   Precise data bus error
[00:00:00.225,000] <err> os:   BFAR Address: 0x801
[00:00:00.231,000] <err> os: r0/a1:  0x0ae80000  r1/a2:  0x0ae80000  r2/a3:  0x15d00000
[00:00:00.239,000] <err> os: r3/a4:  0x080f6e69 r12/ip:  0x08007839 r14/lr:  0x2003278f
[00:00:00.248,000] <err> os:  xpsr:  0x29000000
[00:00:00.253,000] <err> os: s[ 0]:  0x20032749  s[ 1]:  0x00000002  s[ 2]:  0x0000a7fc  s[ 3]:  0x00000000
[00:00:00.264,000] <err> os: s[ 4]:  0x0801afa8  s[ 5]:  0x08005543  s[ 6]:  0x9adef20f  s[ 7]:  0x08018794
[00:00:00.274,000] <err> os: s[ 8]:  0x08019a90  s[ 9]:  0x20000e1c  s[10]:  0x08017fc8  s[11]:  0x0000000d
[00:00:00.285,000] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:00.295,000] <err> os: fpscr:  0x00000000
[00:00:00.300,000] <err> os: Faulting instruction address (r15/pc): 0x080f6fea
[00:00:00.308,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.316,000] <err> os: Current thread: 0x20000558 (main)
[00:00:00.323,000] <err> os: Halting system

Note: I modified the invalid sketch header output as was curious about what these
values are.

This is in loader\main.c

	bool sketch_valid = true;
	struct sketch_header_v1 *sketch_hdr = (struct sketch_header_v1 *)(header + 7);
	if (sketch_hdr->ver != 0x1 || sketch_hdr->magic != 0x2341) {
		printk("Invalid sketch header v:%x m:%x\n", sketch_hdr->ver,  sketch_hdr->magic);
		sketch_valid = false;
		// This is not a valid sketch, but try to start a shell anyway
	}

I get this message every time... So wondering if there is an issue and/or should this
message be silenced. Maybe raise as issue?

Also in Static mode, if I first run a sketch from the IDE, like my LED scrolling text using thread... and then try to run the App lab sketch the link fails:

Starting app "Weather2"
Sketch profile configured: Name="default", Port=""
The library ArduinoGraphics has been automatically added from sketch project.
The library ArxContainer has been automatically added from sketch project.
The library ArxTypeTraits has been automatically added from sketch project.
The library DebugLog has been automatically added from sketch project.
The library MsgPack has been automatically added from sketch project.
WARNING: library ArduinoGraphics claims to run on samd, renesas_uno architecture(s) and may be incompatible with your current board which runs on zephyr architecture(s).
Sketch uses 42964 bytes (2%) of program storage space. Maximum is 1966080 bytes.
Global variables use 7724 bytes (1%) of dynamic memory, leaving 515900 bytes for local variables. Maximum is 523624 bytes.
Open On-Chip Debugger 0.12.0+dev-ge6a2c12f4 (2025-05-22-15:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
clock_config
/tmp/remoteocd/sketch.elf-zsk.bin
Info : Linux GPIOD JTAG/SWD bitbang driver (libgpiod v2)
Info : Note: The adapter "linuxgpiod" doesn't support configurable speed
Info : SWD DPIDR 0x0be12477
Info : [stm32u5.ap0] Examination succeed
Info : [stm32u5.cpu] Cortex-M33 r0p4 processor detected
Info : [stm32u5.cpu] target has 8 breakpoints, 4 watchpoints
Info : [stm32u5.cpu] Examination succeed
Info : [stm32u5.ap0] gdb port disabled
Info : [stm32u5.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
CPU in Non-Secure state
[stm32u5.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x41000000 pc: 0x0801415e psp: 0x200216e8
Info : SWD DPIDR 0x0be12477
Error: error running OpenOCD: exit status 1
Error: Failed to write memory at 0x00000000
00000000
Error: file "/tmp/empty/empty.ino.bin-zsk.bin" does not exist
Usage:
remoteocd upload <binary> [flags]
Flags:
--adb-path string    Path to adb binary, if not set it will try to find it
-a, --address string     SSH address of the remote host
-f, --file stringArray   openocd configuration files to use
-h, --help               help for upload
-p, --password string    Password for the SSH connection
-s, --serial string      USB serial number of the connected board
Global Flags:
--quite     Enable quite logging (overrides verbose)
--verbose   Enable verbose logging
Failed uploading: uploading error: exit status 1

But if I then remove the platform.local.txt file (actually I renamed to .save
The App links and runs again.

Note one of the most recent commits that merged in created:
/home/arduino/Arduino/hardware/arduino/zephyr/variants/arduino_uno_q_stm32u585xx/scripts/set-to-ram-mode.sh

#!/bin/sh

# This script sets the micro of the Arduino UNO Q in RAM mode, and allow to flash it
# with menu option flash=ram.
# This is necessary because a flash in RAM mode is possible only if the micro
# isn't running any other sketch (in flash mode).
# The RAM mode is volatile, so after a power cycle the micro will not execute
# the sketch anymore.
# This is used by the arduino-app-cli when uploading sketches to the Arduino UNO Q.

# Requirements:
#   - arduino-cli
#   - jq

# Usage:
#   ./set-to-ram-mode.sh [port]


tmpdir=$(mktemp -d)
trap 'rm -rf "$tmpdir"' EXIT

sketch_path="${tmpdir}/empty"
mkdir ${sketch_path}

bin_path="${sketch_path}/empty.ino.elf-zsk.bin"
dd if=/dev/zero of=${bin_path} bs=50 count=1 > /dev/null 2>&1

if [ -z "$1" ]; then
  port=$(arduino-cli board list --format json | jq -r '.detected_ports[] | select(.matching_boards[]?.fqbn == "arduino:zephyr:unoq") | .port.address')
else
  port="$1"
fi

arduino-cli upload -p ${port} --input-dir ${sketch_path} -b arduino:zephyr:unoq

But don't know anything that calls it. Maybe upcoming app_lab, or ???

EDIT: Sorry there is probably 3/4 different things in the above message

[ptillisch]

Does the fault also occur if you delete platform.local.txt and use the "Alternative Approach" instead?:

https://forum.arduino.cc/t/is-it-possible-to-debug-an-app-lab-uno-q-crash/1429286/2#p-8378655-alternative-approach-3

[Merlin513]

@ptillisch - @KurtE

Decided to try various options of flash and link mode via the IDE as opposed to AppLab

FLASH + STATIC: Blink example works
FLASH+DYNAMIC: Blink example works
RAM+DYNAMIC:

[stm32u5.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x41000000 pc: 0x08014146 psp: 0x200216e8
Info : SWD DPIDR 0x0be12477
Error: error running OpenOCD: exit status 1
Error: Failed to write memory at 0x00000000
00000000
Failed uploading: uploading error: exit status 1

RAM+STATIC:

[stm32u5.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x41000000 pc: 0x08014146 psp: 0x200216e8
Info : SWD DPIDR 0x0be12477
Error: error running OpenOCD: exit status 1
Error: Failed to write memory at 0x00000000

00000000
Failed uploading: uploading error: exit status 1

[ptillisch]

OK, that explains it. Arduino App CLI uses the "RAM" option of the "Flash Mode" custom board option menu when uploading the sketch:

internal/orchestrator/orchestrator.go

[ptillisch]

You can force it to use the "Flash" configuration instead by adding this line to your platform.local.txt file:

openocd_cfg=flash_sketch.cfg

Reference:

boards.txt

[Merlin513]

@ptillisch

You can force it to use the "Flash" configuration instead by adding this line to your platform.local.txt file:

Was going to ask about that. But I added to plaform.local.txt and reflashed board just to make sure and it failed to upload

CPU in Non-Secure state
[stm32u5.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x41000000 pc: 0x08014146 psp: 0x200216e8
Info : SWD DPIDR 0x0be12477
Error: error running OpenOCD: exit status 1
Error: Failed to write memory at 0x00000000
00000000
Error: file "/tmp/empty/empty.ino.bin-zsk.bin" does not exist
Usage:
remoteocd upload <binary> [flags]
Flags:
--adb-path string    Path to adb binary, if not set it will try to find it
-a, --address string     SSH address of the remote host
-f, --file stringArray   openocd configuration files to use
-h, --help               help for upload
-p, --password string    Password for the SSH connection
-s, --serial string      USB serial number of the connected board
Global Flags:
--quite     Enable quite logging (overrides verbose)
--verbose   Enable verbose logging
Failed uploading: uploading error: exit status 1

EDIT and just for the record:

arduino@arduinoQ4:~/.arduino15/packages/arduino/hardware/zephyr/0.53.0$ cat platform.local.txt

openocd_cfg=flash_sketch.cfg
build.link_mode=static
upload.extension=bin-zsk.bin

arduino@arduinoQ4:~/.arduino15/packages/arduino/hardware/zephyr/0.53.0$

[Merlin513]

@ptillisch - @KurtE
If I change the platform.local.txt to just include:

arduino@arduinoQ4:~/.arduino15/packages/arduino/hardware/zephyr/0.53.0$ cat platform.local.txt
openocd_cfg=flash_sketch.cfg

Assuming this would just be the equivalent of FLASH+DYNAMIC, then Blink sketch compiles, runs and makes the led blink

Seems like issue when in RAM mode and maybe thats what that PR @KurtE refered too is suppose to fix.

[extender777]

Does it mean I can upgrade again to 0.53 and have working Uno Q?

[KurtE]

If it were me, and your goal was to do stuff with the Q, I would probably stay with
52. My guess is that 0.53.1 or similar will be released soon. They already tagged it on github, my guess is they are doing some testing and if things look good, will release. But again that is just a guess.

Personally I am interested in trying to figure out what is going on and to help test things... So I am trying out current stuff on one Q and 52 on the other.

Note: (More for the other thread about running current stuff) - I am personally setup to build zephyr and ArduinoCore-zephyr, so I have not tried the shortcut way of running the current stuff.

You can try to use the shortcut method of getting the current stuff:
ArduinoCore-zephyr/README.md at main · arduino/ArduinoCore-zephyr

There are artifacts associated with the last commit that has been merged, and there is a command to download that information into the appropriate places within your cloned ArduinoCore-zephyr project. I have not tried it myself yet as I typically always have local things on my machine, like trying to keep a pending Pull Request up to date and the like, but...

[Merlin513]

Think @ptillisch posted somewhere else that its probably not just 0.53,0 but also cli that needs to be updated.

@KurtE - your response is alot more complete than mine was.

[qubits-us]

i'm running 0.53.1
been staring at this change for a while..
been going through all the changes for .53, some reason this one is susp..
could it be that the memory is fragmented, still green to zephyr but that k function did guarantee a non-fragmented wonderful world??
curious if i'm patching my bridge sources correctly..
i am patching /home/arduino/.arduino15/packages/arduino/hardware/zephyr/
but i also see under /.arduino15/internal/
there's a bridge folder in there too??
i should add, using 0.53.1 the bridgetest sketch now works, bin file is 67.3KB..
Monitor.print is still all over the place..
~q

[extender777]

Much appreciated, I will stay with 0.52. I have no time for debug, I just wanna use my board.

[qubits-us]

might be posting to soon..
but looks like monitor print just doesn't like newline..
in my loop instead of Monitor.println("loop");
i changed it to Monitor.print("loop\r");
printing perfect..
go figure.. ~q