Debug an avr 4809 with microUPDI?

I added this section to PIO.ini

[env:debug]
debug_tool = custom
debug_server =
debug_port = 127.0.0.1:12555
build_mode = debug
debug_load_mode = manual


but although the code loads and runs ( i can interact through serial monitor over usart1), If I try to debug, it still collapses.

We’ve made a good effort and thanks for that, might there be anything else worth trying?

thanks
Paul

Very good! So the microUPDI works can connect to the chip :slight_smile:

So the script pyAVRdbg just stops like it did above there? What’s the last full output of the script when a debug session is started? Maybe something can be seen from that or at the very least, and issue can be opened with that log so that it may be investigated by the author.

i got the following from the python script and below that some output from the PIO debug console


C:\Users\Paul\Downloads\pyAVRdbg-master\pyAVRdbg-master>python main.py
INFO:pyedbglib.hidtransport.hidtransportbase:Manufacturer: ATMEL
INFO:pyedbglib.hidtransport.hidtransportbase:Product: mEDBG CMSIS-DAP
INFO:pyedbglib.hidtransport.hidtransportbase:Serial Number: MICROUPDIPROGRAMMERX
INFO:pymcuprog.deviceinfo.deviceinfo:Looking for device atmega4809
INFO:pymcuprog.nvm:UPDI baud rate: 900000bps
INFO:root:Event recived
PC: 529
INFO:root:Recived break event
INFO:root:No event
Waiting for GDB session 127.0.0.1:12555
Connected by ('127.0.0.1', 49737)
-> $qSupported#37
<- +
INFO:root:AVR running state False
Supported
<- $PacketSize=1000#f1
INFO:root:No event
-> ++$?#3f
<- +
INFO:root:AVR running state False
<- $S00#b3
INFO:root:No event
-> +$Hc-1#09
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qC#b4
<- +
INFO:root:AVR running state False
C
<- $#00
INFO:root:No event
-> +$qOffsets#4b
<- +
INFO:root:AVR running state False
Offsets
<- $Text=000;Data=000;Bss=000#24
INFO:root:No event
-> +$Hg0#df
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$g#67
<- +
INFO:root:AVR running state False
['0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x6a', '0x4e', '0xce', '0x3f', '0x16', '0x0', '0xec', '0x3f', '0xec', '0x3f', '0x0', '0x60', '0x4f', '0x4e', '0xcd', '0x3f', '0x16', '0x0']
['0x2']
['0xcd', '0x3f']
<- $00000000000000000000000000006a4ece3f1600ec3fec3f00604f4ecd3f160002cd3f#3c
INFO:root:No event
-> +$p22#d4
<- +
INFO:root:AVR running state False
530
0x212
0x424
00000424
24040000
<- $24040000#8a
INFO:root:No event
-> +$!#21
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qSymbol::#5b
<- +
INFO:root:AVR running state False
Symbol::
<- $OK#9a
INFO:root:No event
-> +$qRcmd,696e6974#07
<- +
INFO:root:AVR running state False
Rcmd,696e6974
<- $#00
INFO:root:No event
-> +
INFO:root:No event
-> $k#6b
<- +
INFO:root:AVR running state False

C:\Users\Paul\Downloads\pyAVRdbg-master\pyAVRdbg-master>

debug console output:

undefinedWarning! Ignore unknown configuration option `build_mode` in section [env:debug]

No symbol "target" in current context.
WARNING: Error executing command 'gdb-set target-async on'
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = custom
PlatformIO: Initializing remote target...
0x00000424 in __vector_29 ()
    at C:\Users\Paul\.platformio\packages\framework-arduino-megaavr-megacorex\cores\MegaCoreX/WInterrupts.c:154
154	IMPLEMENT_ISR(PORTF_PORT_vect, PF)
Current language:  auto; currently c++
C:\Users\Paul\.platformio\.cache\.piodebug-n125miqx/.pioinit:14: Error in sourced command file:
Target does not support this command.


When the error message appears, can you check whether the referenced file is there post the content?

At this location:

C:\Users\Paul.platformio.cache

this is what I see:

is any of that any good?

Hm it might delete it as soon as you click okay. What’s the examplatory content of the .pioinit file in the two .piodebug-x folders?

yes I ctrl clicked the file in the debug console and it doesn’t exist. From the pioinit file in the _u74 folder it has this ;

echo PlatformIO Unified Debugger -> http://bit.ly/pio-debug\n
echo PlatformIO: debug_tool = custom\n
echo PlatformIO: Initializing remote target...\n

define pio_reset_halt_target
    monitor reset halt
end

define pio_reset_run_target
    monitor reset
