Please, add a basic debugger to IDE

[q2dg]

If Zero board has the ability of being debugged, and the low-level tools (openocd, gdb) already exist and are shipped within the IDE, it's a pity that IDE doesn't offer a basic GUI interface to them. Following these steps (http://starter-kit.nettigo.eu/2015/debug-sketch-on-arduino-zero-pro-with-gdb-and-openocd ...caution, he talks about "the other" board, but I suppose it's the same) is a real pain...so Zero's user experience would improve a lot with a GUI. I know it's a big change...but at least I would like to know if it is the roadmap.
Thanks.

[maimaris]

All arduinos need a debugger

[PaulStoffregen]

Easily said, not as easily done...

[q2dg]

Well, I'm focused in Zero because its product page (https://www.arduino.cc/en/Main/ArduinoBoardZero) says: "One of its most important features is Atmel’s Embedded Debugger (EDBG), which provides a full debug interface without the need for additional hardware, significantly increasing the ease-of-use for software debugging" If you say this and IDE doesn't offer the hability of using this, it's better not to say it, isn't? But more important...the tools are already available and functional!! I only ask for a GUI integration (maybe a toolbar only visible if Zero is selected from Boards menu).

[PaulStoffregen]

I only ask for a GUI integration...

Yup, much more easily said than done!

[NicoHood]

At that point I am also wondering why there is nothing happening on the new boards. They are just there, working more or less. The support even by Arduino.cc is very little so I am not wondering why noone uses those other boards or only complain about missing features. It looks like that Arduino is missing some man power. And the truck factor seems very high to me.

But sure I am aware that this is a huge feature that needs to be implemented. Just wondering from who?

[PaulStoffregen]

Eventually, I will probably be the guy who implements this.....

But don't let that slow or discourage you. If you want it, this is open source, so you can do it. Only a small matter of programming is required!

[NicoHood]

Me? Nah I have other projects :D The USB core needs some more patches, you should probably know best ;)

[PaulStoffregen]

Yeah, my own USB stack has a long list of features still to be implemented....

[NicoHood]

I was thinking of adding LUFA somehow to the core. This would be the best and most professional core I think. I am very happy about the pluggable core, but it adds a lot of overhead. Why dont we work together?

[NicoHood]

Oh I love writing offtopic sometime.

Paul, did you know that you can extend your keyboard API with even more consumer keys? Instead of only supporting 8 fixed keys you can support the first 255 keys like that:

    /* Reserved byte, used for consumer reports, only works with linux */
    0x05, 0x0C,                      /*   Usage Page (Consumer) */
    0x95, 0x01,                      /*   REPORT_COUNT (1) */
    0x75, 0x08,                      /*   REPORT_SIZE (8) */
    0x15, 0x00,                      /*   LOGICAL_MINIMUM (0) */
    0x26, 0xFF, 0x00,                /*   LOGICAL_MAXIMUM (255) */
    0x19, 0x00,                      /*   USAGE_MINIMUM (0) */
    0x29, 0xFF,                      /*   USAGE_MAXIMUM (255) */
    0x81, 0x00,                      /*   INPUT (Data,Ary,Abs) */

However I did not find out how to add an offset. But since I also want to use the sleep (0x32) this isnt that big problem. And the conumer API still exists though. Linux gives us enough options there.

Also your RAWHID test program might need an update. The libusb hidapi works good for me and detects the devices better but it cannot read the USAGE ID it seems, I might be wrong. However I am trying to patch hyperion to visualize leds via rawhid which is quite difficult due to the buffer limits etc.

[PaulStoffregen]

Yes, I'm aware of the other consumer keys. Believe me, that is one of many hundreds of (lower priority) features on my TODO list.

LUFA is very tightly tied to AVR architecture. It's also a tremendously complex coding style that's pretty much the opposite of how I prefer to do things. At this point, I'm leaving all my AVR code as-is and only focusing on adding new features to the ARM code base. So I really don't have any desire to work with LUFA.

Additional PC-side RAWHID examples are an area where I'm looking to accept contributions, but I'm not personally planning to spend more dev time on programming the PC. If you do anything there, please let me know and I'll make a link.

[q2dg]

