- This topic has 9 replies, 2 voices, and was last updated 6 years, 11 months ago by
.
-
Posts
-
Hi there, experienced programmer here, but only now signed up for the forums.
At the start of this year I bought two VisualGDB licenses and have been relatively impressed: an STM32 project I was doing for work has reached the release stage with almost no hickups.
While browsing the processor support I was intrigued to see that I could develop for AVR MCUs as well, which I have done in the past for home projects. Previously I used Atmel Studio 5.x, which did work, but it was very cumbersome (slow) to start up. Once started it was ok, but I tend to start and stop the IDE a lot in a day. Even so, my experience with Atmel Studio for AVR is what led me to try VisualGDB for STM32.
Except… VisualGDB seems lean and mean. It starts and stops with no lag at all compared to a normal Visual Studio project, and I’ve already rebuilt one of my existing software projects and written it to a homebrew board (using a JTAGICEv2 clone).
The only problem I’ve found is that when I use “Program and Start without Debugging” I get an error telling me that the debug interface failed, and the message in the box tells me (from memory) “Flash programming succeeded, but this tool can’t reset the board, so you need to do that manually”.
AFAIK my ATMega644PA supports a full JTAG interface, and certainly Atmel Studio had no problem with this. I’m wondering if there’s a debug option I can set to add this feature? I suspect there might be, because I know that the “nRST” pin on the JTAG interface is optional, but I made sure it was connected on my homebrew board.
Regards.
p.s. I’m not claiming that this is some huge deal. It’s already usable, and normal debugging works great. It just would be nice is all if I can see changes in my board behaviour without having to unplug it, unplug the JTAG, then plug it all back in again.
Hi,
Our AVR support is not as good as ARM as AVR devices are generally less popular and the underlying tools VisualGDB uses to do the low-level communication are somewhat more buggy. Can you confirm that programming FLASH on the same device while debugging works, but the program without debugging doesn’t? Or are both options broken?
Hi. Thanks for replying.
That’s a shame about AVR support being a lower priority, I thought that with the popularity of Arduino, 3D printing, etc that would not be the case. I understand your position however – I just thought it neat that I could use one environment (Visual Studio + VisualGDB) for all three of the development types I’m currently doing: Windows, STM32 and AVR (ATmegaXXX).
Re your question. If I use “Debug | Start Debugging” then the debugger seems to launch normally, without error message… Hmm. Let me just verify that it did actually load new code when I did that… Yes, it definitely programs the flash. So I only get the error message when I use “Debug | Program and Start Without Debugging”.
Incidentally, the last few lines in the GDB log says :-
mon detach
&”mon detach\n”
&”Target does not support this command.\n”
^error,msg=”Target does not support this command.”You raise a point that I hadn’t considered, though it seems obvious in hindsight. I’ve only recently migrated from devices (AD Blackfin) where the code loads from external flash to internal SRAM, so I’m not used to a debug image loaded by JTAG overwriting the flash. Good to know! Is it the intention that when you exit the debugger the original flash image is supposed to be restored?
One further feature of the problem: if I program the flash (getting the error), cancel the dialog and then hit reset on the board as instructed, then any subsequent attempt to program the flash or use the debugger will fail. I have to reset my devboard and cycle the power on the JTAGICEv2. So it looks like it’s leaving the JTAGICEv2 in some unexpected state.
Hi,
The main reason for worse AVR support is actually the underlying tools. VisualGDB relies on existing tools like OpenOCD or Segger J-Link software to handle the low-level communications and brings a usability level on top of it. The AVR devices use a completely different stack of tools that are much less popular and hence much less reliable, so VisualGDB inherits many of their limitations.
BTW, you can work around the ‘program without debugging’ error message by editing the <SysGCC>\avr\avr-bsp\debuggers\avarice\edp.xml file as follows:
<SupportedDebugMethods> <DebugMethod> <DetachCommand></DetachCommand>
VisualGDB will then skip the ‘mon detach’ command when programming the FLASH without debugging.
Perfect, thank you – that’s exactly the sort of workaround I was hoping for (though I’m currently at work so the suggestion is not tested).
Incidentally, I made a discovery since my last post: the JTAGICEv2 has a power toggle switch on it: don’t ask me why, but it’s a godsend. After flashing the AVR I cycle power on the JTAGICEv2. This not only resets the JTAGICEv2 but it also resets my board, killing two birds with one stone: the setup is then ready for my next code iteration.
I’m still surprised by your comment that the underlying tools are unpopular. Are you referring only to the AVaRICE interface? Because of course the Arduino environment is very popular with beginners or so I understand (for me it’s too confining: I’m not a beginner), and that uses presumably pretty much the same toolchain with a different code generator backend – and the IDE of course.
Hi,
No problem, let us know if you run into any further issues with “program without debugging”.
With the popularity, yes, AVaRICE is much less popular than tools like OpenOCD. Arduino is indeed very popular, but it does not support low-level debugging and based on the feedback we got, most Arduino users expect the development tools to be free and there would not be much interest for a professional-grade tool like VisualGDB.
Wow, you’re quite right. Since I don’t use it myself I hadn’t noticed that the Arduino environment doesn’t include a debugger! I guess Arduino is less an IDE, more a place to plug in working code written and debugged by someone else. Oh well, thanks for your help – and in fact with these workarounds I’m now finding VisualGDB AVR support to be perfectly usable: I’ve been having a lot of fun these last few days checking out the sensors I bought for AVR and never found time to write code for.
Hi,
You are welcome. It is a part of the VisualGDB design philosophy to allow tweaking and customizing the parts that may not work out-of-the-box, so that our users could get convenient experience even for rare scenarios that we don’t support directly. Our AVR support package is also open-source, so feel free to check it as a reference if you decide to customize further features.
You are also welcome to post any issues you encounter here and although we don’t guarantee seamless out-of-the-box operation for AVR devices, we should be able to suggest reasonable workarounds.
- You must be logged in to reply to this topic.