end

target extended-remote 127.0.0.1:12555
monitor init
load
pio_reset_halt_target
tbreak main

define pio_restart_target
   pio_reset_halt_target
   tbreak main
   continue
end
echo PlatformIO: Initialization completed\n

and from the _0al folder, this:

echo PlatformIO Unified Debugger -> http://bit.ly/pio-debug\n
echo PlatformIO: debug_tool = custom\n
echo PlatformIO: Initializing remote target...\n

define pio_reset_halt_target
    monitor reset halt
end

define pio_reset_run_target
    monitor reset
end

target extended-remote 127.0.0.1:12555
monitor init
load
pio_reset_halt_target
tbreak main

define pio_restart_target
   pio_reset_halt_target
   tbreak main
   continue
end
echo PlatformIO: Initialization completed\n

Mhm… Line 14 is monitor init. Maybe there’s an equivalent. Let’s test what happens when it’s commented out.

Can you add this to the environent you’re debugging:

debug_init_cmds =
  target extended-remote $DEBUG_PORT
  $INIT_BREAK
  $LOAD_CMDS

should disable all interaction with monitor but maybe also doesn’t reset the chip… See what it does and maybe press the reset button, too.

You may also leave out the $LOAD_CMDS to disable flashing via GDB.

ok so i added debug_init_cmds as follows in PIO.ini, leaving out $LOAD_CMDS