Very interesting...but returning to original question, I would like to know if you consider adding some buttons on the IDE toolbar which conveniently call to openocd and gdb is a fool idea.

[PaulStoffregen]

Go forth to add those buttons and try to make them work. Then you can tell us whether it was foolish!

[PaoloP74]

--> https:/waldschip/ZeroGDB
But work only on Arduino.org's IDE.

[NicoHood]

Wow. People are developing on top of the .org IDE? Impressive and risky.

[ffissore]

It also works only on windows

[lmihalkovic]

I picked up the ZeroGDB code and adapted it for the .cc IDE. In the process I started looking into subclassing the Tool interface with a PlatformTool interface. The purpose of this one is to allow tools that would work for different platforms. My use case is that I am playing with Teensy, AVR, and Arduino_STM32, so I need the right version to fire up. I am also running on OSX, so hardcoding the exe name (and version for that matter) is also a no-go. My current thought is to have a single extension with some config settings... something like
tools.arduinogdb.HARDWARE1.PLATFORM.xxxx.yyyy.zzzz2 = something or other
tools.arduinogdb.HARDWARE1.PLATFORM.xxxx.yyyy.zzzz1 = something or other
tools.arduinogdb.HARDWARE2.PLATFORM.xxxx.yyyy.zzzz = something or other

where HARDWARE would be
avr, Arduino_STM32, teensy (these are the ones I know about)
and PLATFORM would be
osx, win32, linux

Any thoughts?!

I also looked at the code that searches for these extensions... was thinking about extending it with the standard java ServiceLoader. Pros/Cons anyone?!

PS: I was also thinking that it could be useful if some of the config for the launcher was overridable per project such that a sketch folder could have files like the following stored locally to handle whatever I am not seeing clearly at the moment:
tool_arduinogdb_avr_osx.conf
tool_arduinogdb_teensy_osx.conf
if something like that is present inside the sketch, then the ArduinoGDB tool will read the correct INSTEAD OF the default cont inside the .jar. Makes sense?!

[lmihalkovic]

... then again... I just saw how nicely most of the work is done when it comes accessing the toolchain..

I will experiment will the following

platform.txt

# AVR GDB
# -------
debug.gdb.path={runtime.tools.avr-gcc.path}/bin/
debug.gdb.cmd=avr-gdb

[xcvista]

A possible solution: collaborate with Atmel again and enable using the ATmega16U2 on each board as a (probably stripped down) version of mEDBG (the mEDBG chip on ATmega328P Xplaoned Pro is ATmega32U4, so if we can cope with halving both flash and RAM space we can do with that) and reprogram Arduino chips to use debugWIRE for mEDBG to work. Two mEDBG firmwares can be provided, using a pin broken out from 16U2 for debugWIRE on one and the built-in RESET line for the other (so a user can make a solder bridge across the 100nF autoreset cap for the mEDBG to work)

For Arduino Leonardo a mEDBG sketch (like the ArduinoISP sketch) can be released so another Arduino can be programmed with that sketch to debug a Leonardo (or other boards as well.)

[NicoHood]

Feel free to code a firmware for the 16u2. But I guess its very hard, because of the limitations.
you might want to have a look at this one:
https:/NicoHood/HoodLoader2

The main problem is, that the required pins are just not wired on the PCB. Doesnt mean its impossible, but they need to re manufacture all boards, which I think they will never do. Also the 32u4 is now cheaper than the 16u2 I think, since its used so many times and the price fell down. However it is a bit bigger in size.

The best solution would be to just buy a real JTAG debugger and use that. But this is out of Arduino context and the question here was not about hardware, it was about a software integration of the given hardware possibilities.

[xcvista]

The only signal that is used in debugWIRE (the only signal required for debugging to work on m328p and m32u4) is RESET which is already broken out. Place a solder blob on top of the auto reset capacitor and we have the debugWIRE connection. debugWIRE support not only debugging but also ISP so by using the 16u2 as debugWIRE we can even say goodbye to the serial boot loader.

Neither m328p nor m32u4 supports JTAG. m2560 supports it so if we roll a new version of Arduino 2560 we can use m32u4 as the onboard JTAG debugger and USB to Serial adapter (and also say goodbye to the serial boot loader)

