After installing windows 10 ltsc and reinstalling applab it seems like I can not upload any sketches to the Q anymore.
Trying the BLink LED example I gett
Starting app "Blink LED"
Sketch profile configured: Name="default", Port=""
The library Arduino_RPClite has been automatically added from sketch project.
The library Arduino_RouterBridge 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.
Sketch uses 19312 bytes (0%) of program storage space. Maximum is 1966080 bytes.
Global variables use 4692 bytes (0%) of dynamic memory, leaving 518932 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: 0x08014546 psp: 0x20021890
Info : SWD DPIDR 0x0be12477
Error: error running OpenOCD: exit status 1
Error: Failed to write memory at 0x00000000
00000000
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: 0x08014546 psp: 0x20021890
Info : device idcode = 0x30076482 (STM32U57/U58xx - Rev U : 0x3007)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 2048 KiB
Info : flash mode : dual-bank
Info : Padding image section 0 at 0x080f0032 with 14 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x080f0040 .. 0x080f1fff
shutdown command invoked
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: 0x08014546 psp: 0x20021890
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
I would try first to program blink from Arduino IDE 2.x on it.
I would probably first try to burn the bootloader, to make sure it has the same one.
(Also have USB To serial on pins 0, 1 to see if it shows anything)
And I assume you checked that the right serial port selected.
else: on applab, I would probably open command prompt and again try to burn a new bootloader from there. For me that is simply typing: burn_bootloader
as I have alias setup in my .bashrc:
alias burn_bootloader='arduino-cli burn-bootloader -b arduino:zephyr:unoq -P jlink'
alias cleanup='arduino-app-cli system cleanup'
I do not have the board but I will take a SWAG and did some doing some looking on the web I found: Your code compiled, the debugger found the STM32U5, but the uploader setup is wrong and it is trying to program memory incorrectly. The failure occurs when it tries to perform a memory write at address 0x00000000.
The key line are: Error: Failed to write memory at 0x00000000. On STM32 parts, internal flash is normally mapped around: 0x08000000, not 0x00000000 as the real flash programming target. Hopefully this helps.
When burn Bootloader task is performed, what parameters are updated in the MPU and MCU of the UNO Q Board? Is there any fuse bits or lock bits similar to ATmega328P?
The binary codes of the sketch must be passing to the MCU via Router Bridge. In that case, you may try the following commands in case anything wrong/jammed with the roughter bridge:
(1) From linux terminal (>_) of App Lab, type the following and then press Enter key. arduino-app-cli system cleanup
(2) Then type the following and then press Enter key. docker network prune
Turns out that I havent played with the 2gb version of the Q in such a long time I forgot I never updated the bootloader. Once I updated to 53,1 everything ran.
The term Bootloader is sort of misleading or at least different here:
With the Arduino Zephyr setup: A good percentage of the stuff you run is built into the bootloader. This includes all of the stuff within their fork of the Zephyr project. This includes most of the major pieces, like GPIO, SPI, Wire, PWM, ...
There is then also built into these an area for Loadable Extensions, or specifically when we build our Arduino sketch, are actual code and data goes into some predefined sections of memory, and suppose your code calls some stuff within bootloader, there are sort of like jump tables built, where, in your arduino code, it may says to call through the jumper #1, where in the jumpers table will take you to the real code... Likewise the device tree is setup built as part of building the bootloader. Information about it is then propagated to header files that are used in building your sketch:
example files under where your install is, like arduino15\packages\arduino\hardware\zephyr\0.53.1\
In that same directory:
autoconf.h - shows which options and values were configured into the build
syscall_list.h - shows some of the indexes mentioned.
So if you are compiling with one version of this, but the board has another version of it built into it, it might work, depending on what changed between the two versions, or it might fail to upload like he saw, or it might fail when the processor restarts, and you may see faults or load problems that the system prints out. Most of the time these get printed out on most of our boards on the Hardware Serial (pins 0, 1)...
Sorry I know I probably did not explain this very well. Others like @ptillisch are much better at it!
does get confusing at times. When I say bootloader I am referreing the core version of ArduinoCore-zephyr - in the IDE 2.3.8 think its listed as bootloader :)
Thank you for your effort in helping me understanding the bootloader state of the UNO Q board.
When we perform the “Burn Bootloader” operation on an UNO R3 or an ATtiny85,
we clearly understand what actions are taking place. Likewise, a similar scenario may exist for the UNO Q.