[env:debug]
debug_tool = custom
debug_server =[
debug_port = 127.0.0.1:12555
build_mode = debug
debug_load_mode = manual
debug_init_cmds =
  target extended-remote $DEBUG_PORT
  $INIT_BREAK
  

python output:

INFO:pyedbglib.hidtransport.hidtransportbase:Manufacturer: ATMEL
INFO:pyedbglib.hidtransport.hidtransportbase:Product: mEDBG CMSIS-DAP
INFO:pyedbglib.hidtransport.hidtransportbase:Serial Number: MICROUPDIPROGRAMMERX
INFO:pymcuprog.deviceinfo.deviceinfo:Looking for device atmega4809
INFO:pymcuprog.nvm:UPDI baud rate: 900000bps
INFO:root:Event recived
PC: 529
INFO:root:Recived break event
INFO:root:No event
Waiting for GDB session 127.0.0.1:12555
Connected by ('127.0.0.1', 49974)
-> $qSupported#37
<- +
INFO:root:AVR running state False
Supported
<- $PacketSize=1000#f1
INFO:root:No event
-> ++$?#3f
<- +
INFO:root:AVR running state False
<- $S00#b3
INFO:root:No event
-> +$Hc-1#09
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qC#b4
<- +
INFO:root:AVR running state False
C
<- $#00
INFO:root:No event
-> +$qOffsets#4b
<- +
INFO:root:AVR running state False
Offsets
<- $Text=000;Data=000;Bss=000#24
INFO:root:No event
-> +$Hg0#df
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$g#67
<- +
INFO:root:AVR running state False
['0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x6a', '0x4e', '0xce', '0x3f', '0x20', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x60', '0x38', '0x4e', '0xcd', '0x3f', '0x20', '0x0']
['0x21']
['0xcd', '0x3f']
<- $00000000000000000000000000006a4ece3f2000000000000060384ecd3f200021cd3f#c2
INFO:root:No event
-> +$p22#d4
<- +
INFO:root:AVR running state False
529
0x211
0x422
00000422
22040000
<- $22040000#88
INFO:root:No event
-> +$!#21
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qSymbol::#5b
<- +
INFO:root:AVR running state False
Symbol::
<- $OK#9a
INFO:root:No event
-> +$m5de,40#fb
<- +
INFO:root:AVR running state False
5de
40
0
INFO:root:Reading from address 0x0005DE
bytearray(b'!\xf4\xe5\x01"\x96\xf5\x01\x11\x81\x00\xe0\xdc\xcf\xea\xe0\xee\x16\xf1\x04\t\xf4\xbb\xc0\xf0\xe1\xef\x16\xf1\x04\t\xf0m\xc0\xe7\xcfx\xe0\xe7.\xf1,\x81,\x91,\xa1,`\xe1\xb6.p\xc0?\xe91\x0f:1(\xf49\xea')
21f4e5012296f501118100e0dccfeae0ee16f10409f4bbc0f0e1ef16f10409f06dc0e7cf78e0e72ef12c812c912ca12c60e1b62e70c03fe9310f3a3128f439ea
<- $21f4e5012296f501118100e0dccfeae0ee16f10409f4bbc0f0e1ef16f10409f06dc0e7cf78e0e72ef12c812c912ca12c60e1b62e70c03fe9310f3a3128f439ea#ed
INFO:root:No event
-> +
INFO:root:No event
-> $qRcmd,7265736574#37
<- +
INFO:root:AVR running state False
Rcmd,7265736574
<- $#00
INFO:root:No event
-> +$k#6b
<- +
INFO:root:AVR running state False

C:\Users\Paul\Downloads\pyAVRdbg-master\pyAVRdbg-master>

and from the PIO UI

also I cycled power to the microUPD board

That looks sooo close but avr-gdb doesn’t seem to have some features causing it to terminate. Eh, pettry printing can’t be that important.

Sadly the part where that command is generated is deep inside the JavaScript of the extension code, in C:\Users\<user>\.vscode\extensions\platformio.platformio-ide-2.3.0\node_modules\platformio-vscode-debug\dist\adapter.js. When you open this file in a text editor (mine of choice is Notepad++ and VSCode) and search for enable-pretty it gives you a line saying

this.miDebugger.connect(this.args.cwd,['interpreter-exec console "source .pioinit"',"enable-pretty-printing"])

You can try and delete the string from that array so that that part says

this.miDebugger.connect(this.args.cwd,['interpreter-exec console "source .pioinit"'])

You’d have to make that change and restart VSCode I think.

If it doesn’t work, revert the change again. (You can also always recover from this by reinstalling the VSCode PIO extension).

The other proper path would be just to look where to get (or compile) a avr-gdb version that supports pretty printing so that this is painless and supported, which I can look into tomorrow. The currently used version is 7.3.0 but there’s 10.1.0 for download (AVR-GCC 12.1.0 for Windows 32 and 64 bit | Zak’s Electronics Blog ~*) and that is also usable in PlatformIO (done it before, just needs a package.json and a platform_pacakges directives… more infos pending).

If the built executable also doesn’t support it I’ll have to recompile it.

Great that you found that pretty printing ref.:slight_smile: Thanks very much for exploring more recent avr-gdb and just to try to help a bit in pyAVRGDB it states the following with a link to some community repos:
Hopefully all this will be of use more widely to folks using the updi avrs

Install/Dependencies

  • avr-gdb
    • Recommend using the latest version. If you are compiling it I would looking at the arch community repos buildfile
    • Windows users might want to use wsl
  • libusb might be required as a seperate install
  • pip3 install --user pymcuprog
    • Some form for C++ compiler if you are running python versions higher than 3.6 since pymcuprog needs to compile package with Cython
      • Windows:

If there’s anything I can do to help, let me know e.g. I can download a newer version of avr-gdb, but as to how to integrate that into PIO I’d be stuck. Is there a guide?

Mhm I’m 99% sure a rebuild of AVR-GDB is needed because for pretty-printing to work it needs Python (since I read in the manual that it uses Python) and during the compile configuration one must pass --with-python. If I inspect the linked 10.1.0 build from the website linked above it gives me

C:\Users\Max\Downloads\avr-gcc-10.1.0-x64-windows\bin>avr-gdb --configuration
This GDB was configured as follows:
   configure --host=x86_64-w64-mingw32 --target=avr
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --without-expat
             --with-gdb-datadir=/omgwtfbbq/avr-gcc-10.1.0-x64-windows/share/gdb (relocatable)
             --with-jit-reader-dir=/omgwtfbbq/avr-gcc-10.1.0-x64-windows/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
                             --without-intel-pt
             --without-mpfr
             --without-xxhash
             --without-python
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/omgwtfbbq/avr-gcc-10.1.0-x64-windows/lib/debug (relocatable)

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)

And sadly there’s

--without-python

in the original ./configure so that’s not gonna work.

I’ll try to buid it in Linux first for Linux and then using MinGW for Windows. The --with-python option might a be bit tricky since it does need Python and potentially a ton of dependencies that have to be built too.

Did you attempt to delete the pretty printing instruction from the JavaScript file that I found above yet?

  • looks complicated ): I’ll try deleting the pretty printing instruction tonight and report back. Thanks for looking at stuff.

I definitely just made some progress in building AVR-GDB with Python support for Linux. Using the referenced script with

OPTS_GDB="
        --target=avr
        --with-static-standard-libraries
        --with-python
        --disable-source-highlight
"

and all FOR_X and BUILD_X set to 0 except FOR_LINUX=1 and BUILD_GDB=1 gives me a avr-gdb binary that does the following:

max@max-VirtualBox:~/Downloadsavr-toolchain$ ./avr-gcc-10.1.0-x64-linux/bin/avr-gdb 
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
[..]
(gdb) info pretty-printer
global pretty-printers:
  builtin
    mpx_bound128