[NicoHood]

Are you able to program a 16u2 debug wire firmware?

[xcvista]

If I can get my hands on debugWIRE protocol and JTAGICE mkII or mEDBG USB protocol specification I can try code one.

[NicoHood]

Feel free to do that. If it works, we can possibly provide a sketch like Arduino ISP which works on multiple MCUs, not only the 16u2. However I am not sure how the USB Interface needs to look like. But sure that would be a good idea, either with the IDe or with a LUFA firmware. With HoodLoader2 installed on the 16u2 you could even always switch back and forth beween default or other firmwares (it it fits into 12kb flash).

[mikaelpatel]

@NicoHood
Here is a totally different approach to implementing a debugger for AVR. It is part of the Cosa core and libraries. https:/mikaelpatel/Cosa/blob/master/libraries/Debug/examples/CosaDebug/CosaDebug.ino

The debugger is command line shell executed on the board using the serial monitor or any io-stream. Debug commands are added to the source code. Please see the example sketch above.
https:/mikaelpatel/Cosa/blob/master/libraries/Debug/Debug.hh

The debug commands could be added to an application sketch in the IDE. Commands such as insert break-point, conditional break-point, assert, observe variable, memory check, etc.

Cheers!

[lmihalkovic]

@xcvista I was under the impression that debugWIRE was a proprietary technology not accessible outside of commercial products.

I did a bit of searching around and there are plenty of resources accessible to bootstrap the effort. The most crucial resource is time...

[xcvista]

@lmihalkovic This is why I think to pull this off we need another collaboration with Atmel.

[tuxedo0801]

@xcvista

Neither m328p nor m32u4 supports JTAG.

That's not correct: ATmega32u4 (used in Leonardo, Micro, ProMicro, ...) supports JTAG:

http://www.ba0sh1.com/jtag-adapter-arduino-micro/

[PaulStoffregen]

ATmega32u4 ... supports JTAG:

But are the scan chains and internal registers and usage protocols documented?

Many of us have asked Atmel for this info. The answer has always been they consider this info proprietary and will never release it, even under NDA.

Someday debug support is likely to happen for the ARM chips, but unless Atmel changes their tune, 3rd party JTAG/debugwire support (in software other than Atmel Studio) for AVR is almost certainly never going to be implemented.

[q2dg]

Well...there's only one ATmega32u4-based board branded as "Genuino": the
"Micro" board. No Leonardo, no Yún... So, you can infer... I don't see much
future of this microcontroller in Arduino's ecosystem.

2016-05-09 16:57 GMT+02:00 Paul Stoffregen [email protected]:

ATmega32u4 ... supports JTAG:

But are the scan chains and internal registers and usage protocols
documented?

Many of us have asked Atmel for this info. The answer has always been they
consider this info proprietary and will never release it, even under NDA.

Someday debug support is likely to happen for the ARM chips, but unless
Atmel changes their tune, 3rd party debug support for AVR is almost
certainly never going to be implemented.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#4010 (comment)

[mikaelpatel]

I have ported the Cosa Debugger to Arduino and made it available; https:/mikaelpatel/Arduino-Debug

Enjoy!

[tuxedo0801]

But are the scan chains and internal registers and usage protocols documented?

No idea. All I can say: You can use ATMEL Studio with f.i. ATMEL ICE debugger to jtag-debug the arduino leonardo. Did this myself. Works.
And if Atmel Studio is not an option, go for AVaRICE.

Well...there's only one ATmega32u4-based board branded as "Genuino"

Who cares about branding? There are much more controller out there using 32u4...

I have ported the Cosa Debugger to Arduino and made it available;

Thanks. Will have a look at it.

[Avamander]

I really think adding basic remote GDB debug support in GUI would take Arduino IDE to next level and would also make it possible to use anything that just offers remote GDB debugging, be it AVR or ARM (or even PIC or ESP*).

[per1234]

There is now a debugger integrated in Arduino CLI:
https://arduino.github.io/arduino-cli/latest/commands/arduino-cli_debug/
As well as the Arduino Pro IDE:
https://blog.arduino.cc/2020/02/28/preview-the-debugger-feature-for-the-arduino-pro-ide/