[ INFO ] Debug functionality: an update

[ubidefeo]

We have received a lot of confusing requests from users who had issues with the Debug feature of this new IDE,
From hard to decipher errors to unsupported hardware.

We are aware of the fact that such functionality can create confusion in both novice and advanced users, so the team and I decided to put together this update.

As we move towards a Beta release (it will be announced when we feel comfortable with giving it the monicker), we have been investigating the behaviour of the included debugger and plan to offer a much better working solution in the near future.
Please try not to ask "are we there yet" every week, just know that we're at work and we're not a big team.

A better debugger is coming, we look forward to releasing it into your hands, but we want it to be good :)

For the current debugger functionality you have to know the following:

• not every board is supported, in fact only ARM Cortex based boards can work
• our current lineup (MKR, Nano 33, Portenta H7) has support, somewhere it's flaky
• support for debug (a debug recipe) must be provided by the platform developer, so please don't ask us to enable debug for boards which we have no control over
• You CANNOT debug an Arduino UNO or a classic Nano
• in the current version of the debugger Global variables are not working and setting booleans fails miseraby: the solution is on its way
• you cannot step into library code, and also this is going to work when we release an update for the debug functionality
• such update will not necessarily come at the next minor Alpha release

Last but not lease: we know that the debug button in the UI is active no matter which board you select, and we're working on this because we don't like it either 😬

Please feel free to ask more questions below, we're more than happy to update this issue and help you get more clarity.

Thank you for reading us
Arduino Tooling Team

[DeqingSun]

It seems arduino-pro-ide shares a lot of code with VScode.
And VScode actually can debug a uno after this merged PR microsoft/vscode-arduino#685
If there is info for making a debug recipe, I can help to get it added.

[ubidefeo]

hey @DeqingSun
I'll look into that one, introducing DebugWire support would be interested for a lot of reasons.

@kittaakos can you also take a look on the Theia side?

[kittaakos]

can you also take a look on the Theia side?

What exactly, @ubidefeo?

[DeqingSun]

@ubidefeo I got the CLI work nicely with debugger package on

https://raw.githubusercontent.com/DeqingSun/unoDebugTestPackage/main/package_uno_debug_index.json

The set up is the same to https://github.com/DeqingSun/Debugging-Arduino-Uno without the VScode part.

However the pro-ide gave me -break-insert: Unknown option ``-function'' . No matter I connect debugger or not.

[ubidefeo]

@DeqingSun
nice progress on this 👍
as we are changing the Debug part of the new IDE we'll investigate this further.
Right now please consider the current debugger as broken, we're working to fix it nicely before next release

[DeqingSun]

@ubidefeo Is there a timeline for the next release? If it can be released in 2 week I will try to use the pro IDE for my class, otherwise I'll keep using VScode for teaching this semester.

[ubidefeo]

@DeqingSun
we have a few rough edges to polish, so cannot guarantee it'll be done in 2 weeks.
Also as we continue working on the language server and code assist I think we'll try to squeeze both feature in a single release.
Our release cycle could be faster, but I'd rather make sure things are exciting for users 🚀

[DeqingSun]

@ubidefeo I tried again with alpha 0.1.3 and it returns error "The debug session type "arduino" is not supported."

Is this something I can fix with editing launch.json or edit board.txt?

[rsora]

Hi @DeqingSun, thanks for reaching out again and helping us in making the new IDE better!

@ubidefeo I tried again with alpha 0.1.3 and it returns error "The debug session type "arduino" is not supported."

Can you please help me in understanding how to reproduce your problem providing:

• the board that you are trying to debug
• OS/Platform you are using
• (if possible) the sketch that you are trying to debug
• the HW debugger/tool that you are using

Thanks!

[DeqingSun]

@rsora
I tried multiple board and they throw the same error. "The debug session type "arduino" is not supported."

I tried "Arduino Zero programming port", "Arduino Zero USB port", "Arduino M0 pro programming port", and the avr board I defined. They have the same error.
I'm using the launch.json from https://github.com/arduino/arduino-pro-ide/issues/219 and arduino samd version 1.8.6
Mac 10.14.6
I was trying to debug the Blink example.
And I don't think the HW debugger/tool was even scanned so no hardware is connected to computer.

Deqing

[rsora]

@DeqingSun Can you please upgrade the samd core and try again?
We should have the 1.8.10 available.

Thanks!

[DeqingSun]

@rsora Thanks, seems the Arduino IDE can start openOCD at least. I'll take a look to see how to get it working for Uno.

[DeqingSun]

@rsora
It seems pressing the "Start debugging" button on the top will overwrite the launch.json with a working content. Mine is

