AVR JTAG MK I almost there …

[rasyoung]

Howdy all!,

I was able to get a successful test on a connection to a clone AVR JTAG Mk I, on comport #9, by adding a linux style comport designation (/dev/com9) to the setup for a simple ATMega16a example. However when I attempt to start the session, Visual Studio crashes hard.

See attached screen cap.

Advice?

Thanks

R.

Attachments:

You must be logged in to view attached files.

[rasyoung]

Here’s the log …

C:\SysGCC\avr\bin\avarice.exe –file “C:\Codetest\AVR\VsualGDB\Atmega32a\VisualGDB\Debug\Atmega32a” -1 -B 125K –erase –program –verify -j /dev/com9 :2000
AVaRICE version 2.13, Apr  1 2016 17:36:26

JTAG config starting.
Hardware Version: 0xc3
Software Version: 0x80
Reported JTAG device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.
Erasing program memory.
Erase complete.
Preparing the target device for On Chip Debugging.
Downloading FLASH image to target….

Verifying FLASH

[rasyoung]

The relevant error message I believe is :

“No connection could be made because the target machine actively refused it”

Attachments:

You must be logged in to view attached files.

[rasyoung]

Finally, this hardware setup work perfectly under Atmel Studio 4, sp2 418.

Thanks in advance for the consideration of your reply.

[rasyoung]

Did my best to evaluate permissions, and potential issues with Windows Defender firewall. Of course Visual Studio 2017 is run as admin.

I ran the avarice from the command line… to insure it was up and waiting and forced VisualDBG to execute… notice the termination at the end of the session.

C:\Codetest\AVR\VsualGDB\Atmega32a\Atmega32a>C:\SysGCC\avr\bin\avarice.exe  -1 -B 250K -j /dev/com11  :2000
AVaRICE version 2.13, Apr  1 2016 17:36:26

JTAG config starting.
Hardware Version: 0xc3
Software Version: 0x80
Reported JTAG device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.
Preparing the target device for On Chip Debugging.
Waiting for connection on port 2000.
Connection opened by host 127.0.0.1, port 50587.
gdb exited.

[support]

Hi,

Thanks for checking this. If avarice works from command line, but not with normal VisualGDB settings, it might be caused by some command line option (e.g. programming the FLASH). Please try comparing the manual command line with the command line shown in Visual Studio when launching the debug session (you can also see the command line via View->Other Windows->VisualGDB Diagnostics Console).

If the command line arguments are exactly the same, does switching VisualGDB debug method to “custom gdb stub” and hardcoding the command line change anything?

[rasyoung]

Tried quite a number of different options, as the custom gdb was easy to implement after I decided to create a new example, but never got any material change in behavior.

I guess I need to clarify exactly what series of arguments should be give to avarice to get it in the correct state to talk to openocd, in the way that works properly with VisualGDB? Exacting all the possible options, by trial and error, is not very efficient.

Not sure if I know this critical piece of information…

 

 

• This reply was modified 7 years ago by rasyoung.

[rasyoung]

Hello!,

So back to my original approach I setup as before but skip the verify step.

C:\SysGCC\avr\bin\avarice.exe –file “C:\Codetest\AVR\VsualGDB\Atmega32a\VisualGDB\Debug\Atmega32a” -1 -B 250K –erase –program -j /dev/com11 :2000
AVaRICE version 2.13, Apr  1 2016 17:36:26

JTAG config starting.
Hardware Version: 0xc3
Software Version: 0x80
Reported JTAG device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.
Erasing program memory.
Erase complete.
Preparing the target device for On Chip Debugging.
Downloading FLASH image to target….

at least I see a change, the connection is no longer refused.

Cannot resolve the address of _estack or __StackLimit. Skipping stack pointer validity check.

 

Please advise. Thanks!!!

Randy

[rasyoung]

OK, was able to affect some change, by deleting the VERIFY step, and setting a breakpoint in the code.

I do get the previous error message about the stackframe, but it will step through the code very slowly.

Take 5 or 6 seconds for each step to execute.

The flash step prior to debug does load the updated firmware to the chip.

 

 

 

 

Attachments:

You must be logged in to view attached files.

[rasyoung]

Just confirming, Atmel Studio 4.18 sp3, runs this program perfectly, debugs, and automates like a champ via the serial JTAGICE (mk I). So even from an Oracle Virtual Box VM, this code auto steps perfectly, and the hardware LED blinks precisely as you would expect.

https://www.ebay.com/itm/1PCS-AVR-JTAG-AVR-USB-Emulator-Simulator-Debugger-Programmer-JTAG-ICE-for-Atmel/272191095130?hash=item3f5fda815a:g:LfgAAOSwdqRXiJGT

 

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The Atmel studio uses a proprietary debug engine that is indeed better optimized than the open-source Avarice tool (especially if you are using a VM with USB virtualization), however unfortunately it’s beyond our capacity to develop and ship a custom low-level debug engine just for AVR devices, so we have to rely on the open-source tools.

Our best advice for improving performance would be to enable the timing view in the GDB Session window and check the commands that VisualGDB runs. If most of the time is spent querying call stack, variable values, etc., closing the corresponding VS windows will dramatically improve the performance.

[rasyoung]

Thank you, will do.

[Author]

Posts