(gdb) enable pretty-printer
0 printers enabled
1 of 1 printers enabled
(gdb) 

whereas the current toolchain used in PlatformIO does

C:\Users\Max\.platformio\packages\toolchain-atmelavr@1.70300.191015\bin>avr-gdb
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
[..]
(gdb) info pretty-printer
Undefined info command: "pretty-printer".  Try "help info".
(gdb) enable pretty-printer
warning: bad breakpoint number at or near 'pretty-printer'

So if that was the thing missing in AVR-GDB I should be able to to use the microUPDI firmware with my ProMicro board now and connect it to my Nano Every board. Thankfully it has the UPDI pin and the RESET pin of the on-board programmer exposed on pads at the bottom. I’ll see what I can get out of it.

that all looks like good progress. I’ve done a search using notepad++ and replaced the string with nothing as per your previous post. I’ll try that this evening. For some reason my microUPDI is now not getting recognised as a device, so working on that in the interim…

I got it working - a bad cable ! This is now the output from the debug window:

and the pthon script loops with lots of this:

C:\Users\Paul\Downloads\pyAVRdbg-master\pyAVRdbg-master>python main.py
INFO:pyedbglib.hidtransport.hidtransportbase:Manufacturer: ATMEL
INFO:pyedbglib.hidtransport.hidtransportbase:Product: mEDBG CMSIS-DAP
INFO:pyedbglib.hidtransport.hidtransportbase:Serial Number: MICROUPDIPROGRAMMERX
INFO:pymcuprog.deviceinfo.deviceinfo:Looking for device atmega4809
INFO:pymcuprog.nvm:UPDI baud rate: 900000bps
INFO:root:Event recived
PC: 527
INFO:root:Recived break event
INFO:root:No event
Waiting for GDB session 127.0.0.1:12555
Connected by ('127.0.0.1', 63512)
-> $qSupported#37
<- +
INFO:root:AVR running state False
Supported
<- $PacketSize=1000#f1
INFO:root:No event
-> ++$?#3f
<- +
INFO:root:AVR running state False
<- $S00#b3
INFO:root:No event
-> +$Hc-1#09
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qC#b4
<- +
INFO:root:AVR running state False
C
<- $#00
INFO:root:No event
-> +$qOffsets#4b
<- +
INFO:root:AVR running state False
Offsets
<- $Text=000;Data=000;Bss=000#24
INFO:root:No event
-> +$Hg0#df
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$g#67
<- +
INFO:root:AVR running state False
['0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x6a', '0x4e', '0xce', '0x3f', '0x20', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x60', '0x38', '0x4e', '0xcd', '0x3f', '0x20', '0x0']
['0x21']
['0xcd', '0x3f']
<- $00000000000000000000000000006a4ece3f2000000000000060384ecd3f200021cd3f#c2
INFO:root:No event
-> +$p22#d4
<- +
INFO:root:AVR running state False
527
0x20f
0x41e
0000041e
1e040000
<- $1e040000#ba
INFO:root:No event
-> +
INFO:root:No event
-> $m803fce,8#9a
<- +
INFO:root:AVR running state False
803fce
8
80
INFO:root:Reading from address 0x003FCE
bytearray(b's>\xacsY\xfa\xfb\xe5')
733eac7359fafbe5
<- $733eac7359fafbe5#c7
INFO:root:No event
-> +$m803fd6,8#6c
<- +
INFO:root:AVR running state False
803fd6
8
80
INFO:root:Reading from address 0x003FD6
bytearray(b'\xfc\xff\xbf\xcd?\xec\xde?')
fcffbfcd3fecde3f
<- $fcffbfcd3fecde3f#e7
INFO:root:No event
-> +$m803fde,8#9b
<- +
INFO:root:AVR running state False
803fde
8
80
INFO:root:Reading from address 0x003FDE
bytearray(b'\n\xdaT+\x9d\xed\xfd\x8f')
0ada542b9dedfd8f
<- $0ada542b9dedfd8f#21
INFO:root:No event
-> +$m803fe6,8#6d
<- +
INFO:root:AVR running state False
803fe6
8
80
INFO:root:Reading from address 0x003FE6
bytearray(b'\xf3OC\xfb\xe3\xf3\xb8U')
f34f43fbe3f3b855
<- $f34f43fbe3f3b855#97
INFO:root:No event
-> +$m803fee,8#9c
<- +
INFO:root:AVR running state False
803fee
8
80
INFO:root:Reading from address 0x003FEE
bytearray(b'\xfe\x17~R3\xff\xd6\xf7')
fe177e5233ffd6f7
<- $fe177e5233ffd6f7#9f
INFO:root:No event
-> +$m803ff6,8#6e
<- +
INFO:root:AVR running state False
803ff6
8
80
INFO:root:Reading from address 0x003FF6
bytearray(b'\x9b\xdf\xe5\xe4\xebl?\xff')
9bdfe5e4eb6c3fff
<- $9bdfe5e4eb6c3fff#5d
INFO:root:No event
-> +$m803ffe,8#9d
<- +
INFO:root:AVR running state False
803ffe
8
80
INFO:root:Reading from address 0x003FFE
bytearray(b'\x00k\x0c\x94P\x00\x0c\x94')
006b0c9450000c94
<- $006b0c9450000c94#bd
INFO:root:No event
-> +$!#21
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$qSymbol::#5b
<- +
INFO:root:AVR running state False
Symbol::
<- $OK#9a
INFO:root:No event
-> +$m5de,40#fb
<- +
INFO:root:AVR running state False
5de
40
0
INFO:root:Reading from address 0x0005DE
bytearray(b'!\xf4\xe5\x01"\x96\xf5\x01\x11\x81\x00\xe0\xdc\xcf\xea\xe0\xee\x16\xf1\x04\t\xf4\xbb\xc0\xf0\xe1\xef\x16\xf1\x04\t\xf0m\xc0\xe7\xcfx\xe0\xe7.\xf1,\x81,\x91,\xa1,`\xe1\xb6.p\xc0?\xe91\x0f:1(\xf49\xea')
21f4e5012296f501118100e0dccfeae0ee16f10409f4bbc0f0e1ef16f10409f06dc0e7cf78e0e72ef12c812c912ca12c60e1b62e70c03fe9310f3a3128f439ea
<- $21f4e5012296f501118100e0dccfeae0ee16f10409f4bbc0f0e1ef16f10409f06dc0e7cf78e0e72ef12c812c912ca12c60e1b62e70c03fe9310f3a3128f439ea#ed
INFO:root:No event
-> +
INFO:root:No event
-> $qfThreadInfo#bb
<- +
INFO:root:AVR running state False
fThreadInfo
<- $#00
INFO:root:No event
-> +$qL1200000000000000000#50
<- +
INFO:root:AVR running state False
L1200000000000000000
<- $#00
INFO:root:No event
-> +$qC#b4
<- +
INFO:root:AVR running state False
C
<- $#00
INFO:root:No event
-> +
INFO:root:No event
INFO:root:No event
-> $Z0,5de,2#12
<- +
INFO:root:AVR running state False
0
5de
1502
<- $OK#9a
INFO:root:No event
-> +$Z0,5ec,2#11
<- +
INFO:root:AVR running state False
0
5ec
1516
<- $OK#9a
INFO:root:No event
-> +$vCont?#49
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$Hc0#db
<- +
INFO:root:AVR running state False
<- $#00
INFO:root:No event
-> +$c#63
<- +
INFO:root:AVR running state False
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event

`

and finishes with this when I terminate the debug session in VSCode:


INFO:root:No event
INFO:root:No event
Traceback (most recent call last):
  File "C:\Users\Paul\Downloads\pyAVRdbg-master\pyAVRdbg-master\main.py", line 329, in <module>
    data = conn.recv(1024)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

C:\Users\Paul\Downloads\pyAVRdbg-master\pyAVRdbg-master>

Hmm that’s interesting. With just Linux and an unmodified GDB client, just with my platformio.ini


[env:ATmega4809]
platform = atmelmegaavr
;board = ATmega4809
board = nano_every
framework = arduino
upload_protocol = custom
upload_flags =
    -C
    $PROJECT_PACKAGES_DIR/tool-avrdude-megaavr/avrdude.conf
    -p
    $BOARD_MCU
    -c
    xplainedmini_updi
    -Pusb
    -b115200
upload_command = avrdude $UPLOAD_FLAGS -U flash:w:$SOURCE:i
debug_tool = custom
; no debug server
debug_server =
debug_port = 127.0.0.1:12555
build_type = debug
debug_load_mode = manual
debug_init_cmds =
  target extended-remote $DEBUG_PORT
  $INIT_BREAK
debug_init_break = tbreak loop

and starting the GDB server with pyAVRdbg, I get to the point where the microcontroller briefly halts in some code, then continues running, but I can stop it using the pause button.

Didn’t have to modify any JavaScript or replace my GDB client or anything.

But it still has problems resetting the chip and halting at my breakpoint (in loop).

Ahh I needed to upload the firmware once more it seems… Now it breaks at the right position and my call stack is there etc.

I’ll see what it does on Windows.