{
  "version": "0.2.0",
  "configurations": [
    {
      "cwd": "${workspaceRoot}",
      "name": "Arduino",
      "request": "launch",
      "type": "cortex-debug",
      "executable": "/var/folders/l6/28chlnbn66b1nflyprjgv26h0000gn/T/arduino-sketch-A95360DDCF796B5109E9A069DBF3E5C9/Blink_copy_20201217101132.ino.elf",
      "servertype": "openocd",
      "serverpath": "/Users/sundeqing/Library/Arduino15/packages/arduino/tools/openocd/0.10.0-arduino7/bin/openocd",
      "armToolchainPath": "/Users/sundeqing/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/",
      "configFiles": [
        "/Users/sundeqing/Library/Arduino15/packages/arduino/hardware/samd/1.8.10/variants/arduino_mzero/openocd_scripts/arduino_zero.cfg"
      ]
    }
  ]
}

But using the debug panel on the left will not create such a template. Just mentioning.

[DeqingSun]

Hi @rsora, it seems I got some progress.
The new Pro IDE 0.1.3 changes the Debugger configuration in platform.txt.

So far I got 2 issues. First the IDE is always looking for arm-none-eabi-gdb for toolchain. Is it possible to override the file's name?

Also the server is called with argument "-c" "gdb_port 50000" "-s" "/Users/sundeqing/Documents/Arduino/testDebug" "-f" . Is it possible to customize the arguments?

I used this setting

# Debugger configuration (general options)
# ----------------------------------------
# EXPERIMENTAL feature:
#  - this is alpha and may be subject to change without notice
debug.executable={build.path}/{build.project_name}.elf
debug.toolchain=gcc
debug.toolchain.path={runtime.tools.DWDebugTools.path}/linux
debug.toolchain.path.windows={runtime.tools.DWDebugTools.path}/win
debug.toolchain.path.macosx={runtime.tools.DWDebugTools.path}/macosx

debug.server=openocd
debug.server.openocd.path={debug.toolchain.path}/dwdebug
debug.server.openocd.scripts_dir={runtime.tools.openocd-0.10.0-arduino7.path}/share/openocd/scripts/
debug.server.openocd.script={runtime.platform.path}/variants/{build.variant}/{build.openocdscript}

Update, refering to the code on https://github.com/Marus/cortex-debug/blob/a5a07dbbfa6acf53b157a62f4215b36c1ff854ca/src/openocd.ts , the serverArguments are hard coded.

[ubidefeo]

@DeqingSun
right now we're creating the configuration on the fly based on the platform, so custom parameters specified in launch.json are not supported.
this is a new implementation, as you might have seen, and we're testing the water to see what users want/need.
I'm considering letting users write an expansion of the created config file in which to add custom values, but this won't make it into a release before January, I'm afraid

[DeqingSun]

Hi @ubidefeo

I got the Pro IDE debug the Uno. Which is quite simple for use in the Pro IDE. Just add a board support, compile and debug. It is easier than VScode because the Launch.json can automatically fill the correct path for the debugging tools.

However, the Marus/cortex-debug did hardcoded the gdb file name and the openocd parameters. So there is a few dirty tricky involved in this work.

[ubidefeo]

hi @DeqingSun

sorry for the late reply, this is awesome!

Please be patient, on January we'll work on adding a new feature which is allowing the user to specify custom parameters to merge into the automatically generated launch file.
This is a much needed feature, but we wanted to deliver the Cortex Debug integration as soon as possible for our users to give us feedback, we'll get to it once all the dev team is back from their holidays.

thank you so much for being a part of this, we appreciate users who push the limits :)

[ronnyek]

In 0.1.3 (windows), Should this work with a arduino mkr 1010 wifi? Compile and run works fine, but attempting debug produces the following:

Open On-Chip Debugger 0.10.0+dev-gf0767a31 (2018-06-11-13:36)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: unable to find CMSIS-DAP device

[ubidefeo]

@ronnyek
to debug the chip running the program you need a debug interface.
The MKR WiFi 1010 does not have one on-board (the Arduino Zero, for instance, does) so you'll need an external interface.
The one supported out of the box is the Atmel ICE, while if you want to use another such as Segger J-Link, ST-Link or Black Magic Probe you need advanced configuration.

The error you get is due to no interface being found.
Also the WiFi 1010 has debug port pads at the bottom and you'll have to solder headers to access those

[ubidefeo]

hey @DeqingSun

sorry for getting back to you so late.
We have finally implemented the debug config override and you can find it in the Nightly build.
It's been there for about a week but I've been OOO for a few days.

In order to use it you'll need to create a local debug_custom.json file and override the properties you want to replace.
In this example I override interface, servertype and serverpath to use a J-Link with a Nano 33 IoT.
Mind that you don't need the whole structure of a launch.json file, we only override the configuration generated via CLI on the fly and replace the nodes which are specified in this new JSON

{
  "servertype": "jlink",
  "device": "ATSAMD21G18",
  "interface": "swd",
  "serverpath": "/usr/local/bin/JLinkGDBServer"
}

hope you'll like it :)
ubi

[DeqingSun]

Hi @ubidefeo

Thanks for the update. It is cool to change the launch.json parameters, but my problem is not caused by launch.json. As launch.json can load data correctly from platform.txt . I have no complain about it.

The real problem is cortex-debug plugin. As I mentioned on Dec 17, the armToolchainPrefix is fixed in package.json, and the parameters calling debug server is hardcoded in openocd.ts.

My solution is, make a copy of avr-gdb, and name it as arm-none-eabi-gdb to cheat the cortex-debug. And since I'm compiling my own debug server, I just check if the parameters matches the hardcoded one from cortex-debug. If so, just replace them with correct ones.

These problems for me will not be a problem for most of the ARM based board, as the ARM board is using arm-none-eabi-gdb and real openocd. I can not blame cortex-debug because I'm using it for an unrelated target device.

So my dirty fix did work for 0.1.3 and the nightly build. The fixes are dirty but the user won't notice it. The setup process for end-user are fairly easy.

Let me know if you would like to try it and I can send you a few samples to test it right away.

[ubidefeo]

@DeqingSun
please send it my way and I'll try and run it.
Which adapter do you use to debug?
I have a Dragon somewhere in my lab but gotta go dig it out :)

I thought what we implemented would work, because an automatically generated configuration from the platform is

{
      "cwd": "${workspaceRoot}",
      "name": "Arduino",
      "request": "launch",
      "type": "cortex-debug",
      "executable": "/var/folders/fg/55rcspkj0s53_kwrpyfl2bbh0000gn/T/arduino-sketch-10B418473B33AE139482A9628244D2F4/GartnerDemo.ino.elf",
      "servertype": "openocd",
      "serverpath": "/Users/ubi/Library/Arduino15/packages/arduino/tools/openocd/0.10.0-arduino7/bin/openocd",
      "armToolchainPath": "/Users/ubi/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/",
      "configFiles": [
        "/Users/ubi/Library/Arduino15/packages/arduino/hardware/samd/1.8.11/variants/nano_33_iot/openocd_scripts/arduino_zero.cfg"
      ]
    }

and you can override (or add) everything you need in there by making your own debug_custom.json.
What happens if you write this config file as

{
  "servertype": "gdb",
  "device": "DEVICE_ID",
  "interface": "DEBUGWIRE(?)",
  "serverpath": "/PATH/TO/AVR_GDB"
}

and add all you need?
Of course if you send me your config for VS Code I have the chance to try it :)

Let me know
ubi

[DeqingSun]

@ubidefeo The Uno debugger adaptor is an expanded USBTinyISP by dcwbrown. The debug server can talk in OPENOCD protocol, that's make it easy to use an ARM config. The hardware is either work with a attiny85 or a CH552 port. Both of them works.

Again, there is nothing wrong with the generated launch.json, the automatic generated file did load platform.txt correctly. The problem is the debug plugin. VScode's Arduino plugin is way more versatile than the cortex-debug (currently in Pro IDE) plugin. The cortex-debug has a lot of configurations hard coded and I don't think the launch.json in the sketch folder will be capable to change it.

The VScode config is on here. If you don't have the right hardware with you, I can also send you a few boards like this. And you may try debugging on it directly.

[kptb]

Has anyone been able to get this working with an Arduino Zero? ...something I purchased hoping this would be pretty painless.

I have tried to setup my json file based on picking from examples and by looking at similar threads for various errors I have gotten each time I've tweaked it. I haven't kept these as nothing seemed strongly enough in the right direction to pursue.

Would be fantastic if someone had something that will work with the zero out of the box they could share?

[ubidefeo]

@kptb we use the Arduino Zero all the time through the programming port (EDBG) and you don't need any customisation.
If you instead have an Arduino M0 Pro that's a different story, since that board is discontinued and there's no experimental support for debugging in the core

[DeqingSun]

The tested the Uno setup for Pro IDE also works for the IDE 2.0. And the 2.0 can choose the board automatically (I guess using PID/VID?), which make things even more easier.

[ubidefeo]

@DeqingSun
does it mean you managed to make it work?

[DeqingSun]

@DeqingSun
does it mean you managed to make it work?

yes it works perfectly.

[SomeGeek]

@DeqingSun Does your solution also work with the Atmel-ICE? If not, it would be great to have some documentation on the debug hooks.

That way we could just use AVaRICE to spawn the GDB server and let the IDE connect to it.

[ubidefeo]

happy to see you join the conversation, @SomeGeek ;)

[DeqingSun]

@DeqingSun Does your solution also work with the Atmel-ICE? If not, it would be great to have some documentation on the debug hooks.

That way we could just use AVaRICE to spawn the GDB server and let the IDE connect to it.

I don't think my setup will work with Atmel-ICE. And I've never used AVaRICE.

You can check this repo to see how it works. The configuration is in platform.txt and board.txt. As I mentioned before, the debugger module in Arduino IDE will call the debugger server with "-c" "gdb_port 50000" "-s" "/Users/sundeqing/Documents/Arduino/testDebug" "-f", you may need to modify AVaRICE to accommodate such parameters or run another program as the middle-man to deal with it.

[SomeGeek]

@DeqingSun great, I will check into it next week and report back.
@ubidefeo It would be nice if this would be easily adjustable. For example, have an option called debug_server_params (eventually with variables such as the compiled binary) and something like debug_server_port. These are just examples. That way it would be much more flexible for others to use implement their own configs.

[ubidefeo]

@SomeGeek
you should be able to override and add any option for the generated configuration via a debug_custom.json file in the Sketch folder.
I have mentioned this above
#87 (comment)

[tigoe]

I'm excited to see this, and excited to see @DeqingSun contributing to it. It will take some really good documentation to make sure beginners in the IDE 2.0 don't mess up their SAMD boards by trying to use the debugger. I would suggest two things:

• Some clear documentation, written for beginners, on how to use the debugger (@DeqingSun's repo is a good starting place)
• Good error messages that let you know when the debugger might be getting in the way of your non-debugger-related development, and how to resolve it. For example:

1. Open a new sketch
2. Open debugger
3. Add a new configuration, don't put anything in it
4. Switch back to the sketch tab, upload

This is as good a way as any I've found to make your SAMD-based board totally unresponsive, and there's no error message telling you what you did wrong. And it's likely the default behavior for someone who's never used a debugger (feel free to move this to a more appropriate thread, @ubidefeo )

[SomeGeek]

I finally got some time to continue with this.

Using the packages @DeqingSun provided and the prepared digispark, I was able to get it to debug on VSCode. On the Arduino IDE however, clicking launch spawns a cursor inside launch.json with a selection of debug templates (and I already have defined one). I don't know what I'm missing.

The same happens using an modified avarice build which corrects the parameters.

[per1234]

Hi @SomeGeek

clicking launch spawns a cursor inside launch.json with a selection of debug templates (and I already have defined one). I don't know what I'm missing.

The interface of the debugger is not yet as user friendly and intuitive as we would like. It is essential that you initialize the debugger by clicking the "Start Debugging" button on the button bar:

The "Debug" button on the activity bar should only be used for toggling the visibility of the debugger panel.

If you open the debugger via the "Debug" button on the activity bar without first clicking the "Start Debugging" button on the button bar, then the debugger is unconfigured. If you then click the "Start Debugging" button (▷) in the "DEBUG" view, it creates an empty .theia/launch.json file in the sketch and opens that file in the editor, as you experienced already.

In order to make debugging accessible to the target user, the Arduino IDE automagically generates a launch.json file in the temporary build folder when the debugger is initialized. This file is configured for the board you currently have selected in the Arduino IDE, according to the properties set in the Arduino boards platform of that board. For this reason, the .theia/launch.json file is completely ignored, and thus this file the unconfigured debugger creates is a dead end when it comes to configuring the debugger.

Even though it is possible to override all keys under configurations[0] in the auto-generated launch.json by adding a debug_custom.json file to your sketch, the IDE still requires the platform of the currently selected board to contain a full debugging configuration, like how it is done in the "Arduino SAMD (32-bits ARM Cortex-M0+) Boards" platform here:

https://github.com/arduino/ArduinoCore-samd/blob/1.8.12/platform.txt#L129-L140

The IDE is smart enough to disable the "Start Debugging" button on the button bar if the platform does not define a debug.executable property, but all the other properties you see at the link above are also required for the debugger to actually be initialized. If any are missing, you will get no apparent reaction from clicking that button.

[DeqingSun]

Some update about Uno debugging.

I've tested Arduino 2.0.0/2.0.1 in a class and the IDE worked very well with ATMega328P with the board support. The students can debug the ATMega328P and see how the code works.

The "Request 4 cancelled on connection closed" error appeared once while I did the demo and it was fixed with the method mentioned in the Arduino Forum. Not sure the root of cause but maybe related to some settings.

[per1234]

The "Request 4 cancelled on connection closed" error appeared once while I did the demo and it was fixed with the method mentioned in the Arduino Forum.

Hi @DeqingSun there is a known bug that can cause this error:

#1582

A more convenient workaround is described under the "Additional context" section of that issue.

[per1234]

• in the current version of the debugger Global variables are not working and setting booleans fails miseraby: the solution is on its way
• you cannot step into library code, and also this is going to work when we release an update for the debug functionality

These defects were fixed long ago (perhaps by e7b1a27).

the debug button in the UI is active no matter which board you select

Fixed by e7b